Most of What the Agent Writes Should Be Thrown Away · Hanh D. Brown

About eighty versions of a single loading spinner went into the bin.

The team built roughly a hundred of them. Ten to twenty reached the product. The rest were written, looked at once, and deleted. That sounds like waste. It was the method.

Something shifted underneath that story, and it is easy to miss, because it looks like sloppiness. When an Artificial Intelligence (AI) agent can produce a working version in minutes, the cheapest route to a right answer stops being thought. It becomes attempts.

Why do teams throw away most of the code an AI writes?#

Teams bin that code because deleting it costs less than deciding in advance.

Take the spinner, the small shape that turns on your screen while a page loads. It went through about a hundred iterations. Between ten and twenty shipped. Roughly eighty went in the bin. Nobody was being careless. Each version was a question, and looking at it on the screen was the answer.

Old economics ran the other way. Building was the expensive part, so effort went into narrowing before anyone touched a keyboard. Meetings, documents, opinions, all of it aimed at reducing how many things you would have to make.

Careful aim was rational when every shot cost a week.

Now a shot costs an hour. So the discard pile is not evidence of failure. It is the shape of the search. Value moved off the code itself, which I wrote about in why code stopped being a moat. When production gets cheap, the scarce thing moves somewhere else.

How many versions of a feature should you build?#

More than feels reasonable. You will know the number when looking gets boring.

One team needed a design for an interactive list. In a day and a half they built between fifteen and twenty working prototypes, then chose from those. Compare that with what the same decision used to cost. Three versions, over a week or two, and a choice made partly on fatigue.

Another feature, a condensed view of a file, took about thirty prototypes. Then a month of the team using it themselves, which produced a dozen more fixes. Then real users, who wanted something different again, which ended in a setting rather than one answer.

Notice what the extra versions bought. Not polish. Information.

Rough guide for how many to build:

• Build until two versions disagree unexpectedly.
• Stop when new ones differ only cosmetically.
• Keep the ugly one that works.
• Bin the rest the same day.

Speed of binning matters here. Unfinished versions left on a shelf start to look like assets, and then someone tries to rescue one.

Why is a working demo better than a written specification?#

A written specification argues about something nobody has seen.

Practice on the team described here is to prototype and show rather than write a requirements document. The stated preference is blunt. Send a pull request instead of a specification. A document asks people to picture the thing and then argue about their pictures, which is how a room of reasonable people reaches a decision nobody likes.

Nobody buys a house from a floor plan alone. They walk the room, and something they could never have named on paper decides it in four seconds.

There is a sharper version of this. A group of agents was pointed at building a plugin system over a weekend. It wrote its own specification, broke that into a board of about a hundred tasks, and implemented them. What came out was close to production quality. The specification still existed. It had simply stopped being the expensive part.

Every plan is a claim about a thing nobody has seen yet. A demo ends the argument.

What does it cost to be wrong half the time?#

Almost nothing, provided the trying is cheap and the result shows up fast.

One number deserves a long look. The model is wrong about half the time, and you cannot tell which half until you try. That sounds like grounds for caution. It argues the opposite. If you cannot tell in advance, thinking harder buys you nothing. Only trying does.

So the strategy inverts. Aim less. Try more.

A fisherman who casts only where he is certain goes home light. One who casts often, and hauls the net in fast, fills the boat.

This is no licence for carelessness. Cheap tries work when the trying reverses easily and the result is quick to judge.

Spending real money is not that. Neither is anything a customer sees before you do, which is exactly where the old discipline still earns its keep. An hour of a person’s day is cheap to risk. A week of it is not.

Economics changed for prototypes, not for consequences. That is the same discipline separating a real bet from a lazy one in how venture capital used to work.

Worth saying plainly. This is early evidence, not settled science. Controlled studies of AI assisted engineering are only now arriving. Two are worth the time: a randomized controlled trial and a diary study.

Treat the numbers above as one team’s experience. They are not an industry constant.

How does cheap prototyping change what you decide to build?#

Cheap prototyping moves the question from whether a thing is worth building to whether it is worth trying.

Those two differ, and the second has a much lower bar. Someone on a developer relations team had the model generate its own launch videos. The lead of that team later admitted he would not have attempted it. He assumed the model was not ready. It worked. His assumption, not the model, was the thing out of date.

That is the quiet tax on experience right now. Priors expire. An idea that failed six months ago may work this morning. An approach that worked may have been overtaken in a year of releases. The only way to know is to retry what you already ruled out.

Most people never do. They carry a ruling made on an older screen and never think to test it again.

Hardest new skill is not technical. It is being willing to be wrong about your own past conclusions.

Fastest teams treat their conclusions as perishable. The habit travels well beyond software. I made the same case in what deep technology asks of a company.

What does this change about how you run a team?#

Managers should make trying cheap, and make stopping cheap too. Second half gets forgotten.

Stated approach is to give people room to fail, on the explicit understanding that most ideas will be bad, then to hold them accountable for cutting losses and moving on. Both halves carry weight. Permission without the discipline to stop produces a graveyard of half finished projects nobody is willing to bury.

A kitchen that punishes a dropped pan gets cooks who never reach for a new one. A kitchen that never clears the counter serves no dinner at all.

Two consequences follow. The barrier to producing something dropped far enough that everyone on that team now writes code, including the manager, the designers and the finance person. And the work changed texture, from long stretches of deep focus to fast switching between several things at once.

What survives is judgment. Being methodical, forming a hypothesis before you look, and knowing what would prove you wrong. Those were always the valuable parts. They are simply no longer buried under the labour of typing.

There is a human version of this too. A team that can try something on a Tuesday afternoon, watch it fail, and stop, is a team whose people get home for dinner. The alternative is six weeks spent defending a plan nobody has seen working, and that bill lands on a family long before it ever lands on a company.

Source: Boris Cherny, Head of Claude Code at Anthropic, podcast interview.