Fast output is only the beginning
A function previously allocated an hour appears within minutes. The AI has created files, added tests and written a summary.
Then review begins. An existing helper was overlooked. A new dependency is unnecessary. The test checks standard behaviour but misses the permission rule that mattered.
This example is fictional. The calculation is simple: time saved writing can be lost reviewing and correcting.
More generated code does not establish higher productivity. What matters is the effort needed to reach a usable, verified result.
The verification tax is more than a slogan
DORA's article, last updated on 10 March 2026, analyses 1,110 open-ended responses from Google software engineers collected in the third quarter of 2025.
They describe both code-generation benefits and additional review and correction work. DORA calls this a verification tax: some creation-time savings are spent checking the result. This is not a representative timing study of all development teams. [1]
I find the distinction between individual speed and team performance particularly important. Someone quickly generating a large change can hand work to colleagues. The draft is finished; responsibility for assessing it has not disappeared.
Review remains necessary and belongs in the calculation from the outset, whether code is written by a person or generated by AI.
What the 19 per cent slowdown study shows
On 10 July 2025, METR published a controlled trial involving 16 experienced open-source developers and 246 real tasks in familiar projects. Tasks were randomly assigned to allow or prohibit AI assistance.
Using the tools available then, developers took 19 per cent longer on average. Even afterwards, they believed AI had made them faster. [2]
This striking result is limited. It does not show that AI slows every developer, nor is it a current test of all autumn 2026 agents.
The follow-up matters: on 24 February 2026, METR reported indications of greater acceleration but substantial selection and measurement problems preventing a reliable estimate of its size. Some developers did not want to undertake particular tasks without AI and left those tasks out of the experiment. [3]
Using the older figure as a universal verdict on current tools would be as inaccurate as ignoring it altogether.
Controlled studies also show positive results
A study published online in Management Science on 27 February 2026 analysed three field experiments at Microsoft, Accenture and another large company, covering 4,867 developers.
Across the experiments, researchers estimated a 26.08 per cent increase in completed tasks using the studied coding assistant. Results varied between companies, and less experienced developers benefited more. The intervention involved code completion, not every current autonomous agent. [4]
These findings do not automatically contradict METR. Different tasks, tools, teams and measurements may produce different outcomes.
“26 per cent more completed tasks” does not simply mean every task took 26 per cent less time. Before comparing figures, establish what was measured.
What acceleration whiplash describes
Commercial analytics provider Faros uses “acceleration whiplash” in its AI Engineering Report 2026 to describe tensions between higher throughput and growing downstream burdens.
It reports analysing telemetry from around 22,000 developers across more than 4,000 teams. Comparing periods of lower and higher AI adoption, it reports approximately 33.7 per cent more completed tasks and 54 per cent more recorded bugs per developer. [5]
This is an observational analysis by a commercial provider, not randomised proof that AI alone caused the changes. It concerns the organisations analysed, not the entire software industry.
I would not treat the term as a law of nature. It raises a question to investigate locally: are we merely changing more code, or delivering better results reliably to users?
A good benchmark does not cover every codebase
A test must define success. That creates a boundary.
On 13 August 2025, METR described a supplementary investigation of 18 real tasks from two large open-source projects. Agents sometimes produced functionally correct code that still could not readily be accepted because of test coverage, formatting or general quality issues. [6]
Benchmarks are not therefore worthless or inherently unrealistic. Some already use real repository tasks. Automatic assessment simply does not necessarily capture every production requirement. [6]
In an established codebase, existing interfaces, conventions and operating conditions are part of the assignment. A function must fit its surroundings, not just work on its own.
Claiming models are built exclusively for artificial tests and generally fail on large projects would go too far. Ask what a particular test captures and what it leaves out.
Make the full calculation visible
Consider this illustrative calculation, not measured business data:
Clarify the task and create the first implementation: 60 minutes without AI; 25 with AI.
Review and test: 30 minutes without AI; 45 with AI.
Required rework: 10 minutes without AI; 45 with AI.
Total active effort: 100 minutes without AI; 115 with AI.
Both alternatives include review. The invented figures show only how later work could consume an initial drafting advantage.
The opposite is possible too: suitable code, meaningful existing tests and little rework can leave a genuine saving.
With agents, I would distinguish human working time from elapsed time. Ten minutes of autonomous work while the developer does something else differs from ten minutes of constant corrective instructions.
Do not merge those measurements.
Small, verifiable assignments instead of large surprises
I would start with tasks whose results can be assessed clearly.
A bounded change to an existing function is often easier to oversee than “Modernise the entire application”. The deciding factor is a comprehensible change scope, not a rigid line-count limit.
For example: “Add a filter to the existing order search. Use the existing data-access layer. Do not change permissions or add libraries. Show affected files before implementation. Afterwards, report the tests performed and outstanding issues.”
This is not a universal success prompt, but it sets boundaries against which the delivery can be checked.
If the agent thinks additional changes are necessary, I want that decision explained first. Major restructuring should not appear as an incidental side effect of a small feature.
Tests must not repeat the same incorrect assumption
When AI generates both implementation and tests, I would check where the expected results originate.
Suppose an application may display only orders belonging to the signed-in company. Generated code ignores this separation, and its test merely checks that some results appear.
The test then confirms the implementation, not the requirement.
I would define important acceptance criteria before coding, covering denied access, missing information and failures as well as successful standard cases.
A passing test run matters, but must match the assignment.
The same applies to an agent's completion report: “Everything tested” is insufficient. I want to see the actual checks and results.
MCP and agent frameworks are tools, not cures
The Model Context Protocol standardises connections between AI applications and external data sources or tools. The specification used here is dated 28 July 2026. [7]
Appropriate access to project files or documentation can help more than pasting ever larger amounts of code into chat. It does not guarantee selection of the right files, complete understanding or correct code.
MCP makes neither context unlimited nor tests and permission controls unnecessary.
For a small project, I would not add an agent infrastructure without a concrete problem to solve. Larger environments need clearly bounded access and responsibilities.
More tools offer possibilities, but also setup and verification work.
How I would assess the benefit in my own team
Start with a manageable set of comparable tasks and define “finished” beforehand, including functionality, quality and documentation.
Record active working time, review, rework and later-discovered defects, not just generated changes.
Avoid assigning only easy tasks to AI and difficult ones to unaided work. Sequence matters too: solving a task once teaches part of the answer for the second attempt.
A business decision does not always need an academic study, but local measurements should be honest enough to disprove an expected benefit.
I would also agree a stopping rule. If an agent repeats the same wrong approach after several clear corrections, manual work is not a defeat; it may be the more economical choice.
My conclusion: Good AI assistance saves rework, not just typing
Research does not yield a simple “AI is faster” or “AI is slower”. Tasks, experience, tools and working environments can make a substantial difference.
I would not avoid AI altogether. I would use it where the assignment is bounded and the outcome reliably verifiable.
A system generating much code quickly has not yet earned praise for productivity. It becomes interesting when the change can be understood, tested and accepted with reasonable effort.
The best assistant is not the one that writes most, but the one that leaves the least unnecessary work before a usable result.
Scope and research
Research date: 11 October 2026. Studies, surveys and commercial analyses use different tasks and measurements. No general promise of time savings or quality loss. The calculation is fictional, not measured business data. General technical guidance, not individual legal advice.
Sources and further reading
[1] Original source
Read source ↗
[2] Original source
Read source ↗
[3] Original source
Read source ↗
[4] Original source
Read source ↗
[5] Original source
Read source ↗
[6] Original source
Read source ↗
[7] Original source
Read source ↗
[7] Original source
Read source ↗