The skill collapse everyone keeps warning about already happened. AI just made it visible.
I test AI coding tools for a living. I’ve watched the same argument cycle through my inbox for months now: developers are outsourcing their brains to language models, expertise is eroding, and in a few years nobody will know how a for loop works. The panic assumes there was a deep well of expertise sitting there before the models showed up. Having reviewed a lot of tools built by a lot of teams, I’m not convinced.
The oversupply nobody wants to name
One of the more honest takes I’ve read framed the so-called golden age of software as the period when the barrier to entry collapsed. The result wasn’t a generation of master craftspeople. It was an oversupply of developers doing low-value, high-churn work, much of it driven by building tech for the sake of building tech.
That’s an uncomfortable read, and I think it’s mostly right. A large slice of professional programming was already pattern-matching against Stack Overflow, copying config from a blog post, and shipping something that passed review. AI didn’t replace deep understanding in those workflows. It replaced the searching.
Which means the interesting question isn’t whether AI erodes expertise. It’s what expertise was actually load-bearing in the first place.
Where the real damage lands
None of this means the tools are fine. The failure mode I keep hitting in reviews is specific and it’s ugly: AI-generated code often lacks reliability in production. It works in the demo. It works in the test suite the model also wrote. Then it accumulates as technical debt that nobody on the team fully understands, because nobody on the team wrote it.
There’s a structural reason for this. Language models are excellent at passing the static parameter checks that a pull request review actually evaluates. They produce predictable design patterns. They follow style guides more consistently than humans do. Linting passes, formatting is clean, naming is sensible.
So the code looks correct at exactly the layer where most teams do their looking. The problems live one level down, in architecture, in state management, in the assumptions the model made about your system that it had no way of knowing. Code that reads clean and behaves badly is harder to catch than code that reads badly, because your review process is optimized to catch the second thing.
That’s the real crisis, and it’s not about skills. It’s about a quality gate that was already shallow meeting an output that’s specifically good at satisfying shallow gates.
The Spotify signal
In February 2026, Spotify said some of its strongest developers hadn’t written a line of code since December. They’re directing agents, reviewing output, and making calls about what ships.
Read that as a skill story and it’s alarming. Read it as a job description change and it’s just Tuesday. Those developers didn’t lose their judgment when they stopped typing. Judgment is what they’re being paid for now.
But it does relocate the risk. If review is the whole job, and review is the thing AI is best at gaming, then the quality of your output is now entirely a function of how good your review culture is. Most teams have not upgraded their review culture. They’ve just added more code to it.
What the skill-collapse crowd gets right
I’ll concede the strongest version of the argument. You don’t need model collapse to get skill collapse. If a generation of developers learns to code by accepting suggestions, the deep debugging instinct never forms, because that instinct only comes from being stuck for three hours and eventually understanding why. Nobody gets stuck anymore. Getting stuck is the entire curriculum.
That’s a real cost, and by 2026 AI is writing enough of the code in circulation that the long-term sustainability question is legitimate. If the models are trained on code and humans stop producing the hard-won kind, the feedback loop degrades from both ends.
What I’d actually do about it
From the toolkit side, the fixes are unglamorous and they work:
- Review generated code for architecture, not style. Style is the part the model already nailed. Ask what state this touches and what breaks if it’s called twice.
- Never let the model write both the implementation and the only test for it. That’s a closed loop that proves nothing.
- Keep one problem a week where you don’t reach for the tool. Not out of principle, out of maintenance.
- Treat any generated code you can’t explain out loud as unmerged, regardless of what CI says.
The honest version of this story isn’t that AI is destroying a generation of engineers. It’s that AI is a solid accelerant for people who understood the system and a very convincing disguise for people who didn’t. Same tool, opposite outcomes. Which one you get depends on what you knew before you installed it.
🕒 Published: