A Penn State University team tested five models, two agent frameworks, and three code benchmarks and found that after successfully fixing a bug, a median 35%–60% of all steps occurred after the first correct patch. What deserves our attention is that the efficiency bottleneck in coding agents is shifting from “whether it can fix the bug” to “when it should stop.”
What this is
The paper calls the gap between the “first correct patch” and the moment the agent stops on its own “Termination Lag,” meaning the portion of execution that continues after the task has already been solved. The research team saved a snapshot of the code repository between each model call, then replayed every snapshot after the run using the official tests. This allowed them to distinguish between two capabilities: “finding the answer” and “knowing the task is complete.”
The results show that 82% of Qwen3-Coder runs on SWE-bench Verified produced a correct result from their first source-code modification. Laguna-XS.2 nevertheless took 57 additional steps after its first correct patch, while its context grew by 78%. Most subsequent actions involved repeating tests and inspections, accounting for 48%–63% of the activity; actual continued source-code modification made up only 2%–6%.
Industry view
Our judgment is that the next critical capability for agent products will be “reliable stopping”: providing a verifiable signal that the task is complete while curbing endless self-testing and unnecessary changes. This can directly reduce model-call costs, waiting time, and the probability of errors, making it especially important for business models that charge by step or by task.
The research also has its limits. The paper’s “ideal stopper” stops only after retrospectively identifying the correct patch, but real-world products cannot know the answer in advance. The study also focuses mainly on code-repair scenarios, so its findings may not apply to open-ended tasks such as research or customer service. There is a further risk: stopping too early may miss edge cases, while prioritizing speed too aggressively can leave hidden defects in the code.
Impact on regular people
For enterprise IT: When deploying coding agents, organizations should expand procurement metrics beyond a single success rate to include time spent fixing issues, the number of unnecessary steps, and rollback rates, while retaining human review for critical changes.
For individual professionals: When developers use tools such as Claude Code or Cursor, defining clear acceptance criteria and a change budget may be more valuable than simply increasing model quotas. Test coverage and version differences should still be checked before submission.
For the consumer market: If tools finish earlier, per-call pricing, subscription allowances, and response times may decline. But “appearing faster” does not mean the results are more reliable; consumers still need to see whether the final output passes real-world tests.