AI Is Making You a Worse Coder. That’s Not the Whole Story.#
There’s a genre of think-piece doing the rounds right now. The argument goes something like: AI coding tools are making engineers worse. We’re writing less code, so we’re getting rusty. Our skills are atrophying. We’re becoming dependent.
I get it. And it’s not entirely wrong. If you spend six months barely touching a keyboard and let Claude write everything, yes, some things will get rusty. That’s just how skills work.
But the conclusion people are drawing from this, that AI coding is net-negative for engineers, misses something important about what engineering actually is.
The PR That Made Me Think About This#
A few days ago I was reviewing a pull request generated by Claude Code. And I was getting annoyed.
The code worked. Functionally it was fine. But it wasn’t good. It didn’t follow our style conventions. There was a function defined with a leading underscore, which signals “internal, don’t touch,” and then it was imported and called from somewhere else entirely. Valid Python. Sloppy engineering.
I tore that PR apart. Left comments. Flagged the style drift. Pushed back on the design choice. Basically treated it the way I’d treat a PR from a junior engineer who was smart enough to make something run but hadn’t fully internalized the team’s standards yet.
And then I stopped and realized: this is exactly what a tech lead does.
That’s when it clicked for me about where engineering is actually going.
The Skill You Forget You Had to Learn#
When you first learn to program, you write code. That’s the job. Write the function, make it work, move on.
Then you join a real team and everything changes. Suddenly there’s a codebase you didn’t build. Patterns you didn’t choose. A PR queue full of other people’s decisions, and your job isn’t just to write anymore. It’s to read. To understand code you didn’t author and decide whether it belongs in the system.
That transition is genuinely hard. Reading unfamiliar code is a different skill from writing it. It requires a broader mental model of the system, a real sense of what good looks like in that specific codebase, and the confidence to push back when something is off even if it technically compiles.
Nobody ever said that learning to read and review code was a sign of deskilling. We called it a level up.
AI-assisted engineering is that same transition, happening to everyone at the same time.
The Tech Lead Parallel#
Think about what senior engineers and tech leads actually spend their time doing. They review a lot more code than they write. They make architectural decisions. They set standards, catch problems before they ship, and ask the questions that less experienced engineers haven’t thought to ask yet.
We don’t say tech leads are losing their coding skills because they spend more time in review than in an editor. We say they’ve developed judgment.
That’s what’s happening now. The ratio is shifting. You write less, you review more. The thing you’re reviewing is AI-generated instead of colleague-generated, but the mental work is the same: reading code you didn’t write, applying your experience and standards, and deciding whether it’s good enough to ship.
In my own work I’m spending considerably less time writing code and a lot more time thinking about whether the approach is right, whether the abstraction makes sense, whether the thing the AI built is actually what I asked for. That’s not atrophy. That’s just the job changing.
The Honest Caveat#
None of this applies if you’re not actually reviewing the output.
There’s a version of AI-assisted engineering that genuinely is deskilling, where you describe what you want, accept whatever comes back, run it, and ship it if the tests pass. That’s not a new kind of tech lead. That’s just careless.
The frustration I felt reading that Claude Code PR mattered. It meant my standards were intact. An engineer who’s truly checked out doesn’t notice the underscore leak. They don’t care that the function naming is inconsistent or that the abstraction doesn’t fit the existing patterns. They just merge.
The risk isn’t AI. It’s complacency, and that was already a problem before any of this. Engineers have always been capable of rubber-stamping bad code. The tools changed. The discipline required didn’t.
Trusting Your Past Self#
There’s something else here that doesn’t get talked about enough.
When you review code carefully, even code you didn’t write, you can trust it. Not because you could recite every line from memory, but because you remember thinking hard about it. You remember making a decision about it. That’s always been true of large codebases. You wrote something two years ago and you trust it not because you can reconstruct it on demand, but because past-you cared enough to get it right.
The same logic applies to AI-generated code you’ve reviewed with real attention. Will bugs slip through? Yes. They did before too, when every line was written by hand. The question was never whether the process is perfect. It’s whether you engaged seriously with what you shipped.
What This Means Going Forward#
The direction seems pretty clear: code generation is commoditizing. Judgment isn’t.
Knowing what to build, knowing when the AI got it wrong, knowing why a clean-looking abstraction is going to cause pain six months from now, knowing when to push back on your own requirements because the problem you described isn’t actually the problem you have. Those things don’t come from writing code. They come from years of writing code, dealing with the fallout, and developing a feel for the difference between something that works and something that’s right.
Engineers who treat AI as a replacement for thinking are going to struggle. The ones who treat it like a fast junior engineer, capable but needs supervision, are going to find their experience matters more than it did before.
Your skills aren’t going anywhere. You’re just being asked to use them differently.