AI Code Nines

What happens when autonomy outpaces the work

High-autonomy AI work - product-led, feature-shaped, minimal review - is a real discipline with real preconditions. When those preconditions hold, it ships. When they don't - when the same autonomy level runs against work that needed a tighter review boundary - the math turns against you. And the math is worth understanding, because it explains the trajectory whether the team is disciplined or not.

AI does not write uniformly bad code - anyone who has reviewed agent output knows most of it is fine, line by line. The issue is mathematical, and once you see the math, you can place every AI-augmented team on the same spectrum.

Here is the math. Each generation cycle with no human review lands at maybe 85–90% right. Not broken - subtly off. A naming inconsistency, a duplicated concept, an abstraction that almost fits. One cycle at 85% is shippable. Ten compounding cycles at 85% leave you at 0.85^10, roughly 20% of the original quality. And vibe coders run far more than ten cycles, because they iterate by prompting through bugs that should not exist, and each fix lands at the same 85% on top of an already-degraded base. Fixes introduce new issues faster than they resolve old ones.

That is the wall they hit on day three. It is not a quality problem. It is a compounding problem with no error budget management - which means the right mental model already exists. SRE teams have been running it for years.

What SRE got right about imperfection

Site reliability engineering made peace with imperfection by pricing it. 99.9% uptime - three nines - is not a failure to reach 100%; it is a deliberate budget of about 43 minutes of downtime a month. 100% is not the goal, because the cost curve toward it goes exponential. The budget exists to be spent on things that matter: risky launches, infrastructure changes, experiments. You do not waste it on preventable outages. And when the budget is burned, you stop shipping features and stabilize until it replenishes.

Two ideas are worth stealing. First, perfection is not the target - the budget is. Second, a burned budget triggers a freeze, not a shrug.

The nines of AI-written code

Now flip the model to code authorship. Measure what proportion of code the AI writes per cycle:

• 90% AI-written = one nine. A 10% human code budget.
• 99% AI-written = two nines. A 1% human code budget.
• 100% AI-written is impossible - for the same reason 100% uptime is. Architecture, judgment, and taste are always human, and the cost of pretending otherwise goes exponential.

The human code budget is not a failure to automate. It is where the value is. The question that matters is the same one SRE asks about error budgets: what are you spending it on? Spending your 10% on boilerplate is waste. Spending it on architecture decisions, codebase preparation, and review of the AI’s diffs is the whole game.

Higher nines burn quality faster

Here is where the model earns its keep. The more AI per cycle, the thinner the human review layer - and the thinner the review layer, the faster quality degrades per cycle.

At one nine, 10% human touch is a meaningful correction surface. You catch a lot each pass. Compounding is slow. At two nines, 1% human touch is paper thin - you are reviewing far more volume with the same brain, and the compounding accelerates. At three nines you are rubber-stamping, and each cycle goes out barely corrected.

The relationship is direct: higher AI nines means a faster quality burn rate, which means shorter intervals between required stabilization passes.

The nines setting is a dial, not a badge. Crank it up for pattern-based work - scaffolding, ports, repetitive modules - and shorten your stabilization intervals proportionally. Turn it down for complex cross-cutting work where every line needs judgment. Knowing where to set it for a given phase of work is the actual engineering leadership skill in AI-augmented development.

Vibe coding, in this vocabulary, is maximum nines, zero human code budget, and zero stabilization passes. Worse: with no review layer catching subtle issues, the effective per-cycle quality is not 99.9% - it is the 85–90% from the opening math. Every cycle compounds uncorrected. The day-five scrap-and-restart is not a skill issue. It is what the curve does when nobody is managing the budget.

The burn/replenish curve

The whole framework collapses into one picture: quality as a resource that burns and replenishes.

You start at 100% - clean codebase, post-stabilization. Then a burn phase: high-ratio pull requests (3:1, 4:1 adds to removes), mostly new code, feature velocity. Quality declines per cycle at a rate set by your nines dial. The decline is invisible in any single diff and unmistakable in aggregate. Eventually you hit your tolerance threshold - changes start resisting, the same fixes recur, the codebase pushes back. Then a replenish phase: low-ratio pull requests (1.5–1.8:1), high adds and high removes at the same time - refactoring, consolidating, tightening. The curve climbs back. Then you burn again, on a cleaner foundation.

The curve in real data

This is not hypothetical. A client engineering team we advised ran exactly this curve across roughly 48,000 absolute lines (adds plus removes) in 15 days, and their pull request data draws it for you:

Read it as the curve. Ratios climbing from 2.5:1 to 4.8:1 in the first week: burning quality for feature velocity. Then 1.8:1 - the team felt the debt and turned the corner. Then 1.5:1 and 1.7:1 - the deepest replenish, heavy adds and heavy removes as the codebase was reshaped. Then 3.5:1 again - a new burn cycle on a clean foundation.

Two things in this data are worth arguing with. First, absolute throughput stayed constant at roughly 3,000–4,000 lines per day across every phase - burn and replenish alike. The engine did not slow down during stabilization; only the direction changed. Second, the bill was real and predictable: the feature burst ran at high nines - pattern-based work, the AI generating whole modules - and roughly one week of it bought a 12-hour stabilization pass. At lower nines, with more manual intervention per cycle, the debt accrues slower and the interval stretches.

And note what you did not need to measure: the add/remove ratio is the quality telemetry. No survey, no static-analysis score. High ratio means you are burning; low ratio with high absolute means you are replenishing. The complete instrument panel is four numbers - absolute per day (throughput), ratio (burn vs. replenish), nines setting (burn-rate multiplier), and quality, the resource the other three are managing.

How long can you burn?

The engineering leadership question becomes concrete: how long can you run a burn phase before you must replenish? The answer is your nines setting times your quality tolerance.

• One nine (90% AI): slow burn. You can run two to three weeks before a stabilization pass.
• Two nines (99% AI): fast burn. Stabilization needs to be weekly.
• Three nines and beyond: burn rate exceeds replenish capacity. Quality hits zero before recovery is possible. At this autonomy level without stabilization, the recovery costs more than a restart - which is exactly the trajectory the compounding math predicts.

Rules have error budgets too

The model also applies one level up, to the rules you feed the AI. One of our persistent rules for the coding agent was strict: avoid chained method calls, extract intermediate variables. In review we noticed the agent over-applying it to trivial controller wiring - pass-through code where chaining was perfectly fine - and we considered softening the rule with nuance.

The agent’s own assessment, when asked, was the right one: leave the rule strict and accept the occasional controller-wiring case as error budget.

That is the framework at the rule level. A strict rule that over-corrects 5% of the time is a known, small, predictable budget - and over-correction is cheap, because it is visible in review. A nuanced rule that under-corrects 20% of the time is an unpredictable quality leak - and under-correction compounds silently, exactly like an unreviewed cycle. Strict rules with known error budgets beat nuanced rules with unknown leak rates, because an AI will exploit every inch of flexibility you give it.

Spend the budget on purpose

The question for an AI-augmented team is no longer whether to use AI, and it was never how to get to 100%. It is where you set the dial for the work in front of you, how you shorten stabilization intervals when you crank it up, and what you spend the human code budget on. Vibe coding fails not because AI is bad at writing code, but because it runs maximum nines with no budget and no replenish - and the compounding math forecloses every other outcome. Everything short of that is an engineering decision. Make it deliberately.

How the budget evolves as a team climbs the nines - and when an engineer can honestly say they stopped coding - is its own piece: see Vertical Scaling, or "I Stopped Coding Six Months Ago".