The problem with agentic coding is not speed. It is that we deleted a feedback loop and replaced it with nothing. The leadership question is not “should we automate,” it is which parts of the system are still allowed to be understood by no one, and whether anything crossed that line while we were not looking.
Date: July 2026 | Argues with: The Human Bottleneck Is a Quality Mechanism
The Loop We Deleted
Until recently, a codebase could only grow about as fast as people could keep up with it. Code review, pairing, the sheer slowness of typing. Imperfect, often theater, but they did one thing reliably: the system could not get bigger much faster than someone was learning it.
At any real scale nobody understood the whole system. That has been true for decades. But every part of it had someone who did, and the pace of change kept it that way. Agents break the coupling. Code now gets written at machine speed. Understanding still happens at human speed. Nothing in a spec-to-deploy pipeline closes that gap.
Worse, the gap is invisible. Nothing looks wrong. Velocity is up, releases ship, dashboards are green. You find out exactly once: the day something breaks that nobody understands, and you learn that understanding cannot be built in the middle of an incident.
Where I Split From “Slow Down”
The standard response is throughput discipline. Cap generation to what you can review, keep the pain signal alive, stay in the code for architecture. That is the argument in The Human Bottleneck Is a Quality Mechanism, and it is correct about the mechanism and wrong about the remedy.
Rationing throughput treats all code as equally deserving of comprehension. It is not. Not all code deserves to be understood, and the deciding variable is not risk or complexity, it is how long the code will exist.
Before product-market fit, code is scaffolding. It exists to test an idea and get thrown away. Nobody needs deep understanding of code that will not exist next quarter. Automate all of it. More attempts, more shots at the market, pure upside. Capping agent output in that phase is not discipline, it is throwing away the only real advantage you have.
This is a sharper cut than blast radius. Blast radius asks “what breaks if this is wrong,” which is a per-diff question you answer over and over. Disposability asks “will anyone ever have to touch this again,” which you answer once per subsystem and then track.
The Phase Ends Quietly
Here is the failure. The scaffolding phase does not end with an announcement. It ends when real customers are standing inside the building you thought was scaffolding. You cannot tear it down and start over anymore, and it is still growing faster than anyone is learning it.
No event marks the transition, which is exactly why teams miss it. There is no ticket for “this module stopped being disposable.” The code did not change. Its status did. The team that generated it at full tilt for six good reasons keeps generating it at full tilt for zero good reasons, and everyone is still measuring velocity.
So the boundary is not a one-time architectural decision. It is a thing you re-audit, because it moves on its own.
The Failure Mode Is Deceleration, Not an Incident
Companies will get this line wrong in both directions. Getting it wrong on the conservative side is legible: you shipped slower than you needed to, someone else got there first, and you know why.
Getting it wrong on the permissive side does not announce itself. Those teams will not fail loudly. They will just get slower, quarter after quarter, until the post-mortem blames “the market.” Every quarter, more of the system falls into the category nobody can safely change. Estimates inflate. Simple features grow tails. Nobody can point at the incident because there was not one.
That is the tell I would watch for: not outage counts, but the ratio of estimate to actual creeping up across teams with no single explanation.
Where My Line Sits
Mine is drawn by intended lifetime, not by project prestige.
recursive-lm-harness is on the understood side, deliberately. Strict typing, green CI, an argument I have written down and defended in public. It is a portfolio artefact and a teaching object, so its whole value is that I can explain any part of it cold.
The client-facing and internal tooling work sits on the other side, and I am fine with that. Much of it was generated fast to answer a question, and a lot of it was correctly thrown away. Where I have been sloppy is not in generating it. It is in never going back to check whether a piece of it quietly became load-bearing.
The audit I actually owe myself is not “read more of my own code.” It is: list every subsystem currently generating value on a schedule, and ask which of them nobody has understood in six months.
One Sentence
Decide which code is allowed to be understood by nobody, write that boundary down, and re-check it, because code crosses the line without asking.
Related
- The Human Bottleneck Is a Quality Mechanism – The throughput-rationing answer this note argues against
- Comprehension Debt Is Refinanceable – How to lower the cost of re-understanding what falls on the unowned side
- The 30% Cliff – Per-diff comprehension triage by blast radius
- Growth vs Polish Phases – The mechanical version of switching modes
- Code Stewardship Over Authorship – Owning code you did not read line by line
