The expensive failure of an AI coding tool is not a wrong answer. It is a confident guess. A wrong answer looks wrong. A guess looks like a finished spec, gets approved, gets built, passes the tests the agent wrote for itself, and turns out to be about something slightly different from what you meant. You find out in review, after paying for the run.
We had a clear example of our own. On projects with several repositories, the spec drafter was given no list of those repositories and none of the conversation about the task. A task with no repositories selected then ran on the project's first repository only. The spec read well. The work landed in the wrong place.
Two moments to ask
In CodeLynq the task has one chat, and it changes role with the spec. While the spec is still blank, the chat scopes the task. Once a draft exists, it reviews the draft. Both work like a technical lead who has to sign the work off, because that is the job the questions do.
Scoping starts with the lead restating the task in its own words and the approach it would take, so a misunderstanding shows in the first message rather than in the pull request. Then it works out where the work goes. On a project with several repositories it names the ones the task touches and what changes in each, and it is told never to assume the work fits in one repository without saying why. It knows each repository's branches and what codebase memory has learned about it. Then it asks about scope: what is explicitly out, which repository owns what, how the parts talk to each other.
When you draft the spec from that conversation, the drafter gets the transcript and the repository list. On a multi-repository project it also says which repositories the task needs, and those are selected on the task, but only when nobody had chosen any.
How the questions are asked
The format matters as much as the content. An open question ("how should large exports behave?") is homework. A proposal is a decision you can make in a second. So every question is phrased as something to confirm: "I would run large exports in the background and email a link, because a request would time out. Agreed?"
- At most three questions per message, the most consequential first.
- Two to four short answers per question, with the lead's recommendation first, and always room to type your own.
- Nothing the spec already answers, and nothing the lead can sensibly decide itself. It states those decisions in one line instead.
In review, the questions go where a wrong guess changes what gets built: behaviour at the edges (empty, invalid, duplicate or concurrent input, permissions), existing data and migrations, backwards compatibility, API contracts and who calls them, security and privacy, performance where volume matters, rollout, and what proves it works.
A drafted spec also hands itself over. It comes with a short note from the lead, the approach in a line and what needs confirming, and up to four confirmations about the assumptions in the draft, each with the draft's own choice as the first option. Those appear in the chat as the review of the proposal, and the spec screen shows how many are still open.
Knowing when to stop
A chat that keeps asking is its own failure. People stop answering, or answer carelessly to make it go away. So the lead has an explicit stop signal. When nothing important is open, it summarises what was agreed and ends the message with a [[READY]] marker, which it may never use while a question is still open. The app hides the marker and shows "Nothing important is open", with the next step: draft the spec, or put the decisions into it and approve.
Answers belong in the spec, not the transcript
The agent builds from the spec, not from the chat. A decision that lives only in a conversation is a decision the agent never sees. So after a review, one button updates the spec with what was agreed. It keeps what the conversation did not change, and where something was left open it keeps the spec's choice and lists it under assumptions, so the gap is visible rather than silent.
A draft is updated in place. A submitted spec goes back to draft, because what was submitted is no longer what it says. An approved spec is not touched: you open a new version to change it, so the approval always points at the text that was actually approved. The chat then gets a message saying what changed.
What it does not do
- Open questions do not block approval. The spec screen shows how many are still open before you approve, and you can approve anyway.
- The chat is not a code review. It works from the task, the spec, the repository list and what codebase memory knows. The run is where the code is read in full.
- It cannot ask about what nobody knows is missing. If a constraint lives only in someone's head, the lead will propose something reasonable and you have to catch it.
It has also gone wrong in a way we did not expect. The first draft on a project with three repositories came back blank: the model ran out of output room halfway through its answer, and the empty fields were stored as a finished spec. We raised the limit, and a blank answer now counts as a failed draft rather than a ready one.
A test for any spec tool
Three questions tell you most of what you need: does it ask before it writes, does it know when to stop asking, and do the answers end up in the document the agent builds from. More on the approach on the spec-driven development page, and a worked example in what is spec-driven development.