The 70% Problem: Why Generated Software Needs a Human Last Mile

The 70% problem is the observation that generation tends to carry a software build most of the way to working, then stalls against a remainder that resists automation. That last fraction is not more of the same code at a smaller scale. It is qualitatively different work: integration, edge cases, production hardening, and the part nobody bothered to specify. The first stretch rewards fluency; the last stretch rewards judgment, and judgment does not compress the way boilerplate does.

• The first 70% is well-specified surface; the remainder is the unspecified interior.
• A demo proves the happy path and hides the conditions that break it.
• Edge cases multiply faster than any prompt can enumerate them.
• Integration friction lives between systems, where no single generator can see.
• Production hardening is mostly defending against inputs nobody described.
• The figure moves over time, but the shape of the difficulty does not.

Why is the last stretch qualitatively different from the first?

The first stretch of a build is dense with structure that has been described thousands of times. Forms, lists, routing, state, a data shape with predictable fields. Generation is strong here because the patterns are common and the intent is legible. There is little ambiguity about what a sortable table or a validated form should do.

The remainder is different in kind. It is the property of a system where the specification runs out and reality continues. What happens when two writes race? When an upstream surface returns a shape it promised never to return? When a user does the reasonable-but-unanticipated thing? These questions are not harder versions of the early ones. They are a separate category, defined less by writing code than by deciding what the code should mean under conditions the original request never named.

There is also a feedback effect. The early code is generated fast, so it accumulates fast, and the volume itself becomes terrain to cross. A build that materializes in minutes still has to be understood in hours. The reader arrives at a structure they did not write, with conventions they did not choose, and the comprehension cost lands at exactly the moment the hard decisions begin.

This is why the percentage is slippery. As models improve, the boundary tends to move, but it moves along the same fault line: wherever explicit specification ends, automation slows. The slope steepens precisely where description thins out. A figure that reads as progress is really a marker on a frontier that keeps shifting toward the parts that were always least legible.

What does a demo hide that production reveals?

A demo is a controlled performance. It runs one path, with chosen inputs, on a forgiving network, in front of an audience that wants it to succeed. Production is the adversarial inverse: every path at once, hostile inputs, partial failures, and no one steering. The distance between those two states is the demo-to-production gap, and it is where most of the last-mile effort actually goes.

The gap is wide because a working demo and a working system share an appearance but not a structure. The demo optimizes for the visible. The system has to account for the invisible — the retries, the idempotency, the timeout that fires once a week, the migration that has to run while traffic continues. None of that shows up in a screen recording.

One tradeoff that surfaces is speed against durability. Generation buys a fast, plausible artifact. Turning that artifact into something that survives contact with real load is slower, and it rarely looks like generating more code. It looks like reading, tracing, and constraining what already exists.

The gap also has a perceptual cost. A convincing demo sets an expectation that the work is nearly finished, which makes the remaining effort feel like a regression rather than the bulk of the job. Stakeholders saw it work. The distance between that moment and a dependable system is real, but it is hard to defend because it is invisible to anyone who only watched the performance.

Why does the hardest remainder live in what nobody specified?

The unspecified remainder refers to the behavior a system must have that was never written into any request. It is the largest source of last-mile cost because it cannot be generated from a prompt that does not contain it. A generator answers the question it is asked. The hard part is the question nobody thought to ask.

Specification is expensive precisely where it matters most. Nobody specifies what the checkout does when the payment surface confirms but the order write fails, because nobody wants to think about it until it happens. So the gap between stated intent and required behavior becomes the work. Someone has to notice the absence, name it, and decide.

Noticing is the underrated skill here. A generator fills what it is given and falls silent on what it is not, and that silence reads as completeness to anyone who only checks the happy path. The remainder is invisible by construction. Surfacing it means imagining the system under stress before the stress arrives, which is a habit of attention rather than a feature any tool ships.

Happy path

The single sequence of events a demo is built to show, where every dependency behaves.

Unspecified remainder

Behavior the system must exhibit that no request, prompt, or ticket ever described.

Integration seam

The boundary between two systems, where each one's assumptions about the other go unstated.

Production hardening

The work of making generated structure survive inputs, failures, and load it was not shown.

Where does human effort relocate when generation absorbs the first 70%?

The effort does not disappear; it migrates. When the early, well-specified mass of a build is generated in minutes, the human hours that used to go into typing it move toward the activities generation is weakest at. Reading unfamiliar code becomes a primary skill. Deciding what a system should do at its edges becomes the scarce contribution.

This relocation changes the shape of a day. Less time producing first drafts, more time interrogating them. The bottleneck shifts from creation to verification — confirming that the plausible thing is also the correct thing under conditions the generator never tested. Judgment, taste about failure modes, and the patience to chase a once-a-week bug become the work that carries weight.

It also changes what experience is worth. The value of having seen many systems fail does not transfer to a generator; it lives in the person who recognizes a familiar smell in unfamiliar code. That recognition is what lets someone glance at a generated flow and sense, before any test runs, where it will buckle. The early code commoditizes; the instinct for its edges does not.

How do teams cross the final stretch deliberately?

Crossing the last mile tends to follow an order, not because a recipe exists, but because the failures arrive in a predictable sequence. The discipline is to treat the generated artifact as a hypothesis and the remaining work as falsification.

1. Map the seams: list every boundary where the build touches a system it does not control.
2. Enumerate the inputs the demo never used, especially malformed, empty, and duplicated ones.
3. Trace each failure path to a decision: retry, reject, degrade, or surface.
4. Make the implicit explicit by writing down the behavior nobody specified, then choosing it.
5. Pressure the result with real concurrency and real volume before declaring it done.

Each step converts an unknown into a stated intent. The generated 70% gets you a body to interrogate; this procedure is the interrogation. It is slower than generation by design, because its product is certainty rather than surface.

The order matters more than any individual step. Mapping the seams first prevents the common mistake of hardening the interior while the boundaries stay undefended. Enumerating inputs before tracing failures keeps the work grounded in what actually arrives rather than what was imagined. The sequence is a way of spending attention where the next failure is most likely to come from, instead of where the code is most comfortable to read.

What is the last-mile boundary becoming as generation improves?

The boundary is not dissolving; it is relocating upward. As generation handles more of the well-specified middle, the human frontier moves toward the parts that were always least describable — the judgment calls, the failure semantics, the decisions about what a system owes its users when something breaks. The percentage may climb. The character of the remainder gets harder, not easier, because what remains is the residue of everything that resisted specification.

What gets scarcer, then, is not coding ability but the capacity to hold a system's edges in mind and decide well about them. The field tends to reward those who can read fast, doubt productively, and finish. The last stretch of a generated build will stay human for as long as some part of every system goes unspecified — which is to say, for a long while.

There is a quieter implication for how teams organize. If the generated middle keeps growing, the work that distinguishes a finished system from a plausible one concentrates in fewer, denser hours. That tends to reward depth over throughput, and it makes the ability to say what a system should do under failure more valuable than the ability to produce more of it. The frontier moves; it does not close.