My debugging reflexes got slow.
I noticed it while chasing a race condition in a bot’s message queue. Two years ago I would have read the stack trace, formed a hypothesis, and gone hunting. Instead I pasted the whole thing into a chat window and waited. When the suggestion came back wrong, I pasted it again with more context. That loop went on for forty minutes. The eventual fix was six lines I could have written from memory in 2023.
That is the part of the AI coding conversation that gets skipped. Everyone argues about whether the machine writes good code. The more uncomfortable question is what happens to the person sitting next to it.
The code passes review, which is the problem
Large language models are unusually good at the specific things a pull request checks. They match style guides. They produce predictable design patterns. They pass the static parameter checks a reviewer scans for before hitting approve. If your review process is a checklist, generated code will sail through it every time.
What that process does not catch is architectural drift. A bot codebase built from a hundred individually reasonable suggestions ends up with three different retry strategies, two competing ways to represent a conversation turn, and error handling that varies by whichever file the model happened to see in its context. Nothing is wrong. Everything is slightly inconsistent. That is the shape of technical debt that does not announce itself until you try to change something fundamental.
AI-generated code often lacks reliability in production, and the reason it slips through is that the failure mode is not a syntax error. It is a thousand small decisions nobody made on purpose.
Reviewing is not the same skill as building
In February 2026, Spotify said some of its best developers had not written a line of code since December. They now direct AI agents, review output, and make decisions. Depending on your priors, that is either the future working as advertised or a warning label.
I think it is both, with an important catch. Those developers can review generated code well because they spent years writing it by hand. They know what a bad concurrency pattern feels like before they can articulate why. The judgment they apply to agent output was paid for by prior work that no longer needs doing.
The catch is that this ability does not transfer down the chain. A developer who never wrote the messy version has no instinct to check against. They can read code, but reading is a weaker signal than writing. You can follow an argument you could not have constructed. Ask anyone who has nodded along to a proof they could not reproduce.
The skill shortage does not need model collapse
A lot of the doom discourse assumes models degrade as they train on their own output. Skill erosion does not require that. Even with models improving every quarter, a few years of developers not practicing the underlying craft produces a shortage of people who can evaluate what the models produce.
We have a precedent for the shape of this. The golden age everyone remembers was also when the barrier to entry collapsed, which gave us an oversupply of developers doing low-value, high-churn work. Volume went up and the average depth went down. AI assistance runs the same play at higher speed. More code shipped, fewer people who understand it.
What I actually changed in my workflow
I am not going to tell you to stop using these tools. I use them daily and my throughput on bot projects is genuinely higher. But I put guardrails on myself, because the erosion is passive. You do not choose it, you just stop practicing.
- I write the architecture by hand. Message flow, state boundaries, retry and timeout policy, how tool calls fail. Those decisions get made in a text file before any generation happens. The model fills in implementations against a plan I own.
- One hard problem a week, unassisted. No autocomplete, no chat. Usually a parser, a scheduler, or a tricky bit of async logic. It is slower and mildly humiliating, which is how you know it is doing something.
- I debug before I ask. Ten minutes minimum with the trace and the logs, forming an actual hypothesis. Then I can ask for help. The order matters more than the time limit.
- Review looks for consistency, not correctness. Correctness is the easy half. I read generated code asking whether it agrees with the rest of the system, because that is the question the model cannot answer.
- Anything If
Compounding, in the wrong direction
The trade nobody prices correctly is short-term speed against long-term judgment. Generated code that ships today and needs a rewrite in eight months still felt fast. A skill you stopped exercising feels fine right up until you need it under pressure.
Use the tools. Direct the agents. Just keep writing enough code by hand that you remain the person qualified to check their work, because that qualification is the whole job now.
🕒 Published: