Holly Chambers
Last month, I completed a feature in what felt like record time using Claude. Shipped it, felt great. Then I read the METR study that dropped in July 2025: developers using AI actually took 19% longer to finish comparable tasks, despite swearing they were faster. I checked my Git history. They were right about me.
The Confidence Gap Is Real (And It's Lying to You)
Here's the paradox that should make every developer uncomfortable: nearly all of us are using AI coding tools now, but almost none of us think they actually work. According to Stack Overflow's 2025 Developer Survey, 84% of developers use or plan to use AI tools. Yet when asked if these tools made them significantly more productive, only a fraction said yes. The majority reported minimal impact. (Stack Overflow, 2025)
The METR randomized controlled trial was ruthless about this. Sixteen experienced developers across 246 real tasks: those using AI tools took 19% longer to complete work than those without. But subjectively? The AI users felt roughly 20% faster. (METR, 2025) That's not a minor discrepancy. That's a complete disconnect between perception and reality.
I know exactly what happened to me. Claude would autocomplete a function signature, I'd hit accept, then autocomplete the body, accept again, and boom—a function written in 30 seconds instead of three minutes. Dopamine hit. Progress bar moving. But then the code review cycle began, the edge cases surfaced, the security questions arrived, and suddenly that 30-second save had cost me two hours of rework.
Why Your Brain Thinks AI Made You Better
The mechanics are straightforward: AI reduces cognitive load on syntax. You stop thinking about bracket placement and boilerplate structure. Your brain gets to rest. That feels incredible. It feels like productivity. It is not productivity.
What's actually happening is a hidden tax spreading across the development process. GitClear analyzed 211 million changed lines of code and found AI-generated code had dramatically higher churn—revisions within two weeks—and an eightfold increase in duplicated code blocks. (GitClear, 2024) More code means more review time. More duplicates mean more technical debt.
The real cost isn't in the coding time. It's in what comes after. Code review times have shifted. PR cycles take longer. Engineers spend more hours auditing generated code they didn't write. And here's the thing nobody wants to admit: the code they don't write is the code they don't understand.
Developers feel productive because AI gives immediate positive feedback. But that feedback is divorced from actual problem-solving. You're building muscle memory for clicking accept, not for becoming a better engineer. The psychological sensation of progress is real. The actual progress is questionable.
The Code Quality Tax Nobody Mentions in Sales Calls
Let's talk about what ships when you accept AI-generated code without friction. CodeRabbit found AI-authored pull requests contained 1.7 times more major issues and 2.74 times more security vulnerabilities compared to human-written code. (CodeRabbit, 2024-2025)
Let that land for a second. You're not just shipping faster. You're shipping less safe code. And if you're a junior developer, you're the one whose name is on the commit. The architect who approved it is three layers up the chain.
The vulnerability spike hits harder when you realize that 48% of AI-generated code contains security vulnerabilities at some level. (Second Talent, 2025) That's not edge cases or theoretical concerns. That's nearly half of what you ship having a measurable security issue. Some will be caught in review. Many won't.
GitClear's finding on code churn tells a different story about maintainability. High-quality code doesn't need rewrites in two weeks. But code that's autocompleted without understanding context does. You're building systems you don't fully own, which means you can't fully defend them in a meeting later.
The 10x Myth Became a 2x Myth (And It's Worse)
Nobody talks about the 10x developer anymore. That myth died. But it's been replaced by something almost as dangerous: the 2x myth. Coding is only 20-30% of actual developer work. That means even if AI makes you 10 times faster at writing code, your overall productivity bump is closer to 1.2x. (Paddo.dev, 2026)
Six independent research efforts across 2025-2026 converge on roughly 10% organizational productivity gains at best. That's accounting for everything: coding speed, review overhead, bug fixes, documentation, architectural thinking, and mentoring. It's not nothing. It's also not transformative.
But here's where the danger lives: your employer heard "2x faster coding" from a vendor demo and is expecting you to deliver 2x productivity on Day 1 of your job. You can't. The gap between vendor promise and reality is where junior developers get trapped. You ship fast, expectations aren't met, and suddenly you're blamed for a tool limitation.
Here's What I Actually Use AI For (And When I Deliberately Don't)
I'm not anti-AI. I use it constantly. But I've learned to be surgical about when and how.
Boilerplate? AI wins every time. Scaffolding test files? Yes. Documentation that needs to exist but nobody wants to write? Absolutely. These tasks are high-ROI. The code is replaceable, the pattern is clear, and you can validate the output in seconds. I accept these with minimal friction.
Logic? Architecture decisions? Security-critical code? I deliberate stay engaged. I read every line. I don't trust the AI to understand the context or the consequences. I use it as a spellcheck, not as a code generator. And sometimes I deliberately turn it off. On one project, I refused AI assistance for two weeks while designing a database schema. Halfway through manual sketching, I caught a normalization issue that Claude would have baked in. That problem would have cost weeks of rework in production. The discipline of struggling through the hard part matters.
The developers worth hiring in five years won't be the ones who ship fastest. They'll be the ones who know what they shipped and why it matters.
The Real Edge: Understanding Why
Here's what the productivity data misses: the people who will matter in 2027 are learning differently than the ones relying on AI for everything.
An engineer who understands the fundamentals—why a particular algorithm works, what security issues matter, how to design for maintainability—can use AI as a use tool. They can prompt effectively because they know what good looks like. They can audit the code they don't write because they understand the problem domain.
An engineer who learned by accepting autocompletes has a harder time. They've built pattern recognition, not systems thinking. When the AI fails, they have no mental model to fall back on. When the problem is novel, they're stuck. And when they're leading a team five years from now, they'll have a harder time mentoring people who actually understand how software works.
Maintainability and security represent roughly 70% of a developer's real job value. AI is not particularly good at either. It's good at the narrow 20-30% that's pure code generation. The compound advantage goes to people who stay engaged on the hard parts.
What I'd Tell My 22-Year-Old Self
If I could go back and give myself advice, it would be straightforward:
Use AI aggressively for the boring parts. Boilerplate exists to be automated. You're not learning anything by typing the same function signature for the hundredth time. Skip it. But stay deliberately engaged on the hard parts. When you're stuck on a problem, sit with it. Struggle with it. That's where your brain actually grows.
Audit the code you don't write. If you used AI to generate a function, read it. Understand it. Could it fail? Would you write it differently? If you can't answer those questions, you don't understand what you shipped.
Learn security fundamentals before you inherit production systems. Forty-eight percent of AI code has vulnerabilities. You might not write the vulnerability, but you might be the person responsible for fixing it at 2 AM when a customer finds it. Know what you're looking for.
Remember this: the developers worth keeping are the ones who can explain their decisions. Not the ones who can generate the most commits. In a room with your peers in five years, the people who understand the why will have options. The ones who learned to prompt-spam will be waiting for the next tool to make them feel productive again.
The Real Question Isn't Whether to Use AI
AI coding tools aren't going anywhere. And honestly, they shouldn't. They're useful for exactly what they're good at: making boilerplate faster, scaffolding test files, and writing documentation.
But the real question isn't whether you'll use them. It's whether you'll use them as a crutch or as a lever. The lever-users—the ones who stay engaged on logic, who question the code they don't write, who understand security—those are the people companies will actually want to keep around. The ones who learn the tool instead of learning the craft will always be one tool behind.
The 19% slowdown from METR hit me because I was treating AI like it was magic instead of like it was a tool. Once I started being intentional about when I used it and when I stayed engaged, the calculus shifted. I'm not faster in absolute terms. But I understand what I shipped. That matters more than it feels like it should.
