Recovery patterns instead of panic.

It will happen. The app was working, you asked for one change, and now it won't even open — or it opens and everything is wrong. The instinct in that moment is panic, and panic makes it worse: you start frantically asking the AI to fix it, it makes three more changes, and now you've buried the original break under a pile of new ones. The difference between people who recover and people who give up isn't skill. It's having a calm sequence to run instead of panicking. Breaks are normal. Flailing is the actual danger.

I recently deleted a full day of work on LUMINA — a video player I'd been trying to embed in a panel kept breaking. It would've been easy to call that a wasted day. It wasn't a loss. Not everything comes out perfect the first time with AI; testing and adjusting with patience is how you get it right. Everything is backed up in my knowledge base. Sometimes knowing the way not to do something can help you in the future.

What "broken" actually is

A break feels like catastrophe but it's almost always one of a few ordinary things: a change that didn't work, a change that worked but broke something else, or the AI confidently doing something other than what you asked. None of those are mysterious and none of them are permanent — if you have a way back.

The invariant that makes recovery possible is this: your last working version is the floor you can always return to. Everything in recovery is built on that. You're never actually starting from zero; you're starting from the last point that worked. The whole skill is resisting the urge to dig forward through the broken version and instead stepping back to solid ground first. The break isn't the emergency. Losing your way back is the emergency — and that's the one thing you control.

The recovery sequence

When it breaks, you run this, in order, instead of panicking:

Stop changing things. The single most important move. Don't ask for another fix yet. Each new change while broken makes the break harder to find.
Notice what the last working state was. When did it last work? What was the one change between then and now? That change is your prime suspect.
Go back if you can. If you have a save point that worked, return to it. Calm restored. Now you decide whether to re-try the change more carefully.
If you can't go back, isolate. Tell the AI exactly what broke and what you last changed. Ask it to explain the cause before fixing — not to fire off another change.
Fix one thing, then check. One change, run, look. Resist fixing three things at once; you won't know which one worked.

The shape is the opposite of panic: slow down, get to solid ground, change one thing at a time. Panic does all the opposite moves at once.

The video player worked once, then reliably broke. No video. Worse, the app crashed every time I switched away from the panel. I'm patient, so I kept at it: I vibe code, so I rely on the AI to tell me what to do. We went into a manual testing phase where Claude needed my eyes and hands for smoke tests. We went back and forth, and Claude ruled out the teardown order, three different render backends, a COM error that turned out to be a red herring, and an event-callback theory. All reasoned, all wrong. Once Claude instrumented enough to pin the crash inside a native call we couldn't see into, Claude stopped guessing. Every "one more fix" costs a real build-and-test cycle. Claude recommended we try a different architecture that will be more robust, and now we're shifting gears. But we had been working on changes for hours. I didn't merge any of the broken work. I reverted to the last clean version, documented the dead end, scoped a new architecture that sidesteps the problem, and saved the decision. The break didn't cost me anything I couldn't get back — because I never let the broken version become the only version. It cost me time, but again, AI isn't perfect, and if you want to build things, you'll always have bumps in the road.

A worked example

The app worked this morning. You asked the AI to "make the dashboard load faster," and now the dashboard is blank. Panic says: "It's blank, fix it, also fix the colors while you're in there." Recovery says:

Stop. No new requests yet.
Notice: it worked before the "load faster" change. That change is the suspect.
Go back: you have a save point from this morning. Return to it. Dashboard's back. Crisis over — you're on solid ground with zero damage.
Re-approach: now, calmly, "make the dashboard load faster, and after you change it, confirm the dashboard still shows all its data." You named the thing the last attempt silently broke.

Same break, completely different afternoon. The recovery version cost five minutes. The panic version costs the rest of the day.

Panic mode vs. recovery mode

It helps to see panic and recovery as two distinct modes you can actually choose between, each with its own behavior. You can't always stop the feeling of panic — but you can refuse to act from it and run the other checklist instead.

You're in panic mode when:

You're asking for fix after fix without running anything in between.
You're fixing several things at once and hoping one lands.
You've stopped tracking what the last working version even was.

You're in recovery mode when:

You've stopped making changes and taken a breath.
You've identified the one change that came right before the break.
You're back on a working version, or isolating the cause one step at a time.

Two modes, your choice. The skill isn't never feeling panic — it's catching yourself in the panic checklist and deliberately switching to the recovery one.

Door 1 — Build your floor today (beginner)

The recovery sequence only works if you have somewhere to go back to, so the beginner move happens before anything breaks: save a working version every time things work, so your floor always exists. Then, when a break comes, practice the very first step and nothing fancier — stop changing things. Just that pause, held for thirty seconds, prevents most of the damage. You don't need the full sequence yet. You need a floor and a pause.

There are many ways to maintain a memory state on file. I created ForgeOps as a way to save my current focus, decisions, the latest handoff, and the registry — the project's memory, living outside any model, so Claude or Codex can pick up where I just left off and keep going.

The procedures are the skills: forge-load, forge-scope, forge-build, forge-pr-loop, forge-close, align-prd, align-roadmap. These aren't data; they're written recipes that tell whatever LLM is driving how to read the state, do the next unit of work, and write the state back correctly. A save file doesn't tell you how to play — ForgeOps ships the playbook alongside the save.

You don't have to use ForgeOps, but you need to find a way to save your state regularly. You can even have Claude help you build your own. For long-term projects you need a persistent memory that knows what you've done and the last thing you were working on.

Door 2 — Recover like you've been here before (advanced)

Once "stop and go back" is reflex, the upgrade is recovering with diagnosis instead of just retreat. You learn to make the AI explain the cause of a break before it touches anything, so you fix the real problem instead of papering over it. You start asking for changes in a way that names what to protect — "do X, and confirm Y still works" — so fewer breaks happen at all. The beginner recovers by going back; the advanced builder recovers by understanding, so the same break doesn't keep returning. Same invariant — the last working version is your floor — just used as a base camp for diagnosis rather than a place to hide.

I used to create a .zip file with a date every time I got to a good "saving point" while vibe coding. You end up with a ton of save files, and if you don't focus on documentation it becomes a really big mess. Even if you document things, it's still data piling up — and if you walk away for a while, it's hard to come back and remember what you were working on. With a persistent memory you can always pick up right where you left off. ForgeOps updates the documentation for you, which makes my life much easier. Saved state and updated docs make all the difference.

The deep point

Recovery is what makes building with AI sustainable instead of terrifying. If a break can end your project, you'll build timidly and quit at the first real one. If a break is just a routine you have a sequence for, you'll build boldly and stay in the game long enough to get good. The willingness to keep going is downstream of knowing you can always get back.

There is a line — a balance between who's going to "drive the car," and when. Sometimes AI should drive, and sometimes you should. Operating with a system like ForgeOps that lets you save and control your changes makes a huge difference, but at the end of the day you're going to have to put in some time and figure out when you need to be holding the wheel and when AI should steer. Good projects are a collaboration between the user and the agents. You need to hold tight to your vision and communicate it clearly. You need to understand what the AI is telling you, even if you have to have it break things down into simple terms. Don't be afraid to question or challenge the AI's decisions if you feel they're not aligned with what you really want. You'll know you have the right balance when you're getting strong results aligned with your vision and the AI is doing the heavy lifting.

Get ForgeOps

The ForgeOps agentic system solves the issues we talked about and more. You can buy ForgeOps right now on Gumroad at https://tristateaiconsulting.gumroad.com/l/forgeops for $27. Never lose your place on a project again, and never get stuck somewhere you can't recover from. That's the power of ForgeOps — try it for yourself.