How developers can keep their jobs (1)
Companies think they need fewer developers because AI does the grunt work. I think that's short-sighted, and we should look more closely.
Software architecture
The bet companies are making right now
Companies have concluded that coding agents do the grunt work, so they need fewer developers. The cuts hit people at the start of their careers hardest:
A Stanford study finds that young people in AI-exposed jobs are hit especially hard, while there's no such effect for experienced people:
We find no evidence of widespread, economy-wide job displacement. However, employment of young workers (ages 22–25) in AI-exposed occupations now stands 19% below where it would be had it kept pace with that of their less-exposed peers; experienced workers show no comparable gap.
A Harvard study of 65 million employees points the same way: within six quarters of a company adopting AI, its hiring of juniors (and not just developers) fell by 9 to 10%, while hiring of seniors stayed stable.
(Some very well-known articles online even report a 67% drop, but that figure seems impossible to back up, so I don't cite those articles here.)
In my view, the way companies behave rests on a fallacy: where will future seniors come from if you stop hiring juniors and teaching them the experience?
What vibe coding produces
Less experienced developers now ship working software without understanding it. The code runs, and that's exactly why the problem stays invisible. An analysis by GitClear of 623 million code changes shows that, compared with the time before AI, code duplication has risen by 81% and reuse has fallen by 70%.
In my experience, duplication is far from the only problem. Say I tell Claude Code that I'd like a web application based on bun and describe a few user stories. Claude really does generate something that does what I want.
But when I look at the code, domain logic is wildly mixed with database access, which drives up maintenance effort later.
Then comes the real punchline. If I now ask Claude Code whether it thinks that's fine, it says "absolutely not, we should separate technology from domain logic" and refactors accordingly.
So if I hadn't asked, this code would simply have gone to production. People without architecture experience will produce bad code with AI agents and not notice.
Two kinds of debt, not one
Technical debt lives in the code. Comprehension debt lives in the team: the gap between how much code exists and how much of it anyone really understands. The second kind is more dangerous, because no dashboard measures it.
"Comprehension debt" is a term coined by Addy Osmani (formerly Director, Google Cloud AI - Gemini, Vertex, Agents). In his article, Osmani describes what happens when more and more code exists in a system, but the share of it that any human still really gets can't keep up.
A study by Anthropic found that developers who delegated to AI while they were learning to code scored much lower in comprehension tests. That would mean juniors are better off cracking a few hard problems by hand, because they'd learn faster that way. Developers who used AI as a sparring partner and to explain things did better than a group that delegated the work to AI entirely. So it matters how you use AI, not just whether you do.
The day it will go wrong
With new, fairly small applications in particular, vibe coding without deeper understanding doesn't hurt at all. You can give a junior the following recipe, and they'll get pretty far with it:
- Tell the coding agent what's required
- Let it generate code until all tests are green again
- Then tell it to do a thorough review of what it just generated
- If the review found bugs or drawbacks, have the agent fix them
- Repeat steps 3 and 4 until the review only finds issues rated "minor".
- Make a pull request from the changes and hand it to someone else.
That works until the first requirement arrives that contradicts the existing architecture. At that moment someone has to understand the whole system after all, to decide what to do. That person may no longer be on the payroll, because it was someone experienced who has since taken the next step in their career.
What does such a company do then? It simply lets whoever is around make the necessary decisions, and the architecture starts to decay.
The objection I couldn't dismiss
When I looked for people who share this concern, I found many, including very well-known ones. For example Mark Russinovich, Microsoft's CTO, Deputy CISO and Technical Fellow, Microsoft Azure, and Scott Hanselman, VP and Member of Technical Staff at Microsoft/GitHub.
In their article for Communications of the ACM, they argue that generative AI has cracked the economics of software development, in a way the industry doesn't yet fully see.
But I also found serious engineers who say the whole problem will solve itself, and their arguments are actually better than I expected. In the next part of this series you'll read why they might be right. Stay tuned.