The AI Learning Hub Journal

The Doom Loop

The doom loop, and the way out — which points backwardseach fix lands on code that keeps shifting underneath — with no solid point to compare againstTHE DOOM LOOP — EVERY TURN DIGS DEEPERsomething breaksthe fix "works" —a new thing breakstry another fix,checking less each timean hour later you arefurther from workingthan when you startedfrustration speeds you up exactly when you should slow downthe way outTHE WAY OUT IS BACKWARDSstop — no "one more try"return to the last saved, checked versiondiscard everything since — the hour isalready spent, and the code it made isa tangle of fixes for fixesthen: one change · check · save · repeatRULES THAT STOP IT STARTINGthree failed fixes on one problem = revertnever stack a change on an unchecked onethirty minutes stuck = step awaydecide these rules while you are calmOR START A FRESH CONVERSATIONlong chats hoard wrong turns — open a cleanone, paste the spec and the problem, andkeep the code — drop only the argumentTHREE FAILED FIXES MEANS STOP — GO BACK TO THE LAST SAVED, CHECKED VERSIONthe loop, not the tools, ends most first projects — and saved copies are the only door out
Each fix breaking a new thing is the doom loop — the way out is backwards, to the last version you saved and checked.

How It Starts

The pattern is unmistakable once you have seen it. Something breaks. The fix works, but a different thing breaks. That fix breaks a third thing. An hour later you are further from working than when you started. The code has changed in ways nobody can describe, and every message you send is more desperate than the last. This is not a sign of a bad tool or a bad builder. Each fix is being applied to a system that keeps changing underneath, with no known-good point to compare against. And a frustrated person accepts changes faster and checks them less. Recognising the loop early is most of the cure, because it gets harder to escape the longer it runs.

  • Each fix creates a new break; you drift further from working
  • It is a predictable pattern, not evidence of incompetence
  • Frustration makes you check less exactly when you should check more
  • The longer it runs, the harder it is to reverse — spot it early

The Way Out Is Backwards

The escape is unintuitive, and it is the same every time. Stop, and go back to the last version you know worked. Not the version you think might have been fine — the one you saved and verified. Everything after that point is discarded, and that hurts, because it contains an hour of effort. Discard it anyway. The hour is already spent, and the code it produced is a tangle of half-fixes for problems that only exist because of other half-fixes. From the known-good version, make one change, check it, save it. If the same break returns, you now have a clean, repeatable problem to describe instead of a mess. This is why the copies matter. Without them, there is nothing to go back to.

  • Stop and return to the last verified working version
  • Discard the intermediate work — it is a tangle of fixes for fixes
  • Then one change, check, save — and only then the next change
  • Without saved copies there is no way out, only forwards into more mess

Rules That Prevent It

A few rules, decided in advance, keep the loop from starting. Three failed fixes for the same problem means stop and go back — no exceptions, and no "one more try". Never accept a change you have not checked. Never make a second change while the first is unverified. Save a copy before anything risky. Put a time limit on frustration: thirty minutes stuck is a signal to step away, not to try harder. These rules are boring. They are also the difference between people who ship something and people who abandon a project, calling the tools unreliable. The tools are usually fine. The loop is what actually ends most first attempts at building something.

  • Three failed attempts at the same problem: stop and revert
  • Never stack a second change on top of an unverified first one
  • Set a frustration time limit and honour it
  • Decide these rules while calm, because you will not invent them while panicking

A Fresh Start Beats a Long Argument

One more escape route: start a new conversation. Long sessions accumulate wrong turns, abandoned approaches and contradictory instructions. All of that context keeps influencing what comes back. Sometimes the fastest fix is a fresh conversation. Paste your spec and the current problem, and describe it cleanly, with none of the history. It often produces a completely different and better answer, simply because it is not weighed down by an hour of confusion. Keep the spec somewhere pasteable, precisely so this is cheap to do. Starting a new conversation is not the same as starting the project over. You keep the code; you discard only the argument.

  • Long conversations accumulate contradictions that keep steering the output
  • A fresh session with the spec and the current problem often unsticks things
  • Keep the spec pasteable so a clean restart costs seconds
  • New conversation is not the same as new project — keep the working code

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.