Compounding judgment in the age of AI brainrot
Last week I watched a senior engineer review a 600-line PR that Claude had generated in twenty minutes. He scrolled past most of it, stopped on one function, paused for maybe four seconds, and said: "This is going to deadlock under load."
It did. The code looked clean. Tests passed. CI was green. He had spent a decade chasing race conditions in distributed systems, and the shape of the bug was familiar before he could articulate why.
That four-second pause is the entire job now.
The bottleneck moved, again
AI is an amplifier. Give it good taste and you ship more good code. Give it sloppy taste and you ship sloppy code at unprecedented scale. None of this is new. Compilers amplified our typing. Frameworks amplified our architecture decisions. Stack Overflow amplified our willingness to paste code we didn't fully understand.
What changed is the surface area. I can generate, in a single afternoon, more code than I can meaningfully read in a week. The bottleneck is no longer typing. It is judgment — the part of the job that decides which of four plausible solutions is the one that won't burn me in six months.
Judgment, unlike throughput, does not come from the tool. It comes from the operator. And the operator has to keep training, because the tool isn't going to do it for them.
What judgment is actually made of
When I sit on a PR and feel that something is wrong without being able to articulate it, I'm running pattern matching across every system I've ever broken. That pattern matcher was trained slowly, often painfully — on real production incidents, on debugging sessions that ran past midnight, on conversations with senior engineers who explained why my "elegant" solution would not survive contact with reality.
The inputs are unglamorous:
- Failures I absorbed personally, with my name on the deploy.
- Codebases I read deeply, including ones I did not write.
- Conversations with engineers who had ten years on me.
- Books and papers that explained why patterns work, not just what they are.
- Writing — essays, design docs, post-mortems — where I forced my own thinking to clarify.
"Prompting tutorials" is not on that list. Neither is "watching the agent generate code." Watching is consumption. Judgment is built through production and reflection — the same way muscle is built through load and recovery, not through reading about it.
Tayla Burrell makes a similar argument about reading itself in her piece on intellectual compounding: five carefully chosen books in a year beat fifty skimmed ones, because depth is what lets ideas connect. The same maths applies to code. Ten functions I genuinely understood beat a thousand I let the agent produce on my behalf.
The brainrot loop
Here is the take you can disagree with. The engineers entering the field in 2026 will, on average, have weaker judgment at the five-year mark than engineers who entered in 2016. Not because they're less capable. Because the failure loops that built taste are being shortened or removed entirely.
When the AI fixes the bug, I do not learn to recognise that bug. When the AI scaffolds the system, I do not learn why the boring layered architecture beat the clever one. When the AI writes the test, I do not develop an instinct for what an untestable function smells like. The friction was the lesson.
That's the brainrot. Not that AI makes anyone dumb — it doesn't. But it removes the small, daily moments of struggle that compound into expertise, and most engineers will not notice the absence until they need to make a call the AI cannot help them with.
The senior engineer in the opening spotted the deadlock because he had once shipped one. The juniors on his team, who have never debugged a deadlock without an LLM holding their hand, will need a different path to that same judgment. Most will not take it. Most will assume the agent's confidence is their own.
The countermoves I actually run
I haven't stopped using AI. That's the wrong lesson. I use it harder than ever — and I layer in the things it removes.
Read code I did not write. The source of the libraries I depend on. Post-mortems from Cloudflare, Stripe, GitHub, AWS. Their incident reports are some of the best engineering literature being published. They show me what failure looks like in production at a scale I will never personally experience.
Read books that are not about coding. The judgment problem is, at root, evaluating decisions under uncertainty. I get more leverage from Kahneman, Brooks, Hamming, and Christopher Alexander than from another framework tutorial. The classics were written by people who debugged on punched cards. Their judgment compounded because they had no choice. I borrow it.
Write things down. Not for an audience — for me. After a hard debugging session, I write what went wrong, what I tried, what worked, what I'd do differently. Forcing the story into words is what converts experience into judgment. The agent will happily summarise my incident for me; that's exactly why I shouldn't let it.
Disagree with the AI at least once a day. Not because it's usually wrong. Because looking at its output and saying "no, this is the wrong shape" is the rep that keeps the muscle alive. If I accept every diff it generates, I'm training myself to be the rubber stamp.
Pair with engineers who are better than me. This was already the highest-leverage thing in software, and it has become more so. Twenty minutes watching a staff engineer review a PR will teach more about taste than a month of solo AI-assisted coding.
The five-year split
In five years, "AI fluency" will mean nothing on a CV. Everyone will be fluent. The differentiator will be engineers who can describe, in writing, without an LLM, what good architecture looks like for a specific problem — and defend that choice when challenged.
The ones who can do that will command a premium larger than the current senior-to-staff gap. The ones who cannot will compete on price against an infinitely scalable workforce of agents that will, frankly, be cheaper.
You can disagree. You might be right. But ask yourself: if the model gets twice as good every eighteen months, what part of the job is it not coming for? The mechanical parts are already gone. What's left is the four-second pause. The taste. The judgment.
Start compounding this week
Pick one of the countermoves and run it for a week. The smallest version that still counts:
- One post-mortem read end to end (Cloudflare's archive is the best free engineering education on the internet).
- One short write-up of a bug you solved, in your own words, in your own notes.
- One PR where you reject the agent's first answer and rewrite the prompt until it produces something you'd actually ship.
Compound that, deliberately, while everyone else is compounding their context window.
Sources I drew from: