The Typing Was the Safety Harness — Leadership Garden
Search
Sign in
Table of contents
The bottleneck was never typing
Slowness was load-bearing
We have always done stochastic engineering
The shape an agent reaches for when nobody is watching
The QA was hidden in the writing
The shallow systems are not safer
How the noticing gets learned
What changed is the price of one input
The hard parts of software engineering are still hard. The forcing functions moved. The work did not.<br>I have been trying to make this argument to colleagues for months. Most of the popular framings of the AI shift get it wrong in the same way. They focus on the visible surface changes: a new orchestrator role here, the death of the typing bottleneck over there, prompt engineering as its own specialty alongside the older disciplines, agent-fleet management starting to look like a real job. The underlying work, the part of engineering that distinguishes one practitioner from another, looks the same as it did three years ago. We just used to do most of it for free, by accident, as a side effect of typing.<br>The "we are all orchestrators now" framing has something real underneath it, but the framing itself is incomplete in a way that matters. The angle I want to argue is narrower and more useful than "your job is now to manage agents." Your job is to recreate, on purpose, the safety pass that typing used to do for you for free.<br>Typing code was doing load-bearing work that nobody invoiced for, an implicit in-line form of design review and quality assurance. We removed it, and most teams haven't realized they still need it.<br>The bottleneck was never typing<br>This is the uncontroversial part. If you can type 80 words a minute and you ship a few thousand lines on a great week, the math says typing was never the bottleneck. Maybe four hundred lines on a focused day. Out of six hours of deep work, the actual finger-on-keyboard time is small. The rest is something else.<br>Most people would call the something else "thinking." That is true but vague. The something else is a stack of activities that happen while you are writing code, that happen because you are writing code, and that you do not do at any other time.<br>You notice when the shape of the problem is wrong.<br>You realize the boundary between two modules is in the wrong place because filling in the second module makes the first one's interface look stupid.<br>You fight with three lines of code for an hour and at the end of the hour you understand that the data model is broken, not the code.<br>You write a function signature and find that the inputs you thought you needed are wrong. Fixing the upstream call site forces you to fix the type definition, and the type definition surfaces a subtle assumption nobody had written down.<br>You read the previous engineer's code while you are touching it and fix the bug you spot, the one nobody filed a ticket for.<br>You write a test and discover, while writing the assertion, that the function you just wrote actually has three exit conditions instead of two, and one of them silently swallows errors.<br>None of this is typing. But it was happening during typing, which is why we never separated the two, and which is why we are mostly surprised now that the work didn't come along when the typing left.<br>The conventional split for software engineering used to be something like fifty percent writing code, fifty percent testing. That split was already wrong. In my experience watching senior engineers work, the writing is more like five or ten percent of the actual time spent, and the rest is the noticing. The noticing is what we are losing.<br>Slowness was load-bearing<br>The slowness of writing code was doing a kind of work we never named. It forced you to think carefully about each line, and when the slowness left, the thinking left with it.<br>Take a concrete comparison. In the old workflow, you sat down to write a small data model. Halfway through, you realized one field needed to be a discriminated union instead of an optional. You changed it. You moved on. The change cost you maybe ninety seconds of thinking and two lines of code. Nobody filed a ticket. Nobody wrote a design doc. The fix happened because you were the one writing the code and you noticed.<br>In the new workflow, you write a prompt that produces the data model. The model uses an optional. You scan the output, think "looks fine," and move to the next thing. The bug ships. Or, worse, the model passes through a code review where the reviewer is also scanning at the same level of attention, because the volume of agent output has made deep review economically impossible. Two weeks later somebody hits a state the optional can't represent. Now you are debugging it as a runtime issue instead of catching it as a design issue.<br>Same bug, both workflows. The difference is when it surfaced. The old way caught it during writing, at the cheapest possible point in its lifecycle. The new way catches it in production, under load,...