Your coding agent builds exactly what the ticket says. That is the problem.

Picture a ticket that has sat in the backlog for a month: "Add bulk export of invoices to CSV, so finance can reconcile in Excel." On a team using coding agents it gets picked up after lunch, and by mid-afternoon there is a pull request with the feature, a dozen tests and a green build. It looks like the future everyone was promised. Then someone in finance tries it on a real customer list, and the questions start.

Can a sales rep export every customer's invoices, or only their own? What happens at 200,000 rows? Are voided invoices in the file? Why does one customer's name open as a formula? None of that was in the ticket, and every one of those questions has an answer in the code. The agent chose them. Nobody told it to, and nobody noticed that it had.

If you are planning next year's roadmap around AI-assisted delivery, from your own team or from a partner, this is the cost that rarely makes it into the business case. AI makes writing code far cheaper. It does nothing for deciding what the code should do, and it removes the slow, human friction that used to drag those decisions into the open.

Every gap in a ticket is a decision somebody makes

Tickets have always been incomplete. On a team of people that was survivable, because the gaps came out as questions. An engineer halfway through the export would post in the channel: do we include voided invoices? The answer took a day, the feature took a week, and the slowness was quietly doing a job. It forced each decision to the surface while there was still time to make it properly.

Coding agents can ask questions, and the better tools encourage it. But an agent working through a task on its own tends to resolve doubt the way a hurried contractor would: pick the most plausible reading and keep going. What comes back is code that looks finished, with every open question already answered inside it. The decisions still get made. They are made by a model, silently, and they return to you as a review problem.

Some of those choices are harmless. Using the server's locale for dates is a nuisance at worst. Others are not. Letting anyone who can see the invoice page export every invoice is an access-control decision, the kind that surfaces in a penetration test report months later, long after anyone remembers choosing it. Writing customer-supplied text into the file unchanged is another. According to OWASP, spreadsheet programs such as Excel and LibreOffice treat a cell that begins with an equals sign as a formula, so a name typed into a public sign-up form can end up running inside the finance team's spreadsheet. The agent was not careless. Nobody asked the question.

Review is the expensive place to find these. A reviewer looking at three hundred tidy lines has to reverse-engineer each decision from the code and then work out whether anyone intended it. That is slower than answering the question up front, and less reliable, because the decisions that never appear as code at all, such as the missing audit record, are the hardest to spot.

"Write better specs" is half the answer

The industry noticed. Spec-driven development, where a structured specification is written first and agents generate the plan, the tasks and the code from it, went mainstream quickly: GitHub open-sourced its Spec Kit in September 2025, and Amazon built its Kiro editor around the same idea. The tooling is useful, and the instinct behind it is right.

Where the common advice goes wrong is in what it treats as the hard part. Most of it is about the writing: templates, formats, how much context to give the model. The hard part of the invoice ticket was never the prose. Five of its seven open questions belong to finance, security or compliance, and none of those people were in the conversation. An engineer, or an agent, can produce a long and fluent specification full of plausible guesses. It reads as finished. It is the same silent decision in a nicer document.

Length makes it worse. A twelve-page specification buries its three real decisions among paragraphs restating the obvious, and the person who should sign them off skims straight past.

What a ticket needs before an agent picks it up

Tickets that come back right the first time share a shape. None of it is new to good product management. Agents simply remove the slack that let teams get by without it.

• The outcome, in the user's words. Who uses the result and what they do with it. "Finance reconciles a month of invoices against the bank statement" tells the agent far more than "export to CSV".
• Two or three worked examples. Concrete inputs and the exact output expected, including one awkward case. Examples become tests before any code exists, and they settle ambiguity faster than any paragraph.
• What not to build. Non-goals stop the agent being helpful in directions you will pay to maintain: no scheduling, no PDF version, no new permission model.
• The facts the code cannot see. Who is allowed to do this, how much data there will be in a year, which regulation applies, which other team depends on the format. An agent can read the entire repository and still know none of these.
• A named person who answers, and how fast. Every remaining gap needs someone accountable who will reply the same day.

Let the agent ask first

The cheapest fix is a habit that takes about fifteen minutes. Before any code is written, give the agent the ticket and the codebase and ask for one thing: a numbered list of every assumption it would have to make to build this. No code yet.

On the invoice ticket, that list would cover most of the rows in the table above: scope, permissions, volume, formats, voided records. A person then goes down the list and answers each item, marks it as the engineer's call, or sends it to whoever owns it. The questions arrive in one batch on the first day, instead of one at a time across a week, or not at all.

Two cautions. The agent can only raise questions it can infer from the code and the ticket, so it will rarely ask about the contract clause that promises customers a monthly statement, or the auditor who wants every export logged. Someone who knows the business still reads the list and adds what is missing. And do not let the agent answer its own questions. It will happily do so, which is how the export got built in the first place.

The bottleneck moves to your side of the table

This is the part buyers price in least. When code takes weeks, a product owner who answers questions within three days is fine. When code takes an afternoon, that same product owner sets the pace of the whole team, and the agents simply wait faster. Google's DORA research reached a similar conclusion at scale: its 2025 report, built on survey responses from nearly 5,000 technology professionals, describes AI as an amplifier of the strengths and weaknesses an organisation already has. Slow decisions are a weakness it amplifies very efficiently.

So before you commit budget to AI-assisted delivery, run a small test on your own backlog. It takes an hour and needs nobody from outside. Pull five tickets from the top of your next sprint and give each one a point for every yes to the five questions below. They are the five ingredients from the section above, turned into checks.

• Outcome. Does it say who uses the result and what they do with it, in their words rather than the system's?
• Examples. Does it include worked examples with the exact output expected, at least one of them an awkward case?
• Non-goals. Does it say what not to build, so the agent knows where the feature stops?
• Hidden facts. Are permissions, likely data volumes and any rules or regulations that apply written down in the ticket?
• An owner. Does it name a person who will answer questions about it the same day?

A ticket that scores five can go straight to an agent. Three or four means a fifteen-minute assumption pass first. Two or fewer goes back to whoever owns the product, because no engineer, human or otherwise, should be guessing that much. If most of the sprint lands in the bottom group, that is the first thing to fix, and it is much cheaper to fix before an engagement starts than in the middle of one.

Questions to put to any vendor promising AI speed

Every engineering partner now describes itself as AI-native. These questions show whether it has thought about where the time actually goes.

• Who writes, who decides. Ask who drafts the specification and who signs off the decisions in it. A good answer separates the two: their engineers draft, your people decide, and every decision has a name next to it.
• A real specification. Ask to see one from a past project, with client names removed. Look for decisions, worked examples and non-goals, not page count.
• Ambiguity. Ask what their agents do when a ticket is unclear. "It works it out" should worry you. "It stops and lists its assumptions" is the answer you want.
• Examples before code. Ask when the worked examples become tests. The right answer is before the code, so the tests check what was intended rather than whatever got built.
• What they need from you. Ask what they need from your side each day, and what happens to the schedule if you are slow. An honest vendor will say your decision speed caps their delivery speed, and will ask who on your side can answer within a day.

There is an upside in all of this. For years, slow builds gave organisations cover for slow decisions: nobody minded that a question took a week to answer when the feature took a month to build. Agents take that cover away. The first few sprints feel as if the team is suddenly waiting on you, and that feeling is accurate. Teams that treat the wait as information and fix it get the speed they paid for. Teams that tell the agent to just pick something get an export that works beautifully for exactly the wrong people.