It’s a Tuesday afternoon. Something in the checkout flow broke, and the only person who might know why is staring at a function nobody on the team actually wrote. It passed review. The style is immaculate. The variable names are the kind of tidy you’d put in a textbook. And yet it’s doing something subtly wrong, in a way that took four months and a few thousand customers to surface.
The engineer scrolls. Scrolls again. Then says the sentence that should worry all of us more than any headline about robots taking jobs: “I don’t know what this is supposed to do.”
That’s the scenario I keep coming back to, and it’s the reason I want to talk about skill erosion rather than job loss. Because the story unfolding in software right now isn’t really about machines replacing people. It’s about people slowly losing the ability to check the machines.
Code that passes the test but fails the job
Here’s the mechanic that makes this tricky, and you don’t need a programming background to follow it.
When a developer submits code, it goes through a review process. Part of that review is automated: checks that the pieces fit together, that the formatting matches house rules, that nothing obviously breaks. Large language models are exceptionally good at satisfying exactly those checks. They produce predictable design patterns. They follow style guides to the letter. On the surface, AI-written code looks better behaved than most human code.
The catch is that looking correct and being correct are different things, and our review systems are much better at measuring the first. Reports from practitioners describe AI-generated code as often unreliable once it reaches production, quietly accumulating what the industry calls technical debt — the pile of shortcuts, mismatches, and half-fitting decisions that someone eventually has to pay down with real time and real money.
Think of it like a house built by someone who has memorized what beautiful houses look like but has never felt a wall bear weight. The trim is perfect. The doors close nicely. You find out about the foundation later.
What Spotify’s disclosure actually tells us
In February 2026, Spotify shared that some of its strongest developers hadn’t written a line of code since December. They weren’t idle. They’d shifted into directing AI agents, reviewing what came back, and making calls about what to keep.
You can read that two ways, and honestly both are true at once.
The optimistic read: this is what use looks like — sorry, this is what amplification looks like. Experienced people making more decisions per hour, spending their attention on architecture instead of syntax.
The uncomfortable read: those developers can review AI output well because they spent years writing code by hand. Their judgment is the product of all that typing. So what happens to the next group, the ones who arrive after the typing stopped being necessary?
The gap that doesn’t fill itself
Expertise in most fields is built the boring way. You do the thing badly, notice it’s bad, figure out why, and do it slightly less badly. Debugging your own mistakes is the curriculum. Remove the mistakes and you remove the lessons.
Some commentators now argue we could see a broad skill shortage within a few years if current habits hold — not because AI models degrade, but because human capability quietly does. That’s a prediction, not a measurement, and I’d treat it as one. But the logic is hard to wave away. Reviewing output is a genuinely different skill from producing it, and the first one seems to depend on having practiced the second.
There’s a related argument I find interesting: that the so-called golden age of software hiring also flooded the field with low-value, high-churn work as the barrier to entry fell. If that was already true before AI agents showed up, then agents don’t create the problem. They accelerate it, and they make it much harder to see.
Why this matters if you never touch a keyboard
You might be thinking this is a developer problem. It isn’t, and this is the part I’d underline for anyone running a team or a business.
- Software you depend on is increasingly assembled by systems that optimize for plausible-looking output, not verified behavior.
- The people best positioned to catch the difference are a group whose skills we’re currently not replenishing.
- Technical debt doesn’t announce itself. It shows up as an outage, a security incident, or a project that mysteriously takes three times longer than expected.
None of this argues for refusing AI tools. That ship has left, and the productivity gains are real. What it argues for is treating human expertise as something you actively maintain rather than something that persists on its own.
Practically, that means keeping some work deliberately manual for people who are still learning. It means valuing engineers who can explain why a solution works, not just ship one that runs. And it means asking, whenever a system produces something too tidy to question, whether anyone on your team could rebuild it from scratch if they had to.
If the answer is no, that’s not an AI problem. That’s a bus factor of zero, and it was there before the model wrote a single line.
🕒 Published: