What happens to a profession when the hardest part of the job becomes optional?
That is the question I keep circling back to, and I do not think the industry has an honest answer yet. The framing we hear most often is about productivity: AI writes more code, faster, so we ship more. But throughput was never the constraint that made engineering hard. Judgment was. And judgment is exactly the thing that erodes when you stop exercising it.
By 2026, AI is responsible for a significant portion of the code being written. That part is not controversial anymore. What is contested is whether that code holds up, and what happens to the humans who no longer write it.
Passing the Review Is Not the Same as Being Correct
Here is the failure mode that interests me most as someone who studies agent architecture. Language models are extremely good at the parts of code review that are mechanically checkable. They produce predictable design patterns. They follow style guides with a consistency no human team sustains. They pass the static parameter checks that happen during a pull request.
In other words, they optimize against exactly the signals we use to approve code.
This is not a bug in the models. It is a structural consequence of how they were trained and how we evaluate them. Our review pipelines were built assuming that surface-level correctness correlates with deeper correctness, because for human authors it usually did. A developer who wrote clean, idiomatic, well-typed code had probably also thought about the failure cases. The style was a proxy for the thinking.
That proxy is now broken. Style has decoupled from thought. AI-generated code frequently lacks reliability in production while sailing through the checks designed to catch unreliable code. The result is technical debt that does not look like debt. It looks like a tidy codebase that nobody fully understands.
The Skill Question Is Not Hypothetical
In February 2026, Spotify said that some of its strongest developers had not written a line of code since December. Their work is now directing AI agents, reviewing output, and making decisions about what the agents produce.
I want to be careful here, because this can be read two ways, and both readings are defensible.
The optimistic reading: this is abstraction working as intended. We stopped writing assembly, then we stopped managing memory, and each time the profession moved up a layer and got more done. Directing agents is just the next layer.
The pessimistic reading, and the one I find more persuasive: the previous abstractions came with reliable foundations underneath. When you stopped writing assembly, the compiler did not occasionally produce plausible-looking garbage. The abstraction was trustworthy, so trusting it cost you nothing. Agent output is not trustworthy in that sense, which means the human layer above it has to be doing real verification work. And verification requires the exact skill that not writing code slowly removes.
You cannot review what you could not have written. That is the crux of it. Review is not a lighter version of authorship; it is authorship plus the extra difficulty of reconstructing someone else’s intent. Asking developers to review more and write less is asking them to do the harder task with the weaker muscle.
Collapse Does Not Need Model Collapse
Much of the discourse about AI degradation focuses on model collapse, the idea that models trained on synthetic output will progressively degrade. It is a real concern with real research behind it.
But we do not need model collapse to get skill collapse. The models could stay exactly as good as they are today and we would still be on track for a shortage of people who can reason about systems from first principles. The mechanism is entirely human: skills that go unused decay, and the developers entering the field now may never build them at all. Not because they are less capable, but because the environment no longer requires it of them.
There is a sharper version of this argument worth sitting with. The so-called golden age of software hiring was also when the barrier to entry fell away, and it produced a large supply of developers doing low-value, high-churn work. If a meaningful share of the industry was already operating without deep expertise, AI does not create the expertise gap. It exposes it and accelerates it.
What Actually Helps
I do not think the answer is refusing to use these tools. That position is coherent but it is not going to scale, and it forfeits real gains.
What I would argue for instead is treating expertise as infrastructure that requires deliberate maintenance:
- Stop treating PR approval as a quality signal. If models optimize against your checks, your checks measure compliance, not correctness.
- Build evaluation that tests behavior under conditions the model never saw, rather than properties it can pattern-match.
- Preserve authorship deliberately. Some code should be written by humans specifically because the writing is how understanding gets built.
- Track comprehension, not just velocity. Ask whether anyone on the team could reconstruct a subsystem from scratch. When the answer becomes no, you have found your real debt.
The uncomfortable part is that none of this shows up in this quarter’s metrics. Skill erosion is slow, and its costs arrive as incidents nobody can diagnose, years after the decisions that caused them. That delay is exactly why it will be underpriced, and exactly why it is worth naming now.
đź•’ Published: