An issue that is well written for your team can be a poor spec for a coding agent. The person reading it fills in what is missing with what they know about the product, the customer and what was said yesterday in the daily. The agent has none of that.
The idea this insight defends: when a task is missing information, a coding agent that nobody has told otherwise tends not to ask: it invents it and carries on. That is why turning an issue into a spec is not delegated to the agent. A person who knows the product does it, before the agent writes a single line.
What an issue takes for granted
An issue is a note between colleagues. "Add a date filter to the orders list" is enough if whoever picks it up knows what an order is, which date counts and whom to ask. Three things are almost always taken for granted: where the change is, what must not be touched and when it counts as done. That list is ours, not from a study. An agent that receives only that sentence has to decide all three, and does so without telling anyone.
What the agent does when something is missing
Three recent studies measure the same thing with different methods: what happens when an instruction is missing data.
The first is Ambig-SWE (Vijayvargiya, Zhou, Yerukola, Sap and Neubig; accepted at ICLR 2026). It starts from 500 SWE-bench Verified issues, a set of real issues from open-source repositories, and generates with GPT-4o summarised versions that are missing data. Result: without explicit prompting, models almost never interact, even for severely underspecified inputs. And only two of the six models evaluated told a complete task from an incomplete one with notable accuracy (89% and 84%), and that was when they were encouraged to ask. When the agent could ask a simulated user, performance improved by up to 74% compared with not being able to.
The second is "Ask or Assume?" (Edwards and Schuster, University of Vienna; EMNLP 2026). It uses 500 SWE-bench Verified issues from which details such as code snippets, file paths and stack traces are removed. With Claude Sonnet 4.5 as the base model, the agent resolves 70.8% with the full issue. With the incomplete issue and no way to ask, 54.8%. With a set-up that separates detecting what is missing from running code, and asks before acting, 69.4%. With a second model, 69.4% against 72.8% with the full issue.
In percentage points, our own arithmetic: of the 16 lost with the trimmed issue, the set-up that asks recovers 14.6. The difference is not made by a better model but by a step in the process: detecting what is missing and asking before writing code.
The third is "Coding Agents Are Guessing" (Ji and others, Hong Kong University of Science and Technology and Tongji University, July 2026). It measures operations (DevOps) tasks with 2,208 variants of 69 task families and five agent and model combinations. Its conclusion: underspecification, rather than mainly making agents fail, makes them guess. Depending on the setup, they asked in between 1.7% and 44.5% of scored runs. And warning about the blast radius (how far an action reaches) barely reduced how often the agent acted.
Risk These are benchmarks, not real teams. In Ambig-SWE the incomplete issues are summaries generated with GPT-4o. In "Ask or Assume?" details are removed from real issues and the one answering is a simulated user (GPT-5.1) who holds the full issue; your team needs a real person. "Coding Agents Are Guessing" measures operations, not features. The models are those of each study. We keep the direction, not the percentage.
What an issue should carry before you hand it to an agent
The studies do not say how to write an issue; they say what happens when data is missing. From there, this is our proposal: six things a person usually carries in their head and the agent needs in writing. The right-hand column is the question that, once answered, closes each gap.
| What the issue leaves implicit | What the agent needs to know | The question that closes it |
|---|---|---|
| Where the change is | Modules, files and entry points affected | Where do we change things, and where not? |
| What each term means | The domain concept as it exists in this code ("order", "date") | Which field or concept exactly? |
| The edge cases | Empty values, time zones, permissions, large volumes | What happens when the input is odd? |
| When it is done | Acceptance criteria that can be checked | Which test would prove it is done? |
| What must not break | API contracts, customer data, migrations | Which change would be visible outside or irreversible? |
| Who decides if there is risk | The person who approves if it touches money, data or security | Who approves it before it is merged? |
onext's own work
Who closes the gaps
The agent can help, on one condition. It is asked to list, before writing code, what it is missing as questions rather than assumptions; that is, in essence, what the set-up proposed in "Ask or Assume?" does. But the one answering is a person who knows the product. The sequence we propose, within Spec-Driven Development (SDD):
- Ask the agent for a list of questions about the issue, with no code. It has to be an explicit instruction: without it, according to Ambig-SWE, it almost never asks.
- A person who knows the product answers in writing, on the issue itself, for whoever comes after.
- With the answers, the issue becomes a spec: scope, limits and acceptance criteria that can be checked.
- Where there is risk (money, personal data, security, changes that cannot be undone), a person approves the spec before the agent implements, and you decide how to undo what it does. A person decides where there is risk.
An issue is ready for an agent when nobody has to explain anything else to it: what is missing is asked about beforehand, not discovered in review.
An example, made up
The issue says "Add a date filter to the orders list". Before writing code, an agent should ask: is the date the creation date or the delivery date? Does the range include the last day? In which time zone is it read? Is there pagination, and how many orders can there be? Who may see which orders? If nobody answers, the agent picks one answer per question, and whoever reviews finds out, if they find out, by reading the diff. It is an example to illustrate; it is not from any customer.
It is the same logic we explain in Specs and agents: the spec is where you sign off, but one step earlier: here the spec is not signed off, it is written. What the agent cannot guess about your code, such as architecture decisions, we covered in architecture decisions. And if what reaches review is an assumption nobody spotted, the gain sits waiting there, as we describe in more code, same delivery.
A test for this week
Take three issues your team is about to start. Give each to the agent with a single instruction: "Do not write code. List what you need to know that is not in the issue". Count how many questions are useful and how many you would have found in review. It is a home-grown test, not a measured method. If on one of them it asks nothing, do not take the issue as good: the models in Ambig-SWE were poor at telling a complete task from an incomplete one.
If you want to see how this is written on your own team's code, with someone from outside, the diagnostic is free, and if the diagnostic shows no difference, there is no Quick-start. The rest of the path is at AI-Accelerated Development. The full method is in Spec-Driven Development with AI.
Frequently asked questions
What is the difference between an issue and a spec for a coding agent?
An issue is a note between colleagues: it takes for granted where the change is, what must not be touched and when it counts as done. A spec for an agent says it in writing: scope, limits, edge cases and acceptance criteria that can be checked. What a person fills in on an issue from their knowledge of the product has to be given to the agent.
Do coding agents ask questions when information is missing?
Rarely, unless you tell them to. In Ambig-SWE, models almost never interact without explicit prompting, even for severely underspecified inputs. In Coding Agents Are Guessing, depending on the setup, agents asked in between 1.7% and 44.5% of runs. In "Ask or Assume?", the set-up that separates detecting what is missing from execution asks before acting.
Does an issue have to be much longer for an agent?
We don't know of a study that measures the ideal length. What the studies remove from issues to make them incomplete are concrete details: code snippets, file paths, stack traces. More than more text, what is needed is the information the agent cannot infer: where, what not to touch and when it is done.
Can the agent itself turn the issue into a spec?
It can help with half of the work: read the issue and list what it is missing as questions, without writing code. The other half is not its own: answering those questions requires knowing the product, the customer and the business context, and a person does that. Without that answer, the agent fills the gaps with assumptions again.
Which tasks should not go straight to an agent?
Those that affect money, personal data, security or changes that cannot be undone. For those, a person approves the spec before the agent implements. The study on operations (DevOps) instructions found that warning the agent about the blast radius (how far an action reaches) barely reduced how often it acted: asking for care does not replace someone deciding.
How do I check whether my team is doing this well?
With a small test: take three issues about to start, ask the agent to list what it needs to know without writing code, and count how many questions are useful, meaning how many you would have found in review. If it asks nothing, that does not mean the issue is complete: the models in Ambig-SWE were poor at telling a complete task from an incomplete one.
Sources
- Sanidhya Vijayvargiya, Xuhui Zhou, Akhila Yerukola, Maarten Sap and Graham Neubig, "Ambig-SWE: Interactive Agents to Overcome Underspecificity in Software Engineering", arXiv:2502.13069, version 3 of 21 February 2026 (accepted at ICLR 2026).
- Nicholas Edwards and Sebastian Schuster (University of Vienna), "Ask or Assume? Uncertainty-Aware Clarification-Seeking in Coding Agents", arXiv:2603.26233, version 3 of 7 September 2026 (camera-ready for EMNLP 2026).
- Zimo Ji, Zekai Zhang, Congying Xu, Zongjie Li, Yudong Gao, Shuai Wang and Shing-Chi Cheung, "Coding Agents Are Guessing: Measuring Action-Boundary Violations in Underspecified DevOps Instructions", arXiv:2607.02294, 2 July 2026.
- The table, the steps, the example, this week's test and the calculation of recovered points are onext's own work.
Bernat López is founder and CEO of onext, an AI boutique. He helps development and product teams work with AI with method —specification before building, a person who decides where there is risk and Spec-Driven Development— and applies to his own company what he proposes: onext runs on its own agentic system.
LinkedIn →