Somebody on your team opens a ticket. Azure DevOps, Jira, whatever you use. It says: add a way for customers to export their data. Just one line. How hard could that be?
They hand it to an AI coding assistant. By lunch there is a working export button. It has tests. There is a pull request waiting for review. It is fast, it is confident, and it is the wrong feature.
Congratulations. You just built the wrong thing in an afternoon instead of taking all quarter.
Notice what did not fail
The code compiled. The tests passed. The pull request had a reviewer, and the reviewer approved it. Of course they did. Review checks the code against the ticket. Did the thing export? It did. Done.
Nobody in that loop was checking the ticket against reality. That is not a job we have given anyone in this new world. What failed was the sentence at the top, and that sentence had been sitting there looking perfectly fine for two weeks.
For most of my career, a sentence like that could be vague and we would still be fine. Not because we were careful. Because we were slow. A vague ticket sat in a queue. Somebody eventually picked it up and asked what exporting this data actually meant. That question was free. It happened before anything expensive got built.
Refinement quietly turned into estimation
We do have an event for this. If you practice Scrum, we call it refinement. In a general agile sense it is just analysis and design, and it has to happen no matter how you choose to run your products. But in most of the teams I sit with, refinement has quietly turned into estimation with a few extra steps. We size the ticket. We do not interrogate it, which was the whole point.
The four jobs of backlog refinement
I teach in my workshops that backlog refinement is really four activities. Estimating is one of them. Adding and clarifying details is the big one, because that is the conversation where hidden assumptions get surfaced. Breaking large ambiguous items into smaller ones matters because the bigger an item is, the less you know about it. And then design: UI, UX, architecture. All of that has to happen somewhere, and it is not necessarily inside the sprint where the work gets built.
Ambiguity used to have a filter
The filter was the cost of writing code. When building took three weeks, nobody built three weeks of the wrong thing without asking good questions first. Most of the time.
I am not telling you that filter was great. It was slow and it was accidental. It caught things by luck as much as by design. But it caught them, and now it is gone. The ticket does not sit. It gets picked up in minutes and executed exactly as written, which is the thing we always feared when we gave developers too much detail. We did not want to turn people into robots. Look what we built instead.
Polished output is what fools people
A half-understood requirement used to produce a half-finished feature. You could see the seams. You knew where to go looking.
Now a half-understood requirement produces something polished. Error handling. A loading state. All those tests that used to take forever. Nothing on that screen tells you that the person who wrote the ticket and the thing that got built are describing two different products.
So when does anybody find out? In a demo, if you are lucky. After release to the customer, if you are not. And by then you are not fixing a misunderstanding. You are unwinding a decision that already shipped, that already has real customer data sitting inside it, and that already has complexity wrapped around it in the code base. In my experience, AI is much better at adding to a code base than at carefully removing something from one.
AI does not know what you meant. It knows what you said.
In my own use, it asks a clarifying question far less often than a good engineer would. So whatever intent you hand it, it amplifies. Clear intent gets executed clearly. Vague intent gets executed vaguely, at speed, with confidence.
This is also the central finding of the 2025 DORA report, which surveyed nearly 5,000 technology professionals and concluded that AI does not fix a team, it amplifies what is already there. My version of that finding is narrower and it sits in your backlog.
And it does not stop at one ticket. There is compounding interest here. A vague ticket buys you one wrong feature. A whole backlog written that way buys you a wrong quarter, delivered on time and under budget. Every burndown chart looks green. Watermelon projects: green on the outside, red all the way through. What is hidden is the inventory of wrong things you shipped.
The expensive part moved
None of this is an argument against the tools. I use them every day and I am not giving them back. The argument is that they moved the expensive part of the work. It used to be building. Now it is deciding, and deciding was always the actual problem.
Which is why the phrase "AI will fix our requirements problem" has it exactly the wrong way around. Requirements were never a typing problem. They were a thinking problem, even back when typing them out was slow too. The hard part of a requirement is not writing it down. It is deciding what you actually want and what you are willing to give up to get it. That is what a good product owner spends a career learning. Saying yes to something is always saying no to something else.
AI can write the ticket for you. It cannot make the decision for you. It will assume one and keep going, confidently. That assumption is probably the most expensive thing in your pipeline right now, and it is invisible. It does not show up as a defect, because nothing is broken. It shows up six weeks later as a feature nobody uses, and then everybody blames the roadmap.
Clarity is a speed control now, not a quality practice
Product thinking is not the slow part of delivery anymore. It is the part that keeps speed from hurting you. The clearer the instruction, the more of the acceleration you get to keep. The vaguer it is, the more of that acceleration you spend building something you will throw away, and you will never see the cost of it on a financial ledger anywhere.
This lands on one specific person. Whoever writes the ticket is now making a design decision that used to get made later, in a conversation, by a group of people. If you are a product owner or product manager, there is very little sitting between what you wrote and what ships. That is either the best week of your career or the worst one.
Your acceptance criteria were written for a colleague
Somebody is already thinking: we write acceptance criteria. Fair enough. Go pull up the last three your team wrote.
I love acceptance criteria. They are how we identify what done means. But the ones I get handed are written for a colleague. They assume the reader knows the product, knows the customer, and sat through the six arguments the team already had. That is not a flaw. It is efficient between people who share context. AI shares none of it, and it will not tell you that.
The four fields I use
I call this the AI-ready acceptance criteria template until I come up with a better name. Four fields. One feature per copy. Filled in before anyone builds anything.
1. Intent
One sentence about the outcome and the user, not the feature. Who is better off, and how? What capability are you delivering? We get locked onto features. Ask about the capability.
2. Constraints
What must not happen. These are the boundaries, and this is where you write down the things everyone assumed but nobody said. That is hard to produce on demand, but it does come up once you start asking.
3. Examples
Two or three concrete input-output pairs, and at least one of them has to be messy. A clean example only teaches the happy path, and the happy path was the part nobody was confused about. The messy one is where the intent actually lives.
4. The disconfirming test
How you would prove the thing wrong. Not how you would demo it. How would you catch it when it looked right but was wrong?
Most teams I work with can do the first three on a decent day. The fourth is the one that gets skipped, including by me, and it is the one doing most of the work. It is also the hardest to teach. The best way to practice it is to practice it.
A confirming test is easy to pass. Something built from a half-understood ticket will pass it, because it was written from the same half-understanding. So ask the opposite question: what would I see if this were built wrong and still looked finished? That answer usually has to come from the people building it, because they know where the seams are.
Who fills in which field
Intent and constraints belong to whoever owns the product decision and the domain knowledge. Examples and disconfirming tests belong to the people who will build it, because they know where it breaks. Doing that together is the refinement event I described earlier.
Backlog refinement is not a meeting. It is a working session, it is collaborative, and it happens constantly rather than on a schedule.
Two things this is not
This is not a return to writing a specification document for six weeks. Four fields, one page, ten minutes of argument.
And it does not make the AI write better code. It makes you decide on purpose before the AI writes anything at all, and it gives the tool a clear boundary to write inside.
A worked example: the export ticket
Let us run the original one-liner through it. Add a way for customers to export their data.
Intent
A billing admin can pull last month's transactions into their own spreadsheet without contacting support or opening a ticket.
Notice what one sentence just settled. Who it is for. What the outcome is. What capability we are delivering. And which problem it retires: nobody is opening a support ticket for this anymore. That is self-service, and it pays us back for years.
Constraints
It never returns data from another account. It never includes full card numbers. It does not run against the live production database during business hours. People still do that, by the way.
Examples
The clean one: an admin with 100 transactions gets a file that opens in a spreadsheet with dates read as dates. You know what I am talking about.
The messy one: an admin with three years of history in two currencies. Does that come back as one file or two? Who decides?
And the empty one: an admin whose date range returns nothing, who then believes the report is broken. Do they get a file at all? Does it have empty headers instead of an error?
Disconfirming tests
How would I know this shipped wrong even though the button works when I click export?
Support still runs exports manually for the largest accounts, because the file is too big. The file opens with dates read as text. A refunded transaction shows up twice.
None of those three shows up in a demo, especially the date that looks like text. All three of them show up in month three, in a thousand support tickets.
Writing all of that took about as long as this section did to read. It is not a project. Now hand it to AI. Same tool, same model, same afternoon. What comes back is something you can actually argue with, because it has goals attached to it. And the argument happens before the code exists, which is the only time an argument is cheap. Problems found earlier are always cheaper, and that is especially true in software.
One sentence was carrying a decision nobody had made
Back to that ticket. The team did not build the wrong thing because the AI was bad at its job. They built it because one sentence was carrying a decision nobody had actually made yet. That is on us, and by us I mean product people.
That was survivable when building was slow, because the delay absorbed it. We even gave the delay a name and called it a process. It is not survivable when you are using AI to speed up development, and it should not be.
We used user stories for years to help developers see the customer's point of view, and I still think the people building the thing need that context. But user stories are no longer the only thing we need in the box.
Try this next week
Take one item already in your sprint and write the four fields on it before anybody builds anything. Add them to the acceptance criteria. Then tell me how it went.
I would genuinely like to hear about a requirement your team shipped wrong because the intent was never clear. I read those, and a lot of these episodes start there.
If you want to go deeper on refinement as a decision-making practice rather than an estimation ritual, that is a large part of what we work through in our upcoming classes. Bring your own backlog. We will pull a real ticket apart together.
Progress over perfection. You do not have to be perfect tomorrow. You just have to be better than you were yesterday.