Feels 20% Faster, Is Actually 19% Slower: Most People Get the Math of AI Coding Wrong
In a randomized controlled trial, experienced programmers using AI to write code felt 20% faster, but were actually 19% slower. The problem isn't AI—it's that most people aren't measuring it at all, and you can't manage what you don't measure.
Hacker News in 2026 is not what it was a year ago. A year ago, the feed was full of "AI coding will replace programmers." This year, the top-voted discussions are doing a different kind of math: once you count the hidden costs—review, rework, maintenance, debugging after mistakes—does AI programming actually help teams ship faster? The hype is leaving the stage, and the ledger is taking its place. That's a good thing.
Let me start with the one number that most deserves to be remembered. In 2025, an independent research organization called METR ran a randomized controlled trial—tasks randomly split into two groups, one allowed to use AI and the other not, then results compared; it's the strictest method, the one used to test drugs in medicine. They recruited 16 senior open-source developers to handle 246 real tasks in large projects they had maintained for years, with millions of lines of code. Before starting, these developers predicted AI would save them 24% of their time. After finishing, their subjective impression was "AI made me about 20% faster." The measured result: they were 19% slower.
Notice the strange trap among those three numbers: predicted 24% faster, felt 20% faster afterward, actually 19% slower. The most dangerous part isn't the 19% slowdown—it's the nearly 40-percentage-point perception gap: people were slowing down while sincerely believing they were getting faster.
Many people will see that headline and want to shout, "See? AI is useless." That's a misreading—and one that will lead you to bad decisions. The trial's design contains a key limitation: the subjects were senior developers who knew their own code inside out, working in mature projects they had maintained for years. This is precisely the scenario where AI should least be expected to speed things up.
Because in code you know well enough to write with your eyes closed, your bottleneck was never typing speed—it's the map in your head. The solution is already formed in your mind; typing it out is just a matter of hand speed. When you have AI write a first version in that situation, you have to read it, understand it, find its mistakes, and rewrite it back to what you already wanted. That entire cycle of review and rework is a tax added out of thin air. AI didn't help you skip thinking; it gave you an extra proofreading exercise.
So when does AI actually speed things up? The answer lies in the flip side of the same mechanism: the larger the knowledge gap between you and the code, the more valuable AI becomes. Unfamiliar tech stacks, frameworks you've never touched, prototypes started from scratch, the kind of boilerplate nobody wants to hand-write—in these scenarios you'd already be searching, experimenting, and stepping into traps. AI shortens the most grinding part: "reading docs, trial and error, writing glue code." The bigger the gap, the more time saved; the smaller the gap, the more it gets in the way.
Turn that judgment into a sentence for bosses and investors: the return on AI programming doesn't depend on how powerful the model is—it depends on which side of the knowledge gap you place it on. If you push AI across the board on the modules your most senior, most knowledgeable people know best, and then wonder why there's no speedup—you've placed your bet in the wrong place. Where AI should really be used is when newcomers take on unfamiliar modules, when you're exploring directions no one has tried, when you need a one-off rapid validation. The same tool is an accelerator in the right place and a cognitive tax in the wrong place.
But what this article really wants you to take away isn't where AI should be placed—it's that nearly 40-percentage-point gap itself.
It tells you one thing: when it comes to whether you've actually gotten faster, human perception cannot be trusted. These subjects weren't novices or outsiders; they were the people who knew their projects best, and they collectively got the direction wrong. The people on your team are the same—they will sincerely tell you AI has made them quite a bit faster, and that statement may be nearly 40 percentage points away from reality. If your AI strategy is built on the feeling that "everyone says it's much faster," you're using an unreliable instrument to make major investment decisions.
I ship with AI every day myself, but I never trust the phrase "it feels faster." I track cycle time—how long it actually takes from start to delivery—not whether it feels good. This isn't distrust of AI; precisely because I depend on it so heavily, I'm even less willing to replace measurement with subjective feeling. METR itself knows this isn't settled—in early 2026 they were still publicly adjusting the trial's design and continuing to test. A question that even a research organization is still repeatedly calibrating is one that companies often decide with a simple "it feels much faster." That itself is the answer.
Whether AI coding is actually faster is a real question. But the more important question is: are you measuring it? If you don't measure, you're left betting on subjective feeling—and this trial has already shown that feeling lies, even experts' feelings lie.