Coding Agent 的交互模式天然鼓励“先改起来再说”。用户往往也只有看到第一版实现，才想起新的约束、边界条件或验收标准。速度变快了，需求工程并没有消失，只是被压缩进同一次会话。
研究如何识别晚到需求并测量后续代码失效
图：研究把会话、文件编辑、需求事件和逐行代码变化放在同一时间线上。来源：原论文。
#从“用户又说了一句话”到逐行返工
研究使用 SWE-chat 的真实会话，先以首次写文件为实现起点，再识别之后出现的需求单元，并按它与原始 brief 的关系、变更操作和触发原因编码。对能够可靠重放仓库状态的会话，作者追踪一项具体代理指标：晚到需求出现后，先前由 Agent 写下的行有多少被删除或替换。
最终分析覆盖 3,553 个合格会话。与时间位置相近、但没有新需求的编辑相比，需求到来后发生的既有 Agent 代码失效量约为两倍。控制“用户是否再次发言”、改用净删除量、改变观察窗口后，方向仍然一致。
需求事件前后，被删除或替换的 Agent 代码如何计量
图：测量窗口只追踪需求到来前已经由 Agent 写出的代码。来源：原论文。
#返工不会自然消失
结果没有发现返工负担会随会话推进而明显下降，也没有发现“新增、限制、删除”哪一类操作在控制需求数量后必然造成更多返工。大多数晚到要求是补充，而不是推翻整份需求，但小补充依然会让刚写好的实现失效。
受控实验进一步区分了两件事：把具体需求延迟披露，会把本应较早完成的实现工作推到披露之后；但只提前说“后面还会有一个要求”，在后续工作量相同的情况下，并未显著减少覆盖。预警不能代替信息本身。
论文也没有把观察结果夸成因果定律：删除代码只是返工代理指标，某一行被改掉不一定完全由新需求造成。它更像是给产品设计提供了一个可测量的成本信号——当任务涉及公共接口、数据结构或大范围重构时，Agent 应在首次不可逆编辑前确认关键约束；小范围、可回滚任务则可以继续快速试做。