The agent that asks a question is worth ten that do not

Two agents are given the same ticket. It says: “Users should be able to export their transaction history.”

The first one ships. It produces a CSV endpoint, a button, a test, and a tidy pull request in eleven minutes. The second one stops after ninety seconds and asks four things. Which date range. Whether “their” means the authenticated user only or also accounts they administer. Whether the export is synchronous or queued for accounts with a large history. Whether deleted transactions appear.

Almost everyone in the industry currently treats the first agent as the better product. I think that is exactly backwards, and the mistake is being baked into how these tools are evaluated.

My position: the willingness to stop and ask is the single most valuable behaviour an agent can have, it is being actively trained out because one-shot completion is what demos well, and the questions themselves are a free, continuous audit of your specification quality that most teams are throwing away.

The four questions were the actual work

Look at what the second agent produced. Not code: a list of the decisions that ticket concealed.

Every one of those questions has a right answer that lives in somebody’s head, and every one of them has a wrong answer that ships silently. “Their transaction history” resolving to authenticated-user-only is a defensible reading. It is also the reading that generates a support queue on day one from every business account with delegated access.

The first agent did not avoid those four decisions. It made all four, invisibly, in eleven minutes, and encoded them into an implementation plus a test suite that now asserts them as correct. The decisions still happened. What changed is that nobody knows which way they went until something breaks.

This is the honest shape of context blindness. The failure mode is not incoherent output. It is output that is internally consistent, well structured, plausibly reviewed, and built on an assumption nobody in the organisation ever agreed to.

Agent that guesses

• Ambiguity resolved in silence, at generation time
• Assumption encoded in code and in the tests that guard it
• Cost surfaces after merge, usually in support
• Reviewer must reverse-engineer the assumption from the diff
• Looks fast on every dashboard you have

Agent that asks

• Ambiguity surfaced before any code exists
• Decision made by the person who is allowed to make it
• Cost is ninety seconds and one Slack reply
• Reviewer checks a stated criterion, not an inferred one
• Looks slower on every dashboard you have

Questions are the cheapest artefact in your pipeline

Price the alternatives honestly.

A clarifying question costs a context switch and a one-line answer. Call it two minutes of a product person’s attention, and it happens before anything has been built on top of the wrong answer.

A wrong assumption caught in review costs a reviewer working out what was intended, a comment thread, a regeneration, and a second review. Call it a day of elapsed time, mostly waiting.

A wrong assumption caught in production costs an incident, a fix, a migration for whatever data was written in the meantime, and a conversation with whoever noticed before you did.

Controlled studies on specification quality point the same way: human-refined specifications cut downstream errors by up to half. That result is usually read as an argument for writing better specs up front. It is also an argument for the cheaper thing, which is letting the builder tell you which part of the spec was not good enough, at the exact moment it discovers the gap.

You will never write a spec that anticipates every question. You can absolutely build a loop that makes asking cheap.

The rate is a metric, and you are probably not looking at it

Here is the part I would like more teams to take seriously.

Count the clarifying questions your agents raise, group them by the ticket and the area of the codebase, and you have something no survey will give you: a continuous, unsolicited measurement of where your requirements are thin.

The patterns are legible almost immediately. One squad’s tickets generate three times the questions of another’s. Every ticket touching permissions generates a question about scope, because your permission model has never been written down anywhere an outsider can read. A named person’s tickets are consistently unambiguous, which tells you something you should act on at review time.

Questions cluster on one teamTheir tickets are titles, not criteria. Fix upstream, not in review.

Questions repeat across ticketsA shared rule exists only in someone's head. Write it once, put it where the agent reads.

Questions concentrate in one moduleLocal conventions are undocumented. That module is also where your context blindness incidents are.

Question rate near zeroNot a clear backlog. An agent tuned to never ask, or a loop where asking has no route to an answer.

That last row deserves emphasis. A question rate of zero is not evidence that your specifications are good. It is evidence that either the tool will not ask or the organisation has given it nowhere to ask. Both are worth knowing.

Build the loop, or the behaviour dies

Asking is only useful if the answer arrives before the code does. In most teams it does not, because the question lands in a channel nobody owns, and the agent has no state in which to wait.

Three things make the difference, and none of them are exotic.

A destination. The question goes somewhere with a named owner and an expected response time, attached to the work item rather than floating in chat. If a clarification takes two days to answer, everyone learns to guess instead, and they are right to.

Permission to stop. The agent must be allowed to produce nothing and still be considered to have done its job. If your only measure is throughput of merged changes, you have priced questions as failure, and you will get an agent that guesses.

Answers that persist. The answer to “does export include deleted transactions” should end up in the acceptance criteria, in the repository, where the next agent and the next reviewer both find it. Answer it in Slack and you will answer it again in six weeks.

The third one is where most of the value is, and where most teams leak it. A clarification answered in a thread is a decision made and immediately discarded.

Where this breaks down

An agent that asks constantly is unusable, and the failure is real. There is a failure mode where every trivial ticket generates six questions, product people stop reading them, and the whole channel becomes noise that gets muted. Volume without prioritisation is not a signal, it is a tax. The behaviour you want is a small number of high-consequence questions, and nobody has a reliable way to tune that yet.

Questions can be a substitute for competence. A good agent should be able to read the repository and answer “what does ‘their’ mean here” from existing code, existing permission checks and existing conventions. If it is asking things the codebase already answers, that is not admirable caution, it is a retrieval failure wearing a polite face. The distinction between “the answer is not in the repository” and “I did not look” matters enormously and is hard to inspect from outside.

The people receiving the questions are the constraint you already have. Product managers and tech leads are not sitting idle. Routing more decisions to them makes them the queue, and a clarification loop that adds four interruptions a day to the one person who understands the domain may cost more than it saves. If you build this, watch their calendar, not just your defect rate.

Some ambiguity is genuinely cheaper to resolve after the fact. For low-consequence, easily reversible work, guessing and correcting beats asking and waiting. The export example is not that. A copy change on an internal admin page is. A policy that treats all ambiguity as equally worth stopping for will slow down the ninety percent of work where nobody cares.

And I have a commercial interest here. We sell tooling in the space between a ticket and a merge, so an argument that specifications deserve more attention is an argument that happens to suit us. Discount accordingly, and note that most of what I have described is a process change and a channel with an owner, not a purchase.

The takeaway

The agent that asks is not slower. It is doing the same decision-making as the agent that guesses, out loud, at the point where the decision is cheapest to correct. One-shot completion rate is a demo metric, and optimising for it means paying for those decisions later at a much worse exchange rate.

More usefully: the questions are data. Their rate, their clustering and their repetition tell you where your specifications are thin, continuously, without running a survey or holding a retrospective. Almost nobody is collecting them.

If you take one thing into next week: find out whether your agents can ask a question at all, and if they can, find out where those questions currently go. If the honest answer is “nowhere” or “a channel nobody reads”, you have been discarding your best free signal about the quality of your own backlog.