A developer posted on Reddit recently that they forgot how to implement a Laravel API. Not something exotic. A basic REST endpoint. The kind of thing they'd done hundreds of times before. "I went to university for this," they wrote. "I've been a software engineer for many years now and it feels like I am back before I ever wrote a single line of code."
This isn't an isolated anecdote. 404 Media ran the headline "Software Developers Say AI Is Rotting Their Brains" last week. The piece is full of engineers saying the same thing in different words: something is slipping away from them, and they only notice when the AI isn't there to catch them.
The conversation usually frames this as "skill atrophy." Like forgetting phone numbers after smartphones. A minor inconvenience. You can always look it up again.
That framing is dangerously wrong.
It's not about writing, it's about reading
The skill you're losing isn't the ability to write code. You can still type. You can still read documentation. You can still scaffold a project from memory if someone puts a gun to your head.
What you're losing is the ability to read code critically. To look at a function and feel, before you've even traced the logic, that something is off. That instinct isn't magic. It's pattern recognition built through thousands of hours of writing bugs, finding them, and understanding why they happened.
When you stop writing bugs, you stop building that instinct.
Anthropic published a study earlier this year that makes this concrete. They gave 52 engineers a new library to learn. Half used AI assistance. Half coded manually. Then they tested comprehension.
The AI group scored 17% lower overall. But here's the part that matters: the largest gap was on debugging questions. Not syntax. Not API recall. Debugging. The specific skill of looking at code and understanding why it's wrong.
The developers who let the AI write their code couldn't spot the problems in it.
Why reviewing isn't the same as writing
There's a common defence: "I still review all the AI's output." As if reading code after the fact builds the same muscles as writing it yourself.
It doesn't.
When you write code, you build a mental model of intent. You know why each line is there because you put it there. You know which edge cases you considered and which ones you punted on. You know where the dragons live because you walked through the forest yourself.
When you review code someone else wrote, whether that's a colleague or an AI, you're pattern-matching against experience. But if you stopped building that experience six months ago, your pattern library is frozen. You're reading with yesterday's eyes.
This is why I keep coming back to the same principle: if you can't explain what the code does without reading it line by line, you shouldn't have accepted it. Not because the AI got it wrong. But because you can't tell whether it did.
The 43% problem
A 2026 Lightrun survey found that 43% of AI-generated code changes need manual debugging in production. Not in testing. In production. After passing QA and staging.
Think about what that means. These aren't obvious bugs. They pass tests. They pass code review. They look correct. They only break under real-world conditions that nobody anticipated because nobody understood the code well enough to anticipate them.
The brilliant parrot writes plausible code. Code that looks right. Code that passes the smell test of a reviewer who didn't write it. But plausible isn't correct. And if your debugging instincts have atrophied, you won't catch the difference until your pager goes off at 3am.
This is how lava layers form. Not through obviously bad code, but through code that's subtly wrong in ways that nobody on the team can diagnose anymore.
The autopilot problem
Aviation figured this out decades ago. Pilots who rely too heavily on autopilot lose situational awareness. They respond slower to emergencies. They miss warning signs. The FAA mandates manual flying hours specifically to prevent this.
Software has no such mandate. Nobody is requiring you to hand-write code for 20% of your working hours to maintain your debugging instincts. Nobody is testing whether you can still trace a stack trace without asking Claude to explain it.
And unlike aviation, where a crash is immediately visible, the consequences of lost situational awareness in code are silent. The bugs accumulate. The layer of petrified code thickens. And one day you're staring at a production outage in code that passed every automated check, and you genuinely cannot figure out what's wrong.
What to actually do
I'm not going to tell you to stop using AI. That ship sailed. And the productivity gains are real for the right tasks.
But there's a difference between using AI as a power tool and using it as a crutch. The line is simple:
- Write the logic yourself first. Use AI for boilerplate, scaffolding, and repetitive patterns. Don't use it for the parts that require thinking.
- If you can't explain it, reject it. Not "I can read it and it looks fine." Can you explain why it does what it does? Can you predict where it'll break?
- Debug manually sometimes. When something breaks, resist the urge to paste the error into an AI. Trace it yourself. Rebuild that muscle. And when you do hand a bug over, there is a way to split that work that leaves the hypothesis with you.
- Write bugs on purpose. Seriously. Implement something wrong, then find the bug. That's how debugging instincts are built.
If you want those turned into a standing routine rather than good intentions, I wrote up a practice plan for reading code: a merged PR a day, predict-before-you-run, and explaining code back with the AI closed.
The developer who forgot how to build a Laravel API didn't lose that skill overnight. They lost it one accepted suggestion at a time. Each time the AI wrote something they could have written themselves, they skipped one repetition of the exercise that keeps the skill alive.
AI isn't making you a worse writer.
It's making you a worse reader. And in this profession, reading is the harder skill.