You only find out what you actually wanted once you’re looking at the thing that got built. The coding agent did exactly what you asked, and it’s still wrong — not because it misunderstood you, but because you didn’t know yet what you meant. A study submitted 2 September 2026 mined 3,553 coding-agent sessions and measured that moment: requirements surfacing only after implementation begins — the kind nobody could have written down, because seeing the code is what triggered them — get an agent’s prior work deleted or replaced at roughly twice the rate of any other edit, a 1.96× ratio, 95% CI [1.31, 2.82]. Standard advice says specify everything before the agent starts typing; this study’s sharpest finding is that the costliest requirements weren’t skippable by prompting — they didn’t exist yet to prompt about.
The rework tax lands on requirements the code itself provoked
Across 402 usable sessions and 921 requirement-arrival events in 74 repositories from the SWE-chat dataset, the paper’s primary canonical matched analysis narrows to 452 real events: those average 57.5 invalidated prior lines, against 29.4 for their set-weighted controls — that 1.96× gap, or 2.28× on a conservative measure. Fifty-four percent of requirements arrived past the session’s midpoint, beyond where a spec could plausibly have caught them. The paper’s own abstract explains why: stakeholders
“cannot express a constraint until part of the system exists to react to.”
That’s not a communication failure. It’s how people actually recognize what they wanted.
The obvious fix is to prompt around it — warn the agent that requirements might shift. The study tested that directly: E2 ran 25 tasks twice each with Aider, 200 runs total, round two applying the identical change in both arms, the only difference being whether round one carried a warning. A working fix should have cut how much prior code got overwritten. It cut 0.16 lines — about a sixth of one line — confidence interval [−0.56, +1.06]. Correctness barely moved, 92.7% versus 93.8%.
This measures sequencing, not a prompt you forgot to write
A one-sentence heads-up bought back about a sixth of a line, not the rework itself.
2026’s dominant answer to this churn is spec-driven development: write the requirement down properly first, trade planning time for less downstream rework. Microsoft states the trade plainly — with a spec upfront, “more time goes into clarifying intent and planning up front, and less time is lost to downstream rework,” per a June 2026 post
by principal engineer Apoorv Gupta. GitHub’s Spec Kit
walks a project through spec, plan, tasks and implementation, its /speckit.clarify step meant to surface underspecified areas before code exists.
Here’s the seam worth keeping visible: the study measured a chat-turn warning, not a written spec, and never ran Spec Kit, Kiro, or any spec-driven toolchain. Read across to what a spec actually does — not disclose uncertainty, but move a requirement’s content earlier — and the finding lines up with the orthodoxy, not against it. Its companion experiment, E1, tested that directly: disclosing the actual requirement relocated work earlier (delayed disclosure added 9.2 lines of round-two churn, [+6.4, +12.8]) while correctness held, 95.0% upfront versus 92.9% delayed. A spec gives an agent content to react to before the provoking code exists; a warning gives it nothing.
That has a practical edge for whoever runs these sessions. For the developer who kicks off a task, walks away, and only realizes what she wanted at the diff, the lesson isn’t to preface prompts with “I might change this” — the study measured that disclaimer, and it did nothing. Expect an after-the-fact correction to cost roughly double the code, and budget the time and tokens for it, not the trust in what ships.
The paper hedges more than the headline lets on
The authors are careful about what they haven’t shown. Line-level invalidation is, in the paper’s own description, a syntactic proxy — it marks code disappearing under replay, not proof that the deleted lines’ meaning was actually broken, and the authors treat their controlled experiment only as a bound on the causal reading of the association, not as the paper’s headline claim. Timing and operation-type breakdowns come back inconclusive, and only 18–22% of clean-start sessions contained a detected emergence event, in a non-random sample skewed toward longer sessions. The authors say the advance-warning null “does not establish equivalence”: no detected effect isn’t proof of no effect. The controlled runs also used just one tool, Aider, against two backends, gpt-5.6-sol and gpt-5.6-terra — a narrow base to hang a null result on, whatever it might mean for other tools and models.
Independent skepticism of spec-driven orthodoxy exists too. Thoughtworks’ Birgitta Böckeler, on Martin Fowler’s site, warns bigger specs can amplify “review overload and hallucinations,” describing an agent that took her notes on existing classes as a new spec and regenerated duplicates. Calvin French-Owen similarly cites Steve Yegge’s advice to “make lots of plans” and “expect to throw them away” — closer to the case study on governance discovered mid-project, not specified upfront than to Spec Kit’s pitch.
None of that reverses the core finding, only narrows what it can claim. The rework tax on late requirements looks real; what isn’t established is that anything short of knowing it sooner removes it. It’s the same lesson as a mid-run edit silently breaking an agent’s sense of “done” : timing matters more than what got said.
Which is the honest shape of the finding: not that specification fails, but that the failure caught here has nothing to do with what you said, and everything to do with when the code first made you need to say it.
