When AI Becomes Production Infrastructure, You Need Recovery Capacity

This article is based on the author's experience operating AI-assisted development workflows. The author identified the failure mode and defined the Recovery Reserve concept. AI helped recompose the article for DEV readers and prepare the Japanese review back-translation. #ABotWroteThis

Quick answer

If AI materially expands how much work your team can keep in motion, recovery becomes AI-dependent too. "We will do it manually" is not a fallback when the workload was sized for AI-assisted throughput. Keep enough inference capacity to execute the critical recovery path (Recovery Reserve), define a fallback provider and a migration context, reduce demand in a degraded mode, and decide emergency purchasing authority and cost attribution before the incident.

Generative AI has changed how much work I can keep moving at once.

I use it to write code, investigate existing systems, organize requirements, compare architecture options, generate tests, review implementations, write documentation, and trace dependencies across a project.

That is useful. It also creates an operational problem that is easy to miss:

AI can increase production capacity faster than it increases your ability to recover without AI.

Once a project has been planned around AI-assisted throughput, losing that capacity is not just an inconvenience. The workload remains, while the system that made the workload manageable disappears.

That is the point where AI stops behaving like a productivity feature and starts behaving like production infrastructure.

"We'll just continue manually" is not always a fallback

I noticed this during a development project where AI was already part of the normal workflow.

Research, architecture, implementation, debugging, and review were all being accelerated with AI. Then sufficient AI capacity was no longer available.

The obvious fallback sounded reasonable:

If AI is unavailable, continue manually.

But the remaining workload had already been shaped around AI-assisted throughput. Switching execution back to unaided human work reduced processing capacity without reducing demand.

That is not graceful degradation.

It is a capacity failure.

A real fallback must change both sides of the equation: the available production capacity and the amount of work the system is expected to carry.

AI is becoming production capacity, not just a tool

If one editor stops working, I can use another. If one terminal application breaks, I can switch tools.

Those tools improve ergonomics and productivity. They do not necessarily determine the amount of work I can keep in motion.

AI increasingly does.

It can compress investigation, create implementation scaffolding, review broad changes, and turn vague requirements into an initial design and test strategy. Once those capabilities become part of normal delivery, removing them changes the capacity of the production system itself.

That changes the question from:

Did we use too much AI?

into:

Did we provision enough inference capacity to deliver the committed workload and recover it when something goes wrong?

We already ask similar questions about compute, storage, CI runners, databases, failover, and backups. AI-dependent engineering work needs the same operational framing.

Personal spending can hide a capacity failure

Suppose company-provided AI capacity is exhausted while business-critical work remains.

A practical reaction might be:

I'll pay for another AI service myself and finish the work.

That can solve an immediate incident. It is a bad default operating model.

If an employee quietly supplies missing production capacity, the organization sees a successful delivery rather than an under-provisioned workflow. The next project can then be estimated with the same insufficient assumptions.

This resembles hidden overtime, except the hidden input is inference capacity rather than labor time.

If AI is part of production, its shortage and its cost need to be visible.

AI can expand the blast radius of a bad assumption

AI accelerates correct decisions. It also accelerates incorrect ones.

A bad assumption introduced early can quickly influence architecture, implementation, tests, documentation, follow-up issues, and later features. Human execution speed used to impose a natural limit on how quickly an assumption could spread. AI weakens that limit.

By the time the mistake is found, the task may no longer be a local patch. It can become a reconstruction exercise: identify everything derived from the assumption, restore the correct boundary, regenerate affected work, and verify the result.

That recovery workload can itself require substantial AI assistance.

The loop looks like this:

Use AI
  ↓
Increase throughput
  ↓
Increase work in motion
  ↓
A bad assumption or incident occurs
  ↓
Recovery workload grows
  ↓
Recovery also needs AI

Now add the worst timing:

AI capacity is unavailable when recovery begins

That is the operational failure mode this article is about.

Recovery Reserve: protect the recovery path, not a percentage

I call the protected inference capacity for this situation Recovery Reserve.

It is capacity kept available for work such as:

• incident investigation
• debugging
• re-analysis
• regeneration
• code review
• rollback
• emergency documentation
• migration to another model or workflow

The important point is not to prescribe a universal reserve percentage. A fixed percentage would imply precision I do not have.

Instead, start with a recovery scenario.

Ask what must happen if the primary model is unavailable, if a bad assumption has propagated widely, or if the current work must be handed to a different model. Identify the investigation, decisions, edits, and verification steps on that critical path.

Then protect enough capacity to execute that path.

The reserve is adequate when the recovery path remains executable, not when a dashboard shows a particular percentage unused.

A fallback provider is an operational dependency

Important AI-dependent work should not have only one viable inference path.

A more resilient setup has a primary model, a fallback model or API route, and a documented degraded mode. But the degraded mode matters as much as the fallback model.

"Humans will do everything if AI goes down" is not necessarily degradation. If the workload was created around AI-assisted throughput, handing the same workload to the remaining human capacity does not create resilience.

A degraded mode reduces demand.

For example, keep incident response and acceptance-critical work moving while pausing new features, optional automation, and documentation that can safely wait.

Graceful degradation means matching the workload to the remaining capacity.

Inference cost becomes part of project cost

AI subscriptions are often discussed like ordinary SaaS expenses.

Once AI capacity affects delivery throughput, incident recovery, and required human effort, its economic role changes. Inference consumption and protected recovery capacity become production inputs.

A useful project cost view can include:

Human labor
Cloud infrastructure
External services
AI inference
Recovery headroom

Even when a contract does not expose precise per-task cost, you can still record operational events: capacity exhaustion, fallback-provider use, manual fallback, and recovery-mode execution.

That evidence is more useful for the next capacity plan than an apparently successful project whose missing AI capacity was silently paid for by an individual.

A first-pass business continuity table

Once AI behaves like production infrastructure, the team needs decisions that are operational, not just conceptual.

You do not need a perfect business continuity program before starting. Fill out this table first.

Failure surface	Decide now	Passing condition
Primary AI is unavailable	Fallback model or API route	Critical recovery work can start through another approved path
Inference capacity is constrained	What Recovery Reserve is protected for	Investigation, correction, and verification can run without consuming normal-production capacity first
Work must move to another model	Migration context	Goal, canonical source, current diff, acceptance criteria, verified evidence, and unresolved items can be reconstructed without copying secret values
Capacity is reduced	Work stop order	Incident and acceptance-critical work stays; deferrable work is explicitly paused
Emergency capacity must be purchased	Decision authority and recording rule	The authorized person and project-cost destination are known before the incident
AI cost must be attributed	Usage events to record	Normal production and recovery activity can be distinguished later at project level
A bad assumption could fan out	Checkpoint before high-propagation work	Assumption, acceptance criteria, and verification method are rechecked before broad generation or automation

Migration context deserves special attention. It does not mean saving an entire chat transcript.

The useful handoff is the smallest package that lets another model reconstruct the task safely: what outcome is required, which artifact is canonical, what changed, what defines completion, what has been verified, and what remains unresolved. Secret values stay in the secret store; the handoff contains references to where authorized tools should retrieve them.

After the table is filled out, rehearse an important recovery task without the primary AI path. Wherever the exercise stops is the next missing piece of Recovery Reserve, documentation, authority, or context.

AI operations begins where AI productivity needs resilience

For a long time, most AI adoption work focused on acceleration: better prompts, better models, agents, automation, and parallel execution.

Those still matter.

But once AI is deeply integrated into real delivery, another layer becomes necessary:

• control
• rollback
• capacity limits
• provider failure
• model substitution
• blast-radius reduction
• recovery

The important question is no longer only:

How much faster can AI make us?

It is also:

How do we safely stop and recover work that has been accelerated by AI?

AI adoption starts with productivity.

AI operations starts when that productivity itself has to become resilient.

FAQ

How large should the Recovery Reserve be?

There is no universal percentage. Start from a concrete recovery scenario, such as the primary model being unavailable or a bad assumption having propagated, list the investigation, decisions, edits and verification on that path, and protect enough capacity to run it. The reserve is adequate when that path stays executable.

Is switching everything to human work a valid degraded mode?

Only if demand is reduced at the same time. Handing an AI-sized workload to the remaining human capacity cuts processing capacity without cutting the work. A degraded mode keeps incident response and acceptance-critical work moving and explicitly pauses deferrable work.

What belongs in a migration context for another model?

The smallest package that lets a different model reconstruct the task safely: the required outcome, the canonical artifact, what changed, the acceptance criteria, what has been verified and what is unresolved. Secret values stay in the secret store; the handoff carries references, not a chat transcript.