The whiteboard defense as the antidote to agent slop
- YT :: https://www.youtube.com/watch?v=iuccfEQgIeY
- Original title :: They can’t take it anymore
Prime reacts to a viral post from an engineer at a big company where specs, code, tests, PRDs, tickets and reports are all generated by Claude, nobody reads anything, and people work 12–13 hour days just to press enter. His answer is that the underlying dynamic is decades old, the fix is a standard of understanding rather than a standard of review, and the genuinely new problem is how juniors are supposed to grow up in this environment.
The complaint
The post describes an organisation where every engineer from L1 to L7 does the same thing — talk to Claude. No sense of victory, nobody resolving bugs, nobody thinking. Management's line is that pushing code is not the bottleneck, so the goal is to ship regardless. The author says they wouldn't mind if there were time to read the code and understand where things go, but there isn't.
Mitchell Hashimoto's whiteboard defense
The counter-position Prime endorses: you should be able to be pulled aside at any moment and asked to explain any customer-facing system you have shipped, clearly, defending the decisions you made. That is the benchmark for responsible AI usage.
Crucially it is not line-by-line familiarity — no requirement to know which function is called where. The questions are architectural: why X instead of Y, what happens when an actor behaves maliciously, which data structure and why, where does this fail. Engineers who can answer those build better products and, Prime argues, avoid the soul-sucking experience described in the original post. Skipping this only works for the simplest software; otherwise the wrong abstractions come due later and are hellish to undo.
Nothing has actually changed
Uncle Bob's reply — management is still asking why everything took so long — is the core of Prime's argument. From his first professional job in 2007 through ten years at Netflix ending in 2024, the conversation was identical every time: we need this feature, how many corners can we cut, what can wait a cycle after production. The balancing act of which corners are worth cutting has always been the job. What changed is that people feel more disconnected from the code, so the habit of thinking forward about the codebase is quietly slipping. He calls the result Schrödinger code: it works great until you look at it, and then you're horrified it works at all.
The fix he proposes is remembering how to say no — not being a yes engineer who ships features on demand. Engineers had that power before AI. Without guardrails, without asking the right questions, without being actively involved, you produce garbage, and a bad codebase is equally miserable whether a human or a robot wrote it.
The bifurcated world
His behind-the-scenes theory for why opinions diverge so sharply: a large group works on a website talking to one server with a remote database and a remote login system. The problem space is straightforward, so slop genuinely does hold together, and from inside that world AI appears to have solved everything. Move to a system with several services and non-obvious interactions and the complexity makes it impossible to let go of the wheel.
The juniors problem
The part that worries him most. Seniors can mount the whiteboard defense because they implemented these systems by hand before; juniors are now expected to generate code rather than write it. As the creator of Clay put it, that's the catch-22. Prime doubts he could have learned in this environment — he needed the difficult environment to be forced to study things properly. He says he still takes his own advice: sitting down and writing things by hand to learn a library or feel out a large architectural decision, because reading docs alone doesn't give him the understanding.