New research reveals that while developers feel 20% faster using agentic AI, actual verified "done" rates have dropped by 19% due to the hidden overhead of a...
The Gap Between Feeling Fast and Being Done
Agentic AI changes what "progress" feels like. When a tool drafts an implementation, wires up the boilerplate, and returns a plausible-looking result in seconds, the work registers as nearly finished. New research puts a number on that sensation: developers report feeling roughly 20% faster when working with agentic assistants. The problem is that speed is measured at the moment code appears, not at the moment it is confirmed correct.
The same research shows verified "done" rates falling by about 19%. In other words, more work reaches the "looks complete" stage and less of it survives real scrutiny. The paradox is that the two numbers are related: the faster generation gets, the more output there is to check, and checking is exactly the step that does not get faster.
Where the Hidden Overhead Comes From
Writing code was never the whole job. Reading it, understanding its intent, and proving it does what was asked are the parts that determine whether something is actually finished. An agent shifts effort away from authoring and toward reviewing, but it presents the output as if the review is already handled. The reviewer then has to reconstruct reasoning they never performed themselves.
That reconstruction is slower than reviewing your own work, because you are auditing decisions you did not make. The overhead shows up in predictable places:
- Tracing why the agent chose a particular approach when the code offers no rationale.
- Catching plausible-but-wrong logic that passes a glance but fails an edge case.
- Re-running and re-reading generated tests to confirm they assert something meaningful.
- Reconciling code that works in isolation but conflicts with the rest of the system.
Treating Verification as the Real Deliverable
The fix is not to abandon agentic tools; it is to stop counting generation as completion. Define "done" in terms you can check independently of how the code was produced. A task is finished when a failing test now passes, when the behavior is observed working end to end, or when a reviewer can explain the change without the agent present. If none of those are true, the work is still in progress no matter how finished it looks.
Practically, this means writing the success criteria before the agent runs, not after. When you know exactly what "verified" means for a task, the agent's speed becomes a genuine advantage: it clears the mechanical work quickly and leaves you time for the checking that actually closes the task.
Measuring the Right Thing
Teams that only track how much code ships, or how fast it appears, will read the 20% speed gain as pure progress and miss the 19% they are losing at the finish line. The more honest metric is the rate of work that reaches verified completion without rework, which captures both the generation and the checking in a single number.
Once you measure completion instead of output, the tradeoff becomes visible and manageable. The goal is to keep the felt speed while closing the verification gap, so that faster authoring turns into faster finished work rather than a larger pile of things that merely look done.