Article 4: Fail fast, three strikes

The fourth article in my personal coding constitution is a rule about when to quit, written for somebody who is bad at quitting. Three attempts to fix the broken thing. If the third attempt doesn't land, you stop. You don't try a fourth. You go back to planning.

I'll save you the suspense: the rule doesn't say "give up after three." It says "stop and re-plan after three." There's a difference. Quitting is closing the laptop. Re-planning is admitting that the model of the problem you've been operating on for the last hour is wrong, and that the next thing to produce is a new model, not another attempt at the same one.

The rule exists because I keep catching myself doing the thing it forbids.

The failure mode I keep walking into

Here is the failure pattern I have lived a hundred times, in roughly this order.

You start fixing something. The first attempt looks good: it runs, it almost works. The thing it doesn't do is the small remaining part you understand perfectly well. You'll just adjust this one variable. Second attempt, closer, but now there's a different small remaining part. You'll just adjust this other variable. Third attempt, closer in some ways, further in others. The error message has moved. You don't know whether you're making progress or moving the bug around.

This is the moment the rule applies. Three attempts in, the error has moved twice, you don't have a confident model of why your previous attempts failed, and the only honest summary of the last hour is "I'm trying things." Trying things is fine. Trying things in the editor instead of in your head is the problem.

The fourth attempt almost never works. I've tracked this for myself, informally, for years. When I'm on attempt four it's because I've decided the third failure was bad luck and the fourth will be the one. The fourth is also bad luck. So is the fifth. The sixth attempt is when I usually realize I've been holding the wrong mental model since attempt one, and now I've burned an hour proving it.

The cost is two things, neither obvious. The first is the hour itself. Cheap, in the grand scheme, and recoverable. The second is the hole I've dug in the codebase, six half-applied patches across four files, none of them quite reverted, all of them tangled in ways I no longer remember. That hole is the expensive part. Re-planning from a clean tree is fast. Re-planning from a half-mutated tree is slow and error-prone.

Three strikes is the marker that says: stop digging.

What "re-plan" actually means

The rule isn't useful unless you know what to do at the moment it triggers. "Stop and re-plan" is the slogan. The mechanics are:

Revert the partial work. Whatever the editor has between attempts one and three, throw it away. The reasoning is that the partial work was driven by a model you no longer trust. Keeping a partial patch from a busted model is the worst of both worlds, you carry the cost of the diff without the confidence of the intent.

Write down what you actually know. Not what you suspected, not what you assumed: the verified facts, the error message text exactly, the line that failed, the conditions that reproduce, and the conditions that don't. This step is annoying because it's slow and feels like backwards motion. It's the step that pays for itself the fastest.

Find the assumption that's wrong. Three failed attempts means there's at least one load-bearing assumption that you held going in that turned out to be false. The re-plan is the search for that assumption. Sometimes it's "the function returns the type I think it does." Sometimes it's "the agent is operating on the file I think it is." Sometimes it's "the tests are exercising the code path I think they are." Whatever it is, name it plainly.

Form a new hypothesis. Test it before you patch. The next thing to produce is a small probe (a print statement, a unit test, a manual call against the API) that confirms or denies the new hypothesis. Not a fix. A diagnostic. The fix can wait until the diagnostic agrees with the model.

Now you can attempt again. You're not on attempt four; you're on attempt one of a new model. The clock resets, and you get three attempts on the new model.

This is the discipline. Three strikes per model. New model, new clock. The rule stops you from dragging a broken model into a tenth attempt by pretending each attempt is independent.

The agent version

The rule maps almost word-for-word to working with AI agents, and the failure mode is louder there.

When I hand an agent a task and it produces a diff that doesn't quite work, the cheap move is to paste the error message back and say "fix it." The agent will produce a new diff. Sometimes the new diff works. Often the new diff fixes the surface error and breaks something else. Three rounds of that and the diff is a tangle of partial patches the agent can no longer reason about cleanly, because the agent's context is full of failed attempts and the model it's now operating on is a hybrid of three different models I never asked for.

The fix is the same fix as for me. After three rounds, stop. Revert. Reset the agent's context if you can, start a fresh session, hand it the original task and the verified facts about what failed, and ask it for a plan, not a patch. The agent's first response in the fresh session should be a hypothesis about why the previous attempts failed, and a small probe to confirm. Then a patch. Then go round by round, and remember that you have three attempts on the new model before the rule fires again.

The agent failure mode is louder because agents don't get tired and don't notice they're flailing. A human flailing for an hour will eventually feel the flail. An agent flailing for an hour will produce confident, well-formatted, plausible-looking diffs the entire time. The supervisor (me, you) has to be the one watching the clock. Three strikes. Reset.

What three is, and isn't

Three isn't a magic number. It's the number that falls out of "enough attempts that you've genuinely tried the obvious things, few enough attempts that you haven't dug a hole." Two is too few, the first attempt failing for a stupid reason is common enough that you should be allowed a second. Five is too many, by the fifth attempt you've already burned the time and the hole is already dug.

Three is also the number that's small enough to be a hard limit. The rule has to be uncomfortable to be useful. If the limit is "five or six, depending on how it feels," it's not a limit. It's a vibe. Three is small enough that you notice when you're past it, which is the whole point.

The rule isn't "you only get three attempts to ever fix this thing." It's "you only get three attempts on the current model of why it's broken." When the model changes, the count resets. The discipline is the model-counting, not the attempt-counting.

When the rule is wrong

The rule is wrong in a small set of cases that I've collected over time. Worth naming so I don't pretend they don't exist.

Sometimes the bug is genuinely in a flaky external system and attempt four works because the external system came back. The rule still fires, because you should still re-plan, the new plan is "wait for the external system, confirm it's stable, then retry once." The fact that attempt four would have worked anyway doesn't mean attempt three should have happened.

Sometimes the bug is one keystroke off and you know it and the fourth attempt is genuinely the obvious typo fix you missed. Fine. The rule isn't a court order. It's there to force the issue for the much larger class of cases where you're flailing and don't know it. If you genuinely know it's a typo, the cost of stopping to re-plan is small and the gain is small and you can override the rule. The rule is here for the cases where the override would be wrong.

Sometimes you're plainly in exploratory mode, you don't have a model yet and you're prodding at the system to build one. The rule still applies, but the "model" is the hypothesis you're prodding with. Three failed prods, write down what you've learned, form a new hypothesis. The rule is about not pretending the prods are fixes.

What this is really a rule about

The article is about quitting attempts that aren't working. The rule underneath it is about respecting your own model of the problem. When the model is right, the fix is usually easy. When the fix is hard, the model is usually wrong. Three failed attempts is the cheapest signal I know that the model is wrong, and the rule is the cheapest discipline I know for acting on the signal instead of ignoring it.

This pairs with article one's no-issue-no-code rule, the issue is where the original model gets written down, and the issue is where you update the model when it shifts. Without the issue, the model lives in your head, which is where it's hardest to notice when it's gone wrong. The articles in this series are stackable for a reason. None of them are interesting alone. All of them earn their keep when the day is bad.

Three strikes. Then stop, re-plan, and start over with a model you actually believe in. That's the rule.

, Sid