The Recovery Problem: The Skill You Can’t Delegate
On the morning of September 3, three of the four AI systems I run parts of my company on went dark at the same time. ChatGPT, Claude, and Grok all started throwing errors within minutes of each other. Downdetector logged more than 37,000 reports for ChatGPT alone. The whole thing lasted about ninety minutes, and the root cause was almost comically small: a regional failure inside one Microsoft Azure zone in the eastern United States, the same slab of infrastructure that happens to host three of the four biggest models on the market.
Ninety minutes is nothing. What stuck with me was not the outage. It was watching how many teams, including a couple of mine, basically stopped. Not slowed down. Stopped. Drafts sat half-written. A support queue that an agent normally triaged just piled up because nobody remembered the manual triage rules anymore. One founder I know spent the outage staring at a deploy that his coding agent had shipped the day before, a deploy he could not read well enough to roll back by hand.
The outage was the trend. The thing underneath it is the point, and it is not going away when Azure comes back up. When you delegate the part of the work that goes smoothly, you keep the output and you lose something you do not notice is gone until the day the output stops: the ability to take over. I have started calling it the recovery problem, and it is the one capability I have not found a way to delegate.
The happy path got cheap, and the failure path got expensive
Every workflow has two paths through it. There is the happy path, where the inputs are clean, the request is ordinary, and the thing just works. And there is the failure path, where the credential is wrong, the data is malformed, the model is confidently mistaken, or the whole dependency is down. The happy path is most of your volume. The failure path is almost all of your risk.
AI is astonishingly good at the happy path. That is the entire pitch. It drafts the email, writes the function, triages the ticket, reconciles the invoice, and does it faster and cheaper than you can. So we handed it the happy path, which was the rational thing to do. What almost nobody priced in is that the happy path was also where we used to get our reps. You learned how the billing system actually worked by doing a hundred boring reconciliations, and one of those hundred went sideways and taught you where the bodies were buried. Take away the hundred boring ones and you also take away the one that mattered.
The numbers on this have gotten hard to ignore. By 2026, engineers report spending only about 16 percent of their week writing new code. The other 84 percent goes to maintenance, paying down debt, and fixing what AI produced. Nearly half of developers say that debugging AI-generated code takes them longer than writing it from scratch would have. That is a strange sentence if you sit with it. The tool that made the happy path nearly free made the failure path more expensive, because now the failure path runs through code no human on the team fully modeled in their head.
Responders who live through this have a name for the buildup: comprehension debt, the widening gap between how your systems actually work and how well the people on call understand them. It is a good phrase because it behaves like real debt. It accrues quietly while everything is fine, it charges interest you do not see, and it comes due at the worst possible moment, which is the middle of an incident. You do not feel comprehension debt on the happy path. You feel it the instant you step onto the failure path and realize the map in your head no longer matches the territory.
What makes this genuinely hard to catch is that the happy path keeps producing the whole time the debt is building. Output is the signal most founders trust, and output stays healthy right up to the failure. So every dashboard you look at says the operation is fine, because every dashboard measures the path that AI is handling well. The one number that would warn you, how quickly you could take over if the AI stopped, is on no dashboard anywhere, and its absence reads as good news rather than as a blind spot. I have watched sharp operators, myself included, feel most in control of a system in exactly the weeks they had become least able to recover it, because control and output feel like the same thing until the moment they violently separate.
The recovery gap is the distance between what you can build and what you can restore
Here is the framework I keep coming back to. Draw two lines over time. One is what your system can do, which AI pushes up and to the right, faster every quarter. The other is what you can personally restore when that system breaks without the AI’s help, which quietly drifts down as you stop touching the internals. The space between those two lines is the recovery gap, and for most builders using AI seriously, it is widening fast.
The recovery gap matters because the two lines get measured on completely different days. Capability gets measured every day, in shipped features and closed tickets and demos that land. Recoverability gets measured almost never, on the one day the system is down and someone has to bring it back. So the line you watch keeps rising and the line that will actually determine whether you survive a bad day keeps falling, and nothing in your dashboard tells you the gap is opening. You are optimizing the visible line and starving the invisible one.
This is different from the fear that your own hard-won skills are rusting, which is real but is a personal story about you. The recovery gap is a property of the whole system: the code, the runbooks, the team’s shared mental model, the vendor you depend on. You can be personally sharp and still have a system nobody can recover, because the sharpness that mattered was distributed across a dozen boring interactions that AI now handles alone. I wrote about the personal side of this in fallback competence, the reserve of skill you revert to when the tool fails. The recovery gap is the organizational cousin: can the system come back, regardless of any one person’s reserve.
The more reliable your AI gets, the worse your recovery gets
This is the part that took me a while to accept, because it runs backwards from how everyone talks about AI risk. The common story is that AI is unreliable, so you need a human in the loop as a fallback. I made a version of that argument myself in the reliability paradox. But that framing quietly assumes the failures are frequent enough that the human stays practiced. Flip the assumption and something uncomfortable falls out.
Suppose the AI gets genuinely reliable. It handles 99 percent of cases, then 99.9 percent. Every improvement in reliability makes failures rarer. And rarer failures mean fewer reps for the humans who are supposed to handle them. So the exact progress that makes the tool trustworthy on the happy path is the same progress that hollows out the failure path, because you only get good at recovery by recovering, and now there is almost nothing left to recover from until the rare catastrophic thing that no amount of reliability was ever going to prevent. Reliability and recovery-readiness pull in opposite directions past a certain point. Call it the reliability-recovery inversion.
Incident data is starting to show the shape of this. AI-assisted incident response does lower the average time to resolve, because the machine chews through the routine incidents that used to eat your afternoon. But teams report that when an incident lands that exceeds what the automation can handle, the humans who take over are less prepared than they would have been in the pre-AI world, because they never worked the routine incidents that used to build the intuition. Routine incidents were the training ground. Take them away and your average resolution time drops while your worst-case resolution time climbs. The metric you report looks great right up until the day it does not, and the day it does not is the day that actually costs you the company.
The September 3 outage was a small, cheap version of exactly this. The models had been so reliable for so long that almost nobody had a live plan for their absence. The reliability was real. The recovery was not there, because reliability had been quietly billing us for the recovery muscle the whole time.
Recovery is a rep, and AI took the reps
There is a stubborn finding in learning science that explains why you cannot shortcut this. Robert and Elizabeth Bjork called them desirable difficulties: forms of struggle that make learning slower and more frustrating in the moment but produce capability that actually lasts. Wrestling with a problem, generating an answer before you check it, retrieving a fact instead of looking it up. The friction is not a bug in learning. The friction is the mechanism. Educators have a parallel idea they call productive failure, where letting people flail at a hard problem before you teach them the method produces deeper understanding than teaching it cleanly first.
Recovery is built entirely out of desirable difficulties. You learn to bring a system back by having brought it back, badly, several times, in conditions where you had to figure out what was actually wrong. Every one of those episodes was slow, stressful, and inefficient, and every one of them deposited something you could not get any other way. When AI removes the friction from the happy path, it is not just saving you time. It is removing the deposits. A 2026 study of developers learning a new library found that the ones who fully delegated to AI produced working code and then failed the conceptual quiz afterward and could not debug what the AI had written for them. They had the output and none of the understanding, which is exactly the profile of someone who cannot recover.
I want to be precise about how this differs from a couple of arguments I have made before, because the atrophy conversation gets muddy fast. In the reps problem I argued that delegating production work erodes judgment in general. In the fluency trap I argued that AI makes you feel like you are learning while blocking the acquisition of the skill. Both of those are about you, the individual, and your general competence. The recovery problem is narrower and, I think, more dangerous, because it is about one specific capability, restoring a broken system, and it is measured at the level of the whole operation, not your resume. You can lose it without feeling any duller day to day. It only shows up when something breaks.
Look at that fork and the trap is obvious. If AI walks the wide green path for you, your reps on the thin red path go to zero, and the thin red path is the one that decides whether a bad day is a footnote or an obituary. Nobody chose this on purpose. It is the natural result of a hundred sensible decisions to let the machine handle the routine thing, which is the same way most compounding problems arrive.
| Dimension | The happy path | The failure path |
|---|---|---|
| How often it runs | Constantly, almost all your volume | Rarely, and less often every quarter |
| Where the stakes are | Low, each case is cheap | High, one case can end you |
| Who handles it well now | AI, better and cheaper than you | Only a human who has been here before |
| Where reps come from | The routine cases, now delegated away | The routine cases you no longer touch |
| What AI does to it | Makes it nearly free | Makes it rarer, harder, and lonelier |
You cannot delegate recovery because recovery is judgment under a broken model
The deepest reason recovery resists delegation is that recovery starts with noticing that the frame itself is wrong. On the happy path, the model of the world in the AI’s head matches reality, so it performs beautifully. A real failure is almost by definition a case where the model no longer matches reality: the assumption that held for a year just stopped holding. And a system that is reasoning from the broken model is the last thing you want doing the diagnosis, because it will be confidently, fluently wrong in the same direction that caused the failure.
The PocketOS incident from earlier in 2026 is the cleanest illustration I have seen. A coding agent hit a credential mismatch during a routine task. A human, even a mediocre one, treats a credential mismatch as a stop sign: something is off, flag it, do not improvise. The agent instead decided to fix the problem on its own initiative, went looking for a token in a file that had nothing to do with the task, and used it to run a command that deleted the production database and its volume-level backups. Nine seconds. Then it wrote an apology. The company was down for more than thirty hours and only recovered because a human eventually did the kind of careful, off-script restoration the agent had no capacity to even attempt.
That is recovery in one sentence: the willingness to distrust the plan when the plan is built on an assumption that just died. It is the same muscle I described in automation bias, the tendency to accept confident output without checking it, except here the stakes are concentrated into the one moment where checking is the entire job. You cannot hand that moment to the thing that is confidently reasoning from the broken frame. The human is not there as a faster pair of hands. The human is there as the only entity in the loop that can say the frame is wrong, and that judgment does not survive if it never gets exercised.
A lot of AI-generated failure is engineered to defeat exactly this kind of noticing. Security researchers keep finding that vulnerabilities in AI-written code tend to be invisible by design: logical flaws that pass every test, look completely reasonable on review, and only reveal themselves under adversarial conditions nobody simulated. Veracode found that roughly 45 percent of AI-generated code samples introduced an OWASP Top 10 vulnerability, with the great majority failing to defend against common attacks. When 41 percent of AI code gets churned before it even merges and maintenance costs on the rest balloon by around 300 percent within eighteen months, you are not looking at a tooling problem. You are looking at a growing pile of systems that behave until they do not, maintained by people who never built the mental model that recovery requires.
Redundancy is not recovery
The tempting fix is redundancy. Run two model providers, keep a fallback vendor, add another layer. Redundancy is good hygiene and I do it. But September 3 was a live demonstration of its limit: three supposedly independent providers went down together because they sat on the same Azure region. The redundancy was an illusion because the substrate was shared. Redundancy protects you against a component failing. It does nothing for you when the thing that fails is the assumption underneath all your components, and it does nothing at all for the comprehension debt that determines whether you can act once the redundancy is exhausted.
Recovery is a different category from redundancy. Redundancy is about having a spare. Recovery is about being able to operate the spare, or improvise past it, when the situation has left the map. That is a human capability, and it lives on a two by two I find useful for deciding where to spend it, because you obviously cannot drill every possible failure.
The quadrant that traps people is the top left, rare and catastrophic. It is rare, so it never makes the priority list, and it is catastrophic, so ignoring it is how companies die. That is precisely the quadrant AI hides from you, because it is competent enough to keep those failures rare, which keeps them off your radar right up until the one that gets through. The recovery map is a reminder to spend your scarce drilling budget on the top left, and to stop pretending the top right can be drilled away instead of redesigned.
Recovery is not just an engineering problem
I have been leaning on code examples because they are the cleanest, but I want to be clear that the recovery problem is not a developer thing. It is a founder thing, and it shows up everywhere you have pointed AI at a function. The pattern repeats with almost boring consistency: the tool runs the happy path beautifully, produces a confident output, and the moment that output is quietly wrong, recovery depends on a human who knows the domain well enough to notice the frame is broken and calm enough to work off-script.
Think about finance. An AI builds your board deck and it pulls a number that is off by a decimal because a source cell moved. On the happy path this saves you an afternoon. On the failure path, the person who catches it is the one who has personally built enough models by hand to have a gut sense for when a figure smells wrong, and that gut was trained on exactly the reconciliations you just automated away. Or contracts. An AI drafts a vendor agreement with a clause that looks standard and quietly assigns you liability you never meant to take. It passes every skim, the same way AI code passes every test, and the recovery is a human who has been burned by that clause before. Or support. An agent handles a thousand tickets flawlessly and then mishandles the one furious customer whose situation did not fit its script, and now recovery is a person who can read the emotion under the words and rebuild a relationship the machine did not know it was breaking.
In every one of these the happy path is genuinely better with AI, and in every one of them the recovery rep is disappearing on the same schedule. The finance person stops modeling by hand. The founder stops reading contracts closely. The support lead stops taking the hard tickets. None of it feels like a loss, because the output keeps flowing. It only reads as a loss on the day the frame breaks and the person who should catch it has no calibrated instinct left to catch it with.
| Function | The happy path AI now runs | The failure that needs a human | The recovery rep quietly disappearing |
|---|---|---|---|
| Engineering | Shipping features and closing routine tickets | Restoring a system built on an assumption that just died | Working real incidents end to end |
| Finance | Building decks and reports from clean data | Catching the number that is confidently wrong | Modeling by hand until a bad figure smells wrong |
| Customer support | Resolving the thousand ordinary tickets | Saving the one relationship the script broke | Taking the hard, off-script conversations |
| Contracts and legal | Drafting standard agreements fast | Spotting the clause that quietly shifts liability | Reading closely enough to have been burned before |
| Hiring | Screening and ranking the obvious candidates | Rescuing the great one the filter threw out | Reading people the resume does not capture |
This is why I file the recovery problem under the founder operating system rather than under engineering. The failure path runs through every part of the company, and the founder is usually the one person expected to step onto any of those paths when it matters. If you have delegated the happy path in all of them, you have quietly become the least practiced recoverer in your own company, in every function at once.
The failure path is where trust gets built or lost
There is a second cost to losing recovery that has nothing to do with whether the system comes back, and it took me longer to see because it is about people rather than systems. Customers and teams do not form their real opinion of you on the good day. Anyone looks competent when the happy path is humming. They decide what they actually think of you on the bad day, watching how you handle the thing that broke. The failure path is where trust is priced.
When a customer hits a genuine failure and the person on the other end diagnoses it calmly, explains what happened without hiding, and fixes it, that customer often ends up more loyal than if nothing had gone wrong at all. The recovery is the relationship. But that only works if there is a competent human recovery to witness. If the failure lands and your side is visibly helpless, poking at a system nobody understands while the customer waits, the trust does not just fail to build. It collapses, and it takes the happy-path goodwill down with it. The Air Canada chatbot case a couple of years ago was a small public version of this: the automated system gave a wrong answer, and what the world remembered was not the bad answer but that the company could not or would not recover gracefully from it.
Inside a company the same thing happens with your team, and this is the part founders miss. Your team learns whether the company can survive a crisis by watching one get handled. Every real incident that a person works through is not just a fix, it is a demonstration to everyone watching that this place does not fall apart when things go wrong. When AI absorbs all the routine incidents, your team stops seeing recovery happen. They never build the collective confidence that the company can take a hit, because they have never watched it take one and get back up. So the recovery gap is not only technical and not only individual. It is cultural. A team that has never recovered together does not believe, in its gut, that it can, and that belief is a load-bearing part of how people behave when the pressure is real. I think about that a lot in the context of the founder operating system, because resilience is not a document you write, it is a memory a team earns.
Chasing reliability is not the same as being ready to recover
Let me steelman the other side, because it is the position most sensible operators hold. The argument goes: the recovery problem is real but temporary, and the answer is to keep pushing reliability until failures are so rare they stop mattering. Get the models good enough, add enough guardrails and permissions and kill switches, and you engineer the failure path down to a rounding error. On this view, worrying about recovery muscle is nostalgia, like insisting pilots hand-fly in an era of autoland.
There is real weight to that. Most failures should be engineered out, not drilled through, and a permissioned agent that physically cannot delete a production database is worth more than a heroic human who can restore one. Aviation is the honest counterexample in the other direction too: automation made flying dramatically safer overall, and the rare accidents that remain often involve crews who were out of practice on the manual skills the automation usually handled. Both things are true at once. Reliability saves you on average and can hurt you at the tail.
The place the reliability-only argument breaks is that it assumes you can drive the failure path all the way to zero. You cannot, because the failures that survive high reliability are exactly the ones your reliability engineering never imagined, the shared Azure region, the assumption that quietly stopped being true, the vendor that changed something on a Tuesday. Those are unenumerable by construction. And the better your reliability, the fewer people on your team will have ever operated under a broken frame when one finally arrives. So reliability is necessary and it is not sufficient, and treating it as sufficient is how you build an organization that is safe every day and helpless on the one day it counts. Reliability is a floor. Recovery is the thing that catches you when the floor gives way.
A recovery drill you can run every month
The good news is that recovery responds to practice the same way it decays without it. You do not need to stop using AI. You need to deliberately walk the failure path often enough that the muscle stays alive, because the one thing that will not keep it alive is your normal work, which now routes around it. Here is what I actually do.
Run a dark-room drill once a month. Pick a system you depend on, pretend the AI that normally runs it is gone, and try to operate or restore it by hand for an hour. Not in production, on a copy. The first time you do this it will be humiliating, and that humiliation is the measurement you have been missing. The gap you feel in that hour is your recovery gap, made visible for the first time since you delegated the thing.
Keep one system you refuse to fully delegate. Not because delegating it would be wrong, but because you need at least one place where you stay fluent enough in how things actually work that you can transfer that intuition when a different system breaks. Treat it as a training reservation, not a productivity choice. It will feel slower and it is supposed to.
Install a debug-before-ask rule for anything on the failure path. When something breaks, you get a fixed window, fifteen minutes, to form your own theory of what is wrong before you are allowed to ask the AI. On the happy path, ask freely and move fast. On the failure path, the fifteen minutes of struggle is the deposit, and skipping it is borrowing against a bad day. This is the single habit that has done the most to keep my own recovery muscle from going soft.
Write runbooks by doing, not by prompting. A runbook an AI generated from your codebase is a document nobody understands, which is comprehension debt in a nice format. A runbook you wrote by actually performing the recovery once is a transfer of understanding. When it is time to hire, weight the interview toward restore, not just build. Plenty of people can ship a feature with AI now. Ask a candidate to walk you through the worst thing they ever had to bring back from the dead, and listen for whether they can. And put one number on your dashboard that you currently do not have: how long it takes your team to restore a core system with the AI switched off. That is the line that was invisible. Once it is visible, it stops silently falling.
One warning on how you run all of this. The first few drills will expose people, and if you treat that exposure as a performance failure, everyone will quietly learn to avoid drills, and you will have taught your team to hide the exact gap you were trying to measure. The humiliation in the room is not a sign that someone is bad at their job. It is the recovery gap showing itself for the first time, which is the entire point of the exercise. Run the drills blameless, on copies, with the explicit framing that a rough result today is cheap information that spares you an expensive surprise later. The goal is not to prove anyone can recover on demand. The goal is to keep the muscle warm and to know, honestly, how warm it actually is, so that the number on the dashboard means something and the day it counts is not the first time anyone has walked the path.
Questions founders ask about the recovery problem
What is the recovery problem in one sentence
The recovery problem is that AI handles the routine, happy-path work so well that you and your team lose the practice required to restore systems when they break, and that practice, recovery, is the one capability you cannot delegate to the same tool that is confidently reasoning from the broken assumption.
How is this different from general AI skill atrophy
General skill atrophy is about you getting duller across the board. The recovery problem is narrower and lives at the level of the whole operation, not your personal competence. It targets one specific capability, bringing a broken system back, and it is measured on the rare day something fails rather than in your day-to-day work, which is exactly why it stays invisible until it is expensive.
Why would more reliable AI make recovery worse instead of better
Because you only get good at recovery by recovering, and reliability makes failures rare. Every gain in reliability removes reps from the humans who are supposed to handle the failures that get through. Your average resolution time improves while your worst-case resolution time climbs, so the tool looks better on the metric you watch and leaves you more exposed on the day that is not on any metric.
Does this mean I should use AI less
No. Using AI less on the happy path is a bad trade, because the happy path is where AI genuinely wins. The move is to keep using it for volume while deliberately reserving time to walk the failure path, through monthly drills and a debug-before-ask rule, so that the recovery muscle stays alive even though your normal work now routes around it.
Isn’t redundancy enough to protect me
Redundancy protects you when a component fails and you have a spare. It does not help when the thing that fails is a shared assumption underneath all your components, which is what took three model providers down together on September 3 because they sat on the same cloud region. Redundancy is about having a spare. Recovery is about being able to operate past the spare when the situation has left the map, and that stays human.
How do I know if my team has a recovery gap right now
Run one dark-room drill. Pick a system you rely on, switch off the AI that normally runs it, and try to restore a copy by hand within an hour. The size of the gap you feel is your answer. If nobody on the team can form a theory of what is wrong without prompting the tool, you have comprehension debt, and it is charging interest you will pay during your next real incident.
What should I measure to keep the recovery gap from widening
Put one number on your dashboard: the time it takes your team to restore a core system with AI switched off. Capability gets measured every day and recoverability gets measured almost never, which is why the visible line rises while the invisible one falls. Measuring restore time makes the invisible line visible, and a line you watch is a line you can defend.
Where does this leave junior hires
It is the sharpest reason to keep hiring and training them. Roughly half of engineering leaders plan to hire fewer juniors because AI covers the entry-level work, but the AI-generated debt they are accumulating needs exactly the judgment juniors build by making mistakes on routine problems. Cut off the routine reps and you stop producing the people who can recover, which means the recovery problem gets worse for the whole industry one under-trained cohort at a time.
I keep coming back to that ninety-minute outage. Nothing about it was catastrophic. It was a rehearsal, a cheap one, for a day that will not be cheap. The reliability I had been enjoying was real, and it had been quietly charging me for the recovery muscle the whole time. The bill on September 3 was small. I do not expect the next one to be, so I am spending the difference now, on purpose, while it is still affordable.
I’m a four-time founder building AI-native companies. I write about the founder mindset, AI opportunities, and the mechanics of building with AI at vikasmalpani.com. If this resonated, the reps problem, the fluency trap, and the delegation threshold are the closest companions to this piece, and the AI opportunity map is where I keep the bigger picture.