Vertical Scaling, or "I Stopped Coding Six Months Ago"

There is a sentence making the rounds in every engineering organization right now, usually from someone at staff level: "I stopped coding months ago." It gets said with a small smile, and it lands in the room two different ways - as either the most interesting thing that engineer has said all year, or as the most alarming.

Both reactions are right, because the sentence has two readings. In one, the most experienced person in the org has quietly become a rubber stamp on a firehose - maximum AI output, minimal correction, the vibe-coding trajectory wearing a senior title. In the other, something happened that engineering organizations have never had before: the engineer scaled vertically.

Engineering capacity has always scaled horizontally. More output meant more engineers, and more engineers meant more coordination - every hire adds communication paths, onboarding, and management surface, which is why doubling a team has never doubled its output. AI breaks that trade on the other axis: the same people, multiplied, with zero new communication paths. And not just the top - every layer of the org gets a multiplier. The staff engineer running a 3% coding budget is simply the far end of it: one person's judgment flowing through an AI-augmented system into the output of several engineers. That is the thing executives keep trying to put a finger on about AI adoption. The wish was never engineers who type faster - it was multiplying the engineers they already have.

Note what the sentence is and is not: it is the surface symptom, not the event. Nobody decides to stop coding. It surfaces reactively - one day you notice the last hand-written commit was weeks back, because the infrastructure crossed a threshold and the hands followed. The deliberate work was never the stopping. It was building the system that makes the stopping safe. This piece is about that system: vertical scaling, done responsibly - and what separates it from the rubber stamp, because from across the room the two look identical. The difference is whether the gates were passed or skipped.

The budget, restated

The frame comes from AI Code Nines: treat the share of AI-written code like an SRE availability target. At 90% AI-written - one nine - the remaining 10% is your human code budget, and like an error budget, the point is not to drive it to zero. The point is to spend it deliberately, on the work where human judgment concentrates, while the infrastructure around it keeps quality from burning down faster than you replenish it.

"I stopped coding" is a statement about that budget. Said precisely, it means: my human code budget has dropped to a few percent, and I know exactly what it gets spent on.

Here is the position, stated plainly: a staff-level engineer in a heavily AI-augmented organization should retain about a 3% human-coding budget. Not zero, not ten. Zero means the correction surface has closed - nobody's hands ever touch the places the model is blind. Ten means the infrastructure is not finished and a senior engineer is still typing what the system should be absorbing. Ours sits at that number: weeks pass without writing code by hand, and when the hands do go in, it is almost always for one of two reasons, which we will get to.

Scaling responsibly: nobody jumps to two nines

The progression matters because every gate is infrastructure, not confidence. Most engineers start somewhere near half and half: AI writes the mechanical part, the human writes anything that requires a decision. Each step up is earned by building the thing that replaces what your hands were doing:

• Around 50% - the starting point. AI handles pattern application and boilerplate; you write everything with judgment in it. The gate to climb: a real rules file exists, and review corrections get codified into it instead of repeated every session (A Working AGENTS.md). Until corrections persist, you are re-teaching the model daily - your hands are still load-bearing.
• One nine - 90% AI-written. AI produces whole modules of pattern-following work; your code is the patterns being established and the corrections that matter. The gate to climb: stabilization runs on a schedule derived from measurement, not from feeling (The Stabilization Pass), and cycles stay small enough that review remains honest - you can still explain every line that shipped.
• Two nines - 99% AI-written. Hands on the keyboard are rare. The gate that makes this stable: the correction system runs outside the editor. The codebase is prepared with clean landing zones (Make the Change Easy), the hairy areas have navigation docs (Context Modeling), and misses get attributed and turned into edits (The Session Review). Your judgment still touches everything; your typing touches almost nothing.
• 100% - not a gate, a cliff. At 100% there is no correction surface left, and the compounding math from the nines model has no recovery term. The budget concentrates as you climb. It never disappears - and a team whose budget hit zero did not graduate, it unhooked the brakes.

What the last 3% is for

At a 3% budget, hand-written code clusters into exactly two categories, and the clustering itself is the health check:

AI failure modes. Every codebase accumulates a known list of things the model confidently gets wrong in it - the subtle concurrency boundary, the cross-cutting invariant no single file states, the integration whose real behavior differs from its documentation. Your rules file names them; your hands fix them. This is the budget spent as designed: human correction exactly where the model is known to be blind.

Architecturally dense code. The places where the design is being decided in the code itself - where every line is a judgment call and there is no pattern to follow because this code is creating the pattern. This work stays hand-adjacent forever. It is the same work the disciplines model keeps at maximum review depth (The Three Disciplines), because judgment density is the whole job.

The inverse is the diagnostic: if your hand-written code is still boilerplate - wiring, mappers, the fourth variation of an existing endpoint - you are not out of code, you are out of infrastructure. Something upstream (rules, preparation, context docs) has not been built, and your hands are compensating for it.

When you can actually say it

The claim is testable. You are ready to say "I stopped coding" when all of these hold:

• Every recurring review correction from the last month exists as a written rule. If you are still correcting the same thing twice, you are re-teaching, not managing a budget.
• Stabilization happens on a measured schedule, and the add/remove telemetry shows replenish actually occurring - not a backlog item named "cleanup" that never runs.
• Your last several misses have session-review attributions, and none of them read "the flag was there, nobody caught it." A drowned flag at two nines means the review layer is already thinner than the autonomy you granted.
• Your remaining hand-written code falls cleanly into the two spend categories above. Anything else in the list is infrastructure debt wearing a disguise.

And one boundary that holds at every level: stopped coding never means stopped reading. In an AI-augmented discipline you still review every line; in an outcome-led one the boundary moved to the session and the tests, deliberately, with the validation to support it. An engineer who stopped reading as well as writing is not at two nines. That is the firehose reading of the sentence, and the org usually finds out which one it was a quarter later.

Why staff engineers get there first

It is not seniority privilege. The budget model says human code should concentrate where judgment density is highest - and a staff engineer's value was never typing speed. Their product was always the decisions: where the seams go, which pattern wins, what not to build. AI removed the typing between their judgment and the codebase, so their budget fell fastest with the least loss.

But first does not mean only. The whole spectrum multiplies. A junior working outcome-led on well-patterned tasks ships a multiple of their former output while the apprenticeship continues. A senior runs whole modules at one nine. The spread of individual output across an org used to run something like one to ten; vertical scaling multiplies every point on that spectrum - the distance between the ends grows, but everyone moves. The factor differs by layer because the thing being multiplied is judgment, and judgment is what the layers differ in.

The one shortcut that does not exist: a junior cannot skip to the staff engineer's factor. Their hand-written code is not just output - it is how the judgment gets built that later holds a review boundary at all. A junior at two nines has skipped the apprenticeship that makes two nines safe; their multiplier is real, but it is earned discipline by discipline, not granted by the tooling. The right reading of "I stopped coding" at staff level is not "coding is over." It is that the org has working infrastructure and one person whose judgment now flows through it instead of through a keyboard - with every other layer scaling behind them on the same system.

Horizontal scaling buys output and pays for it in coordination. This is the other axis - and it is why the sentence, said honestly and gated properly, is the best news an engineering organization can send upstairs.