In 2025, a research group called METR ran an experiment that should worry anyone who’s convinced AI made them faster at their job. They took 16 experienced developers, all deeply familiar with massive, real-world codebases (over a million lines of code, more than 22,000 GitHub stars), and gave them 246 real tasks to complete. Some tasks were done with AI tools allowed. Some were done manually. The assignment was random, so there was no way to game which tasks got the AI advantage.
Before the study started, the developers predicted AI would make them 24% faster. After finishing, they reported feeling 20% faster. The screen recordings and timestamps told a different story entirely.
They were 19% slower. Not faster**. Slower.**
That’s not a rounding error. That’s an entire experience of “this is working great” sitting on top of a result that was the opposite of great.
This is the part that actually matters, because it isn’t really about AI being bad. It’s about your brain being easy to fool in a specific, predictable way.
Writing code from scratch is effortful. You stare at a blank file, you look things up, you type every character yourself. It feels slow because it is effortful, and effort registers in your head as time passing.
Reviewing AI-generated code feels completely different. You’re not typing, you’re reading. Your brain classifies that as light work, almost restful, even when it actually eats just as much time, or more. The METR researchers found that AI tools got the easy 70% of a task right most of the time. That remaining 30%, the part with edge cases, security details, and quiet logic errors, still needed a human to catch it. Hunting that down took real, unglamorous time. It just didn’t feel like time, because it felt like reading instead of writing.
There’s a hidden cost buried in that switching, too. Jumping between “describe what I want in plain English” and “now go verify this line by line” is a genuine context switch, and researchers estimate it can take up to 23 minutes to fully recover deep focus after an interruption like that. Multiply that by every prompt-and-check cycle in a two-hour task, and the lost time adds up fast, invisibly.
Here’s where most people would stop the story, but METR didn’t stop there. In early 2026, they re-ran a larger version of the study: 57 developers, 143 repositories, over 800 tasks.
This time, the picture got murkier, and more honest.
That last point is the real twist. The people best at using AI were opting out of the very trials meant to measure it, which means even the improved numbers are probably still too generous.
Individual task speed is one thing. What happens across millions of lines of code, over years, is another question entirely, and the answer isn’t flattering.
A company called GitClear studied 211 million lines of code changes from 2020 through 2025 and found a clear shift in how software gets built once AI tools enter the picture:
Separately, an 800-developer study by Uplevel Data Labs found no meaningful improvement in how quickly finished code actually shipped, but did find a 41% increase in defects in AI-assisted pull requests. Google’s own DORA research told a similar story from a different angle: pull request volume jumped by as much as 98%, but the time it took to review each one rose by 441%, and production incidents per pull request tripled.
Put simply, the bottleneck didn’t disappear. It moved. Writing code got faster. Making sure that code was actually correct, safe, and maintainable got dramatically slower.
There’s a separate study, this one from Anthropic, that points at something even harder to reverse than a slow pull request queue.
Researchers had 52 junior developers learn an unfamiliar programming library, half manually, half with AI help, then tested everyone’s understanding afterward with no AI allowed.
The group that used AI finished the initial task about two minutes faster, a difference so small it wasn’t statistically meaningful. But on the follow-up quiz testing real comprehension, the AI-assisted group scored 17% lower, roughly two letter grades. The steepest drop showed up specifically in debugging, the exact skill you need most once something goes wrong in production.
One detail matters more than the headline number: how someone used the AI changed everything. Developers who asked the AI to explain concepts still scored well, generally 65% or higher. Developers who just let the AI generate the code for them scored under 40%. Same tool. Completely different outcome, depending on whether it was used to think, or used instead of thinking.
This isn’t just a productivity story anymore. Stanford’s own payroll data, tracking millions of workers, found that employment for software developers aged 22 to 25 has dropped almost 20% since late 2022.
Part of that is likely companies assuming AI lets senior engineers absorb more work, so they’ve quietly cut entry-level hiring. Which creates a strange, closed loop: fewer juniors get hired, the juniors who are hired lean on AI and build shallower debugging skills, and the pipeline that normally produces experienced senior engineers gets thinner every year that continues.
None of this means throw the tools out. It means using them without noticing the trade-offs is the actual mistake. A few things the research points toward:
Match the tool to the task. AI genuinely helps in unfamiliar territory, boilerplate, new languages, greenfield projects. It struggles most exactly where your own expertise is already strongest, on code you know cold. That’s precisely where it adds friction instead of removing it.
Track time, not feeling. Your sense of “that felt fast” is measurably unreliable. If you want to know whether AI is actually saving you time on a given kind of task, time yourself for a week instead of trusting the vibe.
Use it to explain, not just to generate. The Anthropic study found this was the single biggest factor separating people who kept their skills sharp from people who didn’t. Ask it to walk you through the “why,” not just hand you the “what.”
Budget real time for review, on purpose. If AI-written code carries a higher defect rate and a much longer review cycle, pretending review is free is how technical debt quietly piles up. Plan for it like it’s part of the job, because it is.
The tools aren’t the problem. Believing your own sense of speed without ever checking it against reality is the problem, and that’s a much older, much more human mistake than anything AI introduced.
You Think AI Made You a Faster Coder. A New Study Says You’re Wrong. was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.