What actually gets faster with AI-assisted development, and what does not

The claims and the numbers

Vendors say three to five times faster. Controlled experiments say a fifth to a half, on one task. One careful study says slower. All of them are measuring different things, and the differences are the whole story.

GitHub's controlled experiment had 95 developers write an HTTP server, and the half with an assistant finished 55% faster. Google ran a randomized trial with 96 of its own engineers on a realistic enterprise task and measured about 21% faster. The 2024 DORA report found that a 25% increase in AI adoption went with 1.5% lower delivery throughput and 7.2% lower stability, even though three quarters of respondents said they were personally more productive. And METR, in a randomized trial with experienced open-source developers working on their own large codebases, found the developers were 19% slower with AI tools while believing they had been 20% faster.

None of these contradict each other. Isolated, well-specified tasks get much faster. End-to-end delivery moves much less, because most of a project is not typing, and a team that ships bigger batches because code got cheap can end up slower and less stable. Expert engineers in codebases they know intimately can get slower still, because the assistant knows the codebase less well than they do and reviewing its output costs more than writing it would have. Add Veracode's finding that about 45% of AI-generated code samples contained a security flaw, and the picture becomes clear. The speed is real, conditional, and easy to spend on the wrong things.

What gets faster

Scaffolding and boilerplate gain first. The new screen, the new endpoint and the new module arrive in the shape the codebase already uses. Tests gain more than anything else, because writing the cases nobody wanted to write is where assistants earn their keep. Repetitive migrations, the same change applied across forty files, gain as well. So do documentation and first drafts of everything, from a pull request description to an architecture note, and so does understanding an unfamiliar codebase, where an assistant that has read all of it answers in seconds what used to take a morning of searching.

All of these share the same conditions. The work is well specified, the result is easy to check, and getting it slightly wrong is cheap.

What does not

Deciding what to build, and why, does not get faster. Neither does architecture, where the decisions are expensive to change later and the assistant will make them differently every time it is asked. Review becomes the bottleneck the moment code arrives faster than people can read it. Quality assurance, coordination between people, releases and the conversations with the client move at their previous pace, and that list is most of a project's calendar.

There is also a cost that does not show up in a sprint. Engineers who never make the intermediate mistakes learn less from the work. A team that accepts what it cannot explain is accumulating a codebase it does not understand, and that bill comes due at the first serious incident.

The practices that make the speed real

The projects where the gains hold share a set of habits, and they are not about the tools.

Write it down first. A requirements note, an architecture decision and acceptance criteria come before the prompt. Assistants are only as good as the specification, and a vague task produces confident nonsense at speed.

Tests before code, or at least alongside it. The test is the specification the assistant cannot argue with, and it is the thing that makes fast output safe to accept.

Small tasks. An assistant asked for a feature produces a guess. Asked for one well-bounded step, it produces something reviewable.

Review against proof, not prose. The output is accepted because the tests ran and the logs say what happened, not because the explanation sounded right.

A second engineer on every change, with automated tests and CI that block what fails, security scanning in the pipeline, and staged environments so nothing is tried on production. These were good practice before assistants. With assistants they are the difference between speed and churn.

Keep the agent away from the sharp edges. We keep agents off critical migrations, cryptography and ambiguous requirements.

Where it goes wrong

Accepting without reading is vibe coding by another name. Letting review become the bottleneck without changing how review works is another failure, as is measuring commits instead of outcomes, because more code produced faster is not the same as more product. Believing the perception is the last one. The METR developers were sure they were faster.

What we see on our own projects

Our engineers use AI coding assistants every day, whether Claude Code, Cursor or Copilot, according to what fits the work. We have not published a productivity number, and we distrust the ones that come without a method. What we can say is where the time goes now. Less goes to scaffolding, tests and repetitive changes, and as much as before goes to decisions, review and the parts of the work that involve other people. The quality gates have not moved. A second engineer reviews every change, tests and CI run on every one, and monitoring is in place before launch.

What this means for a client

Clients see faster first versions, and faster releases after them, on the parts of the work that were mechanical. It is not magic, and it is not a discount on judgment. If an agency promises a multiple, ask what exactly got faster, how it was measured and what did not change. The honest answers to those questions are the ones in this article, and they are the basis on which WeaveLines builds software today.