AI Coding Assistants and the Myth of the 10x Developer

There are two conversations happening about AI coding assistants, and they barely overlap. One is happening among developers who actually use them, where the verdict is a shrug of qualified approval: good at boilerplate, good at the tedious middle, occasionally brilliant, occasionally confidently wrong in ways that cost an afternoon. The other is happening on stage and in press releases, where every tool now makes engineers “10x” more productive and the end of programming as a profession is always eighteen months away.

We would like to gently reunite these two conversations.

Where the tools genuinely earn their keep

Let us be fair before we are grumpy. Modern assistants — Copilot, Cursor, and the growing pile of imitators — are legitimately good at a specific and valuable thing: predicting the next boring bit of code you were about to type anyway. Filling in a switch statement. Writing the obvious test. Translating a snippet from one language to another. Generating the fortieth variation of a data model you have already designed in your head.

For that work, the tools save real time and real irritation, and any developer pretending otherwise is posturing. The value is real. It is just not revolutionary, and the difference matters when someone is asking you to change how your entire team works and pay per seat for the privilege.

The 10x number nobody can find

The marketing rests on productivity multipliers — 30% faster here, 55% faster there, task-completion figures that make good slides. The trouble is that these numbers almost always come from tightly scoped studies measuring how quickly someone finishes an isolated, well-defined task in a controlled setting. Real software work is not an isolated, well-defined task. It is mostly understanding an existing system, deciding what not to build, and reading code rather than writing it.

When independent researchers have looked at experienced developers working on mature codebases they know well, the picture gets less flattering: at least one 2025 randomised study found seasoned open-source maintainers were actually a little slower with AI assistance, even though they believed they had been faster. That gap — measurable slowdown, perceived speedup — is the most honest data point in the entire field, and it is the one you will never see on a billboard.

The skill that quietly atrophies

There is a longer-term cost that no quarterly productivity metric will ever capture: what happens to the developer. A great deal of engineering skill is built by struggling through problems — sitting with a confusing bug, reading unfamiliar source, working out from first principles why the obvious approach is wrong. When an assistant hands you a plausible answer instantly, the struggle is skipped, and so is the learning that the struggle produces. The senior engineer who already has that judgement is fine; the junior who is outsourcing the formative pain is quietly not acquiring it.

This is not a call to make people suffer for its own sake. It is an observation that a tool which removes the friction of understanding also removes the mechanism by which understanding was built. A team that leans hard on generation may ship faster this year and find, a few years on, that its developers are excellent at prompting and shaky on the fundamentals that let them tell when the prompt produced nonsense. The tool is most valuable in the hands of someone who could have written the code themselves and least safe in the hands of someone who could not — which is precisely the inverse of how it is marketed.

The maintenance bill arrives later

Generated code has a particular smell. It works, it passes the happy-path test, and it quietly does slightly the wrong thing at the edges. It hardcodes an assumption. It reimplements a helper that already existed three files over. It swallows an error because swallowing the error made the example compile. None of this shows up in a task-completion benchmark, because benchmarks end the moment the task is completed. Your codebase does not.

The result is a subtle transfer of effort: writing gets cheaper and reviewing gets more expensive. Anyone who has reviewed a large AI-assisted pull request knows the specific fatigue of it — code that is plausible enough to lull you and wrong enough to bite you, in volumes a human would never have produced by hand.

Who the productivity actually accrues to

Here is the pro-consumer point. Even where the tools do make you faster, it is worth asking who captures that surplus. If you are a contractor billing by the hour, faster is money in your pocket. If you are a salaried engineer, faster mostly means the same salary and a higher expected output, plus a per-seat licence your employer now pays on your behalf and will absolutely mention in your next review. The productivity narrative is aimed at the person buying the seats, not the person filling it.

A reasonable position to hold

You can believe all of the following at once, and we do:

• AI assistants are a useful, permanent addition to the toolbox.
• They are excellent at boilerplate and mediocre-to-dangerous at anything requiring architectural judgement.
• The productivity multipliers in the marketing are, at best, measured under conditions that do not resemble your job.
• The person most confident that these tools have made them 10x faster is usually the person you least want reviewing your database migration.

The review bottleneck moves; it does not disappear

The productivity pitch quietly assumes that writing code is the constraint. For most teams it is not. The constraint is review, integration, and the slow human work of agreeing that a change is correct and safe to ship. Generation makes the cheap part cheaper and leaves the expensive part exactly where it was — except now there is more code arriving at it, faster, produced by something that does not understand the system it is editing. You have not removed the bottleneck. You have widened the pipe feeding it.

This is why teams that adopt these tools enthusiastically often report a strange non-result: everyone feels faster, velocity dashboards twitch upward, and yet nothing actually ships sooner. The gains at the keyboard are eaten by the losses at the review desk, where a human now has to read more, trust less, and hunt for the subtle wrong thing that compiled cleanly and passed the happy-path test. The work was not eliminated. It was moved downstream and made harder to see, which is the kind of efficiency that looks great until you measure the thing you actually care about, which is working software in front of users.

What the honest version of the pitch would say

Strip the marketing and a fair advertisement for these tools would read: “Writes your boilerplate quickly. Excellent at the tedious middle. Will confidently produce plausible, subtly wrong code that you must review line by line. Most valuable to experts who could do the work themselves and most dangerous to beginners who cannot tell when it is wrong. Does not understand your codebase. Will not make a bad engineer good, but will make a good engineer a bit faster at the boring parts.” That is a genuinely useful product. It is also a much smaller claim than the one on the billboard, and the gap between the two is where the disappointment — and the maintenance debt — lives.

None of this is an argument against the tools. It is an argument for buying them with clear eyes: as a very fast, very confident junior who never learns your system and never takes responsibility, rather than as the tenfold revolution that justifies restructuring your team around it. Priced honestly, that is still worth the seat. Priced as a workforce multiplier, it is a story someone needs you to believe in order to sell you more seats.

Measure the thing you actually want

If your team is going to spend money and change habits around these tools, measure the outcome that matters rather than the one that flatters. Lines of code written, tasks “completed” in a study, or the warm subjective sense that everyone is moving faster are all easy to collect and largely beside the point. The questions worth asking are harder: did features reach users sooner, did defects go up or down, did the time from idea to shipped-and-stable shrink, and is the codebase easier or harder to work in six months on. Those are the numbers that decide whether the tool paid for itself, and they are conspicuously absent from the marketing precisely because they are the ones that resist a tidy multiplier.

Run that measurement honestly and most teams land in the same unglamorous place: a real but modest gain, concentrated in specific kinds of work, entirely dependent on the skill of the person driving. That is a perfectly good result. It justifies the tool without justifying the mythology. The danger is not adopting AI assistance; it is adopting the story that comes bundled with it — the one where writing code was the bottleneck, the multiplier is real, and the sensible response is to expect more output from fewer people. Buy the tool, skip the story, and keep counting the only thing that was ever the point: working software, in front of users, that someone can still maintain next year.

Use the autocomplete. It is good. Just keep your hand on the wheel, read every line as if a very fast, very confident junior wrote it — because one did — and treat the tenfold-productivity claim with the same scepticism you would treat any other number a vendor needs you to believe in order to renew.