Introduction
The optimism of starting a career in software engineering is grounded in one very specific moment: when a problem gets solved with your own hands, when the solution your brain came up with takes shape in some programming language and actually works. That high is the starter drug. Then the optimism slowly erodes when you've spent 30 hours reviewing something you wrote that runs — but doesn't do what it should. And it dies completely when the code you're reviewing isn't even yours anymore.
Today, AI has taken the part that filled your heart with joy, and left you the awful part: reviewing and fixing.
And still, the industry keeps repeating that we're 55% faster.
Context
The number everyone repeats — "GitHub Copilot makes you 55% faster" — comes from a GitHub and Accenture experiment with 4,800 devs on one bounded task: implementing an HTTP server in JavaScript. No output quality assessment. No test coverage check. No verification that the code would survive production. Participants knew they were being timed. It's real data, but it's not the data that justifies eight-figure licensing deals.
Meanwhile, in 2025, METR (Model Evaluation & Threat Research) ran a randomized controlled trial with experienced developers, on their own repositories, doing real tasks. The result was counterintuitive: devs using AI took 19% longer than without it. They believed they had been 20% faster. METR itself published an update in February 2026 with a larger cohort: the slowdown shrank to roughly -4%, with a confidence interval from -15% to +9%. Honest translation: the effect is ambiguous, but it's definitely not the "56% faster" on the CTO's slide. And an NBER paper from February 2026, surveying nearly 6,000 executives, found that over 80% of firms reported AI had no measurable productivity impact over the prior three years.
The stance: we're paying subscriptions to feel productive
My thesis is direct: AI coding tools, on complex tasks in real contexts (not demos), do not make you significantly faster. What they do is generate such a convincing feeling of speed that decisions get made on that feeling, not on the evidence.
But I want to add nuance here, because this is where it gets interesting. There may not even be a real time saving for companies. When you work with an agent handling coding tasks, the clock keeps ticking — the agent takes however long it takes. The difference is that this time is no longer your time: it's space for a coffee, a few reels, a class, or reading this blog post. The company doesn't necessarily get fewer code-hours. You get your life back, in asynchronous crumbs.
That's real. And it's worth something. But it isn't what's being sold in the pitch decks.
Arguments
1. The "almost correct" code problem. According to the 2025 Stack Overflow Developer Survey, the biggest frustration for developers is dealing with AI solutions that look right but are subtly wrong. Nearly half say debugging that code takes longer than writing it themselves. When you write code, you build a mental model of every variable. When you review generated code, you have to reconstruct that model from the outside — and the cognitive cost is brutal. The exact part that burned you out at the end of your career, reviewing code that isn't yours, is the part AI just multiplied.
2. The illusion of speed is structural. In the METR study, participants predicted 24% speedup beforehand, reported 20% afterward, and were measured at 19% slowdown in reality. The gap between perception and measurement was nearly 40 points. This isn't anecdotal: it's a systematic cognitive bias. When a tool gives you instant feedback (text appearing), your brain registers "progress," even if you then spend half an hour fixing it.
3. The celebrated metrics measure the wrong thing. "88% of accepted suggestions stay in the commit" doesn't mean the code is good. It means the dev accepted it. Longitudinal research on real commits shows heavy AI users generate between 4x and 10x more non-durable code — code that requires refactoring or gets deleted soon after. Output velocity is not delivery velocity.
4. Review is the bottleneck, not writing. Generating code was never the expensive problem. The expensive problems were always understanding it, maintaining it, debugging it. AI optimizes the cheap step and multiplies the expensive one. It's like giving a paint sprayer to someone who has to color inside the lines: faster at first, slower at the end.
5. Prompt engineering is the line between hate and utility. Here's the nuance missing from most "anti-AI" takes: reducing the review effort requires experience and common sense. Prompt engineering — and, more honestly, knowing what to ask for, what not to ask for, and how to scope the context — is the difference between hating AI or treating it as a great junior dev. A good junior, not a great one. One that needs supervision. That occasionally surprises you. That should never push to production without someone with gray hair reviewing. And here's the problem: companies are treating it like a senior.
Closing
None of this means throw Cursor in the trash. It means stop making organizational decisions based on how the tool feels. Measure your own time. Compare, without cheating, equivalent tasks with and without AI. You'll be surprised — in both directions.
AI didn't take our jobs. It took the best part of the job and left us the worst, with the promise of a speedup that doesn't show up in the macro data. In exchange, it gave us asynchronous pauses to grab coffee. It's a weird trade-off, and I'm not sure we're talking about it honestly.
Have you actually measured your real productivity, or are you defending a tool because you like how it makes you feel while you wait for its output?
Top comments (0)