Coding agents start editing on the first message. Users, being human, keep thinking of things afterwards. Researchers took a corpus of real agent sessions linked to their repositories, replayed them edit by edit, and tracked which lines the agent itself had written. That let them ask a question benchmarks are built to exclude. When a constraint arrives after the agent has already started, how much of the work does it take back?
"A constraint stated in turn fourteen meets code written during turn nine, in the same working tree, minutes earlier."
After a new requirement arrived, agents deleted about twice as much of their own earlier code as they did after an ordinary edit, roughly 28 extra lines each time. The comparison held even when it was restricted to edits following a user turn that introduced nothing new, so it isn't just the effect of the user speaking again. Around one session in five contained at least one of these late arrivals, and most were ordinary refinements rather than reversals. The dominant reason recorded was simple preference. It was not a bug, not a failure, just a user seeing the thing and wanting it different.
The code being undone was not a first draft. Lines deleted after a requirement landed had typically survived several rounds of editing already.
"Rework therefore targets established agent output rather than immediate drafts."
A controlled follow-up tried the obvious fix and it did nothing. Telling the agent in advance that a constraint was coming, without saying what it was, produced no measurable change in how much prior code it overwrote. Delaying the requirement moved implementation work later rather than adding to it, and the finished code passed its tests at about the same rate either way. The authors read this as agents being unable to adapt to content they haven't yet received. That is plausible, but their design cannot test it, because the experiment varied what the agent was told, never how it worked.
For a team, churn inside an agent session is a bad proxy for waste. A session that rewrote itself twice may be one where the requirement was discovered rather than fumbled, and measuring agents on lines accepted at the end will punish the work that was hardest to specify up front. That is also the gap to press on in a vendor demo, because throughput numbers come from benchmarks where the brief is fixed before the first edit by design, which is the one condition this study shows real sessions do not meet.
What the study cannot settle is whether these deletions actually serve the new requirement. It measured what followed an arrival, not what caused it; when a sample was inspected, only just over half of the invalidated code looked requirement-driven and much of the rest read as incidental tidying. Nor does it know how many late requirements a session-opening checklist would have surfaced early. That conversion rate is unmeasured, and it's precisely the number any "specify it first" workflow is implicitly promising.
Sources
- Jiang, B., Cheng, H., Fu, Y. et al., "Requirements After the First Edit: Mining Late Requirement Emergence and Rework in Real-World Coding-Agent Sessions" — https://arxiv.org/abs/2609.03028