tropo

Rung 08 · The Agentic Builder Series

When the Build Goes Sideways


The Build Loop, same as every rung — spec, direct, checkpoint, verify. Every prior rung quietly assumed the build mostly goes right. This one is about the run that goes wrong, because that's most of the job.

The tutorials all show you the happy path. You write the instruction, the agent builds the thing, it works, everyone's delighted. Real directing looks different, and you should hear it plainly now rather than discover it alone at 4 p.m.: a large share of the time, the agent will confidently build the wrong thing. Not broken — wrong. It will hand you something polished, plausible, and not at all what you meant, and it will do so with the serene confidence of a worker certain it nailed the brief.

This is the moment that separates people who direct agents well from people who give up on them. It is not a sign you're bad at this. It is the normal texture of the work. The skill this rung teaches is what to do in exactly that moment — because your instinct will be one of two wrong things.

The two instincts to distrust

When a build comes back wrong, most people reach for one of two reflexes.

The first is to start over from scratch — throw it all out, open a blank session, retype everything. Sometimes right, usually wasteful; you discard work that was mostly fine and re-explain context you'd already established.

The second, and more dangerous, is to keep nudging a doomed run — "no, not like that," "closer, but," "try again," round after round, each tweak a little more frustrated, because you've already spent twenty minutes and stopping now feels like admitting the twenty minutes were wasted. This is sunk cost wearing the mask of persistence. The agent has gotten confused, is now building on its own confusion, and no number of small corrections will untangle it.

The way out is to stop treating every wrong build the same and learn to read which kind of wrong you're looking at. There are three, and they escalate.

The escalation ladder

Redirect. The approach is right; one specific thing is off. It built the report but sorted it wrong; it made the form but missed a field. Point at the exact thing — "the date column should be newest-first" — and let it fix that alone. This is the cheapest move and the most common. Most sideways builds need one clean redirect and nothing more.

Restart. The approach is right, but the run is tangled — you've gone six rounds, the agent has lost the thread, and every fix spawns a new problem. Don't keep wrestling it. Open a fresh session and give it a clean spec — the one you now know how to write, because this failed run taught you exactly what you'd left ambiguous. You keep the good files; you discard only the confusion. A restart with what you've learned is not starting over. It's starting better.

Abandon. The approach itself is wrong. No redirect fixes this and no restart fixes this, because the problem isn't the execution — it's the plan. You asked for the wrong thing, or the thing you asked for can't work the way you imagined. Back all the way up to the spec and rethink it. This is the rarest and the one people resist hardest, because it means the mistake was upstream, in your instruction, not in the agent.

Reading which rung of that ladder you're on is the entire skill. And there's a simple rule that keeps you honest about it.

Correct twice, then take it back

Here is the stopping rule worth taping to your monitor: give the agent two clear corrections. If two don't land, the problem is not the agent's execution — it's your spec or your approach. Take the work back and fix the upstream thing.

Two clean redirects that both fail to land are not telling you the agent is stupid. They're telling you that you're redirecting toward a target your instructions never actually described — that the ambiguity is in the spec, and you've been asking the agent to guess your intent instead of read it. The correction you actually need isn't another nudge. It's a better spec, or a different plan.

This rule does something quietly important: it caps your losses. Without it, a bad run can eat an afternoon one hopeful tweak at a time. With it, no sideways build costs you more than two corrections before you step back and diagnose. You will be astonished how much calmer directing feels once "how long do I keep trying?" has a fixed answer.

The wrong build is information

Here's the reframe that turns this from frustrating to useful. A confident wrong build is not a wasted run — it's a diagnosis. The agent built exactly what your instructions, read literally by a worker with no memory and no taste, actually described. Wherever it went sideways is precisely where your spec was ambiguous. The mistake is a map of the gap between what you said and what you meant, and you can't get that map any other way.

And notice the safety net underneath all of this — the one you built in the earlier rungs without knowing you'd need it here. Because your work lives in files and you've been checkpointing along the way, abandoning a bad run costs you almost nothing. You back up to the last good file and go again. The reader who kept everything in one long unsaved conversation has no such luxury; a sideways build there is a catastrophe, because there's nothing to fall back to. You have somewhere to fall back to. That's not luck. That's the governance quietly paying you back.

Correct twice, then take it back.


→ The companion — In Tropo: When the Build Goes Sideways — hands you a build that's about to go sideways and walks you through diagnosing it as a redirect, a restart, or an abandon, then recovering cleanly from your last good file. The recovery is the part that turns fear of the wrong build into a shrug.

Power Play

Want to take this further? When a build comes back wrong, don't just fix it — make the agent show you why it went wrong. Before you correct anything, give it this:

"You built this as X, but I wanted Y. Before we change anything, tell me: what in my instructions led you to build X? Quote the specific words you read that way, and tell me what you assumed where I wasn't clear."

The agent will point straight at the ambiguous sentence — the phrase you thought was obvious and it read two ways. Now you're not fixing the symptom (this wrong build); you're fixing the root (the spec that will produce ten more wrong builds if you leave it). One good round of this and your specs stop generating the same class of mistake, because you've found the exact words that mislead.

Terms worth knowing

  • Redirect / restart / abandon — the three responses to a wrong build, in order of cost: fix one thing · start a fresh session with a better spec · back up to the plan itself.
  • Sunk cost — the trap of continuing a doomed run because you've already invested in it. The "correct twice" rule exists to break it.
  • Rolling back — returning to your last good saved file after a bad run. Cheap and safe when your work lives in files; impossible when it lives only in one long conversation.