AI-assisted development: what actually gets faster, 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. And expert engineers in codebases they know intimately can get slower, 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 is clear: the speed is real, conditional, and easy to spend on the wrong things.

What gets faster

Scaffolding and boilerplate: the new screen, the new endpoint, the new module, produced in the shape the codebase already uses. Tests, more than anything else; writing the cases nobody wanted to write is where assistants earn their keep. Repetitive migrations: the same change across forty files. Documentation and first drafts of everything, from a pull request description to an architecture note. Understanding an unfamiliar codebase, where an assistant that has read all of it answers in seconds what used to take a morning of grepping.

Common to all of these: 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. Architecture: the decisions that are expensive to change later and that the assistant will make differently every time it is asked. Review, which becomes the bottleneck the moment code arrives faster than people can read it. Quality assurance, coordination between people, releases, the conversations with the client. 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, acceptance criteria. 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, which is vibe coding by another name. Letting review become the bottleneck without changing how review works. Measuring commits instead of outcomes: more code, faster, is not the same as more product. And believing the perception; the METR developers were sure they were faster.

What we see on our own projects

Our engineers use AI coding assistants every day: Claude Code, Cursor, Copilot, whichever 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 on scaffolding, tests and repetitive changes, the same on 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

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