For most of my career, a vague requirement was survivable. Not because we caught it. Because building was slow enough that somebody asked a question first.
That question was free, it happened before anything expensive existed, and we never wrote it down as part of the process. It was a side effect of the cost of writing code.
That cost has dropped, and the question went with it. A one-line ticket handed to an AI does not sit in a queue waiting for someone to wonder what it means. It gets executed, literally, at speed, and what comes back looks finished.
Why vague requirements got more expensive
A half-understood requirement used to produce a half-finished feature. You could see the seams, and the seams were the signal. Now the same half-understood requirement produces something polished, with error handling and a loading state and tests that pass. Nothing on the screen tells you that the person who wrote the ticket and the thing that got built were describing two different products.
Review does not close the gap either, because review is checking the code against the ticket. Nobody in that loop is checking the ticket against reality, and we never assigned that job to anyone, because the queue used to do it for free.
That changes where the cost lands. It is no longer wasted build effort, which was always visible and always accounted for. It is a shipped decision, with real data inside it, discovered in month three by a customer or a support queue.
It also scales in a way it never used to. One vague ticket buys you one wrong feature. A backlog written that way buys you a wrong quarter, delivered on time, with a burndown chart nobody would question.
DORA's 2025 research has a finding pointed straight at this. Its new AI capabilities model names seven conditions that strengthen what AI adoption does to outcomes, and the one listed first is a clear and communicated AI stance. DORA's own practical advice for that capability opens on ambiguity, saying that "ambiguity around AI stifles adoption and creates risk."
That capability is narrower than the phrase suggests, and it is worth reading precisely. DORA builds it from respondents' perceptions of four things: whether AI use feels expected of them, whether the organization supports experimenting with it, how clear it is which tools are permitted, and whether the AI policy applies to them. The report's wider argument runs alongside it. The greatest returns, it says, come not from the tools but from the surrounding organizational system, and among the three things it names there is the clarity of workflows.
Read the scope before leaning on any of that. The findings come from 4,867 survey respondents and 78 in-depth interviews, fielded between June 13 and July 21, 2025. DORA presents the capability's effect in bands rather than as a point estimate, so the honest reading is direction and not magnitude, and what the report describes is an interaction between the capability and AI use, not a cause.
The seam matters here, so I will name it. DORA's stance capability is clarity about AI itself: which tools are allowed, whether experimentation is supported, whether the policy applies to you. It is not a measure of how clearly your requirements are written.
The claim that requirement-level ambiguity behaves the same way inside the same system is mine, not DORA's. What their work supports is the shape of the relationship, that ambiguity is costly where the tools accelerate, and clarity is what lets the acceleration land somewhere useful.
DORA State of AI-assisted Software Development 2025: DORA's research program
The honest version of this is that the tools did not create the problem. They moved the expensive part of the work. It used to be building. Now it is deciding, and most delivery organizations are still staffed and scheduled as though the opposite were true.
What AI-ready requirements include
Teams reading this are already thinking, we write acceptance criteria. Most of you do. Go and read the last three your team wrote.
The ones I get handed are written for a colleague. They assume the reader knows the product, knows the customer, and was present for the six arguments the team already had about this feature. That is not a defect. Between people who share context it is efficient, because the criteria are shorthand for a conversation everyone in the room already had.
An AI shares none of that context. It will not tell you what it assumed, and it will not stop to ask. Whatever intent you handed it, it amplifies, and watching it once it is running is a different problem from getting the instruction right. Clear intent gets executed clearly. Vague intent gets executed vaguely, at speed, with confidence.
The obvious workaround does not hold up, either. Telling the tool to ask clarifying questions first produces questions, and the questions are usually reasonable. They are also generated from the same thin ticket, which means they probe what is textually ambiguous rather than what is commercially load-bearing. You will get asked about file formats and not about which customers are allowed to see which rows.
So an AI-ready requirement is not a longer requirement. It is one that survives being read by something with no memory of your product and no stake in getting it right.
Four things make that difference, and they are the four parts of the AI-Ready Acceptance Criteria Template below.
The intent, constraints, examples, tests pattern
Intent is one sentence about the outcome and the user, not the feature. Who is better off, and how. This is the part that most often does not exist anywhere, in any document, because it lives in a product manager's head and gets communicated by tone of voice in a refinement session.
Product clarity is a discipline with its own literature, and its central claim is that the product decision is a decision somebody owns and states, not a consensus that emerges from a backlog. Foundational model, not a 2026 finding. Source: Pichler, Agile Product Management with Scrum.
Constraints are what must not happen. They are the boundaries, and they are where you write down what everybody assumed and nobody said. Every team has three or four of these that are so obvious to the people in the room that writing them feels condescending. Those are precisely the ones an AI will violate.
Examples are two or three concrete input and output pairs. At least one has to be messy, and at least one should be empty. A clean example teaches the happy path, and the happy path is the part nobody was confused about. The messy one is where the intent actually lives, and it is usually the moment you discover the team has not decided something.
Disconfirming tests are how you would prove the thing wrong. Not how you would demo it. Something built from a half-understood ticket will pass a confirming test, because the test was written from the same half-understanding. The question that works is different. What would I see if this were built wrong and still looked finished?
AI-READY ACCEPTANCE CRITERIA TEMPLATE
One feature per copy. Fill all four before building.
1. INTENT
One sentence. The outcome and the user.
Who is better off, and how.
2. CONSTRAINTS
What must not happen. The boundaries.
The assumptions nobody wrote down.
3. EXAMPLES
Two or three input and output pairs.
At least one messy. At least one empty.
4. DISCONFIRMING TESTS
How you would prove it wrong.
Not how you would demo it.
DONE WHEN
Someone who was not in the room can argue
with it before any code exists.Who fills in what
Intent and constraints belong to whoever owns the product decision, which is a judgment about what you hand a tool and what you keep. Examples and disconfirming tests belong to the people who will build it, because they are the ones who know where it breaks. Filling this in together, out loud, is the refinement event doing the job it was supposed to be doing all along.
Two things this is not. It 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.
A worked example
Start with a genuinely vague one. Make the dashboard faster.
ILLUSTRATIVE EXAMPLE. FICTIONAL.
INTENT
A regional manager can open the Monday regional
dashboard and read this week's numbers before
their first meeting, without opening a second
tab to wait for it.
CONSTRAINTS
Never shows a stale number without saying so.
Does not drop year-over-year to gain speed.
Does not load the reporting database in hours.
EXAMPLES
One region, clean month: reads immediately.
Messy: four regions, one reorganized mid-
quarter, so last year does not map. What does
the page show, and who decided?
Empty: a new region shows an empty state,
not a zero.
DISCONFIRMING TESTS
Page is fast, numbers are an hour old.
Comparison quietly drops the reorganized region.
Managers still open the old report to check it.That intent sentence settles three things the original did not. Who it is for. What faster is measured against, which is a human deadline rather than a millisecond count. And which behavior it is meant to end.
None of those three disconfirming tests show up in a demo. All three show up in month three. Now hand that to an AI. Same tool, same afternoon, and what comes back is something you can argue with. The argument happens before the code exists, which is the only time it is cheap.
Try this next week
Take one item already in your sprint, one that feels clear enough. Write the four fields on it before anybody builds anything, and pay attention to which field is hard. That is the one carrying the ambiguity.
Do it on a ticket someone has already read and approved, not a fresh one. A fresh ticket makes the exercise feel like extra work you invented. An approved one shows you what the approval was actually approving.
If the intent takes three sentences, you have two features. If the constraints are empty, you have not asked the team what they are assuming. If you cannot write a disconfirming test, nobody in the room knows what wrong would look like, and you are about to find out at production speed.
If you want to work one of these through on a real backlog item, bring it to a Just-in-Time Just-Enough session, or look at how we run this with product and engineering teams.