Ending is better than mending

agentscostplanning

I once spent the better part of an afternoon reading four hundred lines of code an agent had written wrong. I traced its logic, patched the broken parts, tried to bend it toward the thing I had actually asked for. When I finally gave up — git reset --hard, sharpened three sentences in the plan, re-dispatched — the correct version existed eight minutes later. The hour I spent mending was the most expensive hour of my day. The eight minutes of ending were nearly free.

I had the cost structure exactly backwards, and I had it backwards because I learned to write software in a world that no longer exists.

A slogan from a dystopia

In Brave New World, Aldous Huxley gives his citizens a sleep-taught jingle to keep the economy churning: “Ending is better than mending.” Its companion line is “The more stitches, the less riches.” The point of the conditioning is to stop people repairing what they own, so they keep consuming. Huxley meant it as a warning — a portrait of a society that had engineered away the instinct to fix things, because thrift was bad for business.

For software, in the agent era, the slogan has quietly become true. Not as propaganda. As arithmetic.

The cost structure inverted

For the entire history of software until very recently, code was the expensive thing. Every line was hand-written by a person whose time cost money, so a working artifact represented accumulated human labor. Throwing it away threw away that labor. Mending — debugging, patching, salvaging — was almost always cheaper than rewriting, because rewriting meant paying the labor cost twice. The whole craft was built on that premise. “Don’t rewrite, refactor” is the premise wearing a cardigan.

That premise broke. Writing code is now cheap: an agent and a pile of tokens produce four hundred lines in minutes for a few cents. What did not get cheaper — what got relatively more expensive as everything around it fell — is human time and taste. Your judgment. Your attention. The scarce, slow, irreplaceable act of looking at something and knowing it’s wrong, and knowing what right would look like.

Flat illustration in the same flat avatar logo style as the rest of the site: warm cream background, bold black outlines, deep red and warm orange palette. A large balance scale. The left pan, labeled WRITING CODE, holds a single tiny feather and floats high because it is light and cheap. The right pan, labeled TIME AND TASTE, holds a heavy black weight and sinks low because it is expensive and scarce. An operator avatar stands beside the scale gesturing at it. A caption reads WHATS SCARCE FLIPPED.

When the two inputs trade places like that, the optimal move trades places with them:

When the artifact is wrong, fixing it spends the input that got expensive and regenerating it spends the input that got cheap. Default to regenerating.

Mending is a tax on attention

The hidden cost of mending isn’t the typing. It’s the comprehension. To fix four hundred lines of wrong code, you first have to load the agent’s reasoning into your own head — including the parts that are wrong, because you can’t tell which parts are wrong until you understand all of it. You pay full price to build a mental model of something you’re going to partially discard. That modelling is the single most expensive thing you do all day, and mending demands it up front, in full, before you’ve fixed a single line.

Ending skips the tax. You don’t have to understand wrong code to delete it. git reset --hard costs no comprehension at all. The only thing you have to understand is what you wanted — which you needed to understand anyway, and which is far cheaper to hold in your head than someone else’s flawed attempt to deliver it.

This is why the afternoon felt so wrong in retrospect. I spent the expensive resource — hours of my own comprehension — to rescue the cheap one. I should have spent thirty seconds of taste deciding the artifact was unsalvageable, and let the cheap resource run again.

Why this is safe now, and wasn’t before

You cannot tell people to throw away working code without sounding reckless, so let me be precise about the condition that makes it sane: ending is only cheap when the value has moved out of the artifact and into something durable.

For an agent fleet, that durable thing is the plan. I’ve argued before that the plan is the prompt — that the token-dense, carefully-written specification is the real artifact and the code is a rendering of it. If that’s true, then nuking the codebase isn’t destroying value; it’s discarding one rendering and asking for another. The plan is the negative; the code is just a print. You can burn the print.

This is the same move as pets versus cattle, pushed down one level. Cattle made the agent disposable: don’t nurse the worker, replace it. “Ending is better than mending” makes the output disposable too: don’t nurse the artifact, regenerate it. Both rest on the same foundation — value lives in the reproducible source (the template, the plan), never in the running instance.

Flat illustration in the same flat avatar logo style as the rest of the site: warm cream background, bold black outlines, deep red and warm orange palette. On the left, a small valuable document inside a protective vault box labeled THE PLAN, drawn to look kept and durable. A bold black arrow labeled REGENERATE points right to a fresh clean stack of code pages labeled CODE. In the lower area, a crumpled wrong version of the code is being swept into a bin marked with a circular undo arrow, showing the code is disposable while the plan is kept safe. A caption reads END THE ARTIFACT, MEND THE PLAN.

The other half of the condition is mechanical: reversibility. git reset --hard and even rm -rf && regenerate are only safe moves on top of disciplined version control — atomic commits, clean revert points, a plan and a task graph that survive the deletion. Ending is cheap because the floor is solid. Knock the floor out — uncommitted work, no plan, no clean checkpoint — and ending stops being thrift and becomes the reckless thing it sounds like.

When mending still wins

The slogan is a default, not a law, and the place it breaks is worth naming exactly.

Ending discards everything the artifact knows that the plan does not. Most of the time that’s nothing — the code was a faithful rendering of a spec you still have. But sometimes the artifact has accumulated real knowledge that never made it back into the source: a subtle concurrency fix, three edge cases you discovered only by running it, a workaround for a genuine bug in a dependency. If that knowledge lives only in the code, regenerating throws it away, and the fresh artifact will rediscover the same pain the hard way.

So the test is not “is this wrong.” The test is:

Where does the knowledge live — in the plan, or only in the code?

If it lives in the plan, end: git reset beats the debugger every time. If it lives only in the code, mend once — and then do the thing that actually matters, which is to move that knowledge back into the plan. Write the edge case into the spec. Add the concurrency note to the acceptance criteria. You mend the artifact exactly long enough to harvest what it learned, and then you make sure you never have to mend it again, because next time the plan will know.

There’s a second failure mode that masquerades as ending: regenerating against the same vague plan that produced the mess. That isn’t ending, it’s thrashing — you’ll get a differently-wrong artifact and spend your comprehension budget all over again. Ending only pays off if you change the input. A regeneration that doesn’t sharpen the plan is just a bare “no” wearing a git reset costume.

Owning the dystopia

It would be too easy to quote Huxley approvingly and miss that he was describing a nightmare. Mindless disposability is corrosive — that was the whole point of the book. So what keeps this from being his consumer dystopia rebuilt in a code editor?

It comes down to where the taste goes. Ending is better than mending only if the attention you save by not salvaging code gets reinvested upstream — in the plan, the acceptance criteria, the specification that the next regeneration will render. Spend it there and ending is leverage: you move your scarce judgment to the highest point in the system, where one improvement propagates into every future artifact. Pocket it instead — regenerate mindlessly, never sharpen the source, let the agent churn — and you’ve built exactly the thing Huxley was warning about, just with tokens instead of textiles.

The discipline, in one line: end the artifact, mend the plan. Be ruthless with the disposable thing and precious with the durable one. That’s the opposite of the dystopia. It’s the only version of “ending is better than mending” worth practicing.

The question I now ask

Before I open the debugger on something an agent got wrong, I ask:

Is this cheaper to regenerate from the plan than to understand and fix — and if I regenerate, what am I changing about the input so I don’t just get the same thing back?

If the knowledge lives in the spec, my hand goes to git reset, not to the stack trace. If it lives only in the code, I mend once, harvest the lesson into the plan, and end it forever after. The expensive resource is my own attention. I try very hard now to spend it at the source, where it compounds — not in the artifact, where it evaporates the next time the agent runs.

— Jed


Background: The plan is the prompt — why the durable artifact is the spec, not the code that renders it. And Pet agents vs. cattle agents — the same disposability logic, one level up.