Why AI Coding Agents Fail and How to Recover Safely
Published: 2026-07-14 · Author: Muhammad Tayyab Ilyas
Quick answer
AI coding agents usually fail because a model becomes unavailable, a session stalls, authentication expires, review loops exhaust their limit, or one task depends on another task that failed. Safe recovery preserves completed work, repairs the root failure, retries only affected stories, and then rechecks their dependents.
The most revealing reliability lesson in an autonomous build often arrives as a small, frustrating UI moment. A story is clearly stuck. The interface says it needs attention. Yet the one action a person expects is missing. That happened to us with story S6, Implement PDF export and document templates, and it exposed a deeper truth about multi agent software development: a retry button is only useful when the system understands what it is retrying.
In this guide
- The story of S6
- Failed, blocked, paused, and stalled
- How safe recovery works
- Five practical use cases
- Recovery checklist
- Frequently asked questions
The story of S6: the button that solved the wrong problem
S6 appeared in the Live Build window with a plain status: needs attention. Its worker was Antigravity, its master reviewer was Grok, and the card offered Edit, Schedule, and Skip. The explanation underneath was accurate: resolve or retry its failed dependency. But there was no direct way to do that from the story itself.
The first fix sounded obvious. Add a Restart build button. The existing lifecycle already knew how to resume a paused run, so the new button called that safe path. Tests passed. The production bundle contained the button. It still did not appear for S6.
The reason was not CSS, caching, or a missing deployment. It was semantics. S6 was not paused. It was blocked. Restarting a paused build and repairing a blocked dependency are different operations, even if a user reasonably describes both as rerunning the build.
The correct design separated those meanings. A paused run gets Resume. A directly failed story gets Retry. A blocked story in a failed build gets Resolve and rerun, which repairs the failed dependency chain before requeuing the blocked work. The interface became clearer because the orchestration model became clearer first.
Failed, blocked, paused, and stalled are not interchangeable
Reliable recovery begins with an explicit state model. Treating every interruption as a generic failure encourages blind retries, duplicated work, and unnecessary model usage.
| State | What it means | Safe action |
|---|
| Failed | The story attempted its work but could not complete it. | Retry it, repair its credentials, or reassign its worker. |
| Blocked | The story cannot start because a required dependency failed. | Repair the dependency chain, then requeue the blocked story. |
| Paused | The user deliberately stopped new work and active builders. | Resume from preserved commits and queued stories. |
| Stalled | The agent is alive but no longer making useful progress. | Inspect activity, steer it, or restart that worker with context. |
This distinction also matches a broader shift in reliability research. A recent study of coding agent trajectories argues that failure should be understood as a process with an onset, evolution, and recovery path, rather than only as a final score. See Failure as a Process: An Anatomy of CLI Coding Agent Trajectories.
How dependency aware recovery works
The goal is not to make failure impossible. The goal is to make failure local, understandable, and recoverable.
- Preserve completed work. Keep merged commits and successful stories instead of returning the project to zero.
- Find the root failure. Inspect the first failed dependency, authentication result, session state, review history, and error text.
- Choose the smallest repair. Refresh credentials, replace an unavailable model, remove a stale session, adjust the story, or retry the failed worker.
- Requeue only affected work. Reset failed stories and reconsider the stories blocked by them.
- Respect resource limits. Let normal worker slots, schedules, and model availability decide when the fresh attempt starts.
- Verify the recovered build. Run the same tests, builds, and review gates required by the original plan.
The pattern is familiar outside agent systems. Multi task job platforms repair unsuccessful tasks and their dependents without rerunning successful tasks, which reduces recovery time and resource use. Microsoft documents this approach in its guide to repairing failed job runs.
Why blind restarts waste tokens and trust
Restarting an entire autonomous build can look decisive, but it often repeats the most expensive parts of the run. Agents reread the repository, recreate plans, regenerate artifacts, and review code that already passed. If a previous step had an external side effect, a blind retry can even repeat that side effect.
Selective recovery avoids that trap. It preserves known good state, carries forward useful diagnostics, and spends new model capacity only where the build still has uncertainty. This is especially important when several providers share limited concurrent sessions or when media generation has a hard budget.
Five practical use cases
1. Document generation and PDF export
A team builds templates, data mapping, document preview, and PDF export in parallel. Export depends on the template contract. If the template story fails, the export story should become blocked rather than generating documents against an unstable format. Resolve and rerun repairs the template layer first, then safely requeues export. This is the exact lesson behind S6.
2. SaaS onboarding workflows
Suppose one worker builds account creation, another builds onboarding tasks, and a third builds account health scoring. If the shared customer schema fails review, health scoring should wait. Retrying only the scoring UI would waste time because its dependency is still invalid. Dependency aware recovery fixes the schema and then releases both downstream stories.
3. Online store checkout
Catalog, cart, pricing, payment, and confirmation can be separate stories. A payment story may depend on a stable cart total and currency contract. If pricing fails, the system should preserve completed catalog work, repair pricing, and rerun checkout without rebuilding the storefront.
4. Mobile authentication and protected screens
A mobile build may split authentication, profile APIs, navigation, and push notifications across agents. Protected screens should remain blocked if token storage fails security review. Once authentication is repaired, the orchestrator can reconsider those screens while leaving unrelated visual work untouched.
5. Media generation and delivery
A social video build can separate research, script, generated assets, composition, captions, and delivery. If a required asset is missing, composition should not repeatedly consume rendering capacity. Repairing the asset story first protects generation limits and avoids producing several unusable exports.
The interface is part of the recovery system
Clear status text is necessary, but status without an appropriate action leaves the user stranded. A trustworthy Live Build view should answer four questions immediately:
- What stopped?
- Why did it stop?
- What will the recovery action change?
- What completed work will remain safe?
That is why Retry, Resolve and rerun, Resume, Edit, Schedule, and Skip should not be interchangeable labels. Each action communicates a different promise about state and side effects.
A practical recovery checklist
- Classify the state. Confirm whether the story is failed, blocked, paused, stalled, or already completed.
- Read the dependency graph. Repair the earliest failed prerequisite before its downstream stories.
- Preserve good work. Keep merged commits, accepted reviews, assets, and known good outputs.
- Change one variable. Retry, reassign, refresh credentials, or edit instructions based on the diagnosed cause.
- Verify after recovery. Do not treat a restarted agent as proof that the problem is solved.
Frequently asked questions
Why do AI coding agents get stuck?
AI coding agents get stuck when a model or credential becomes unavailable, a tool or session stalls, review repeatedly rejects the work, or a required dependency fails. Reliable orchestration records the specific state instead of reducing every problem to a generic error.
What is the difference between a failed and blocked story?
A failed story attempted its own work and could not finish. A blocked story has not been able to proceed because another required story failed. Retrying the blocked story alone does not repair its dependency.
Should I restart the entire multi agent build?
Usually no. Preserve successful work, repair the root failed story, and requeue only affected dependents. Restart the whole build only when shared state is corrupted or the original plan is no longer valid.
How do you rerun a blocked AI agent story?
Find and repair its failed dependency first, reset the affected story states, and let the dependency checks requeue them in the correct order. The recovery should preserve completed commits and still respect concurrency limits.
How does selective recovery reduce AI usage?
Selective recovery avoids repeating planning, implementation, review, media generation, and validation that already succeeded. New model calls are focused on the failed work and the dependents that genuinely need another attempt.
The larger lesson
Autonomous software development becomes trustworthy when the system can explain and contain failure. The visible button matters, but the state model behind it matters more. S6 did not need a prettier error message. It needed the platform to understand that a blocked dependency is a different problem from a paused build.
That small distinction protects completed work, reduces unnecessary model use, and gives a person a clear next action. It is the difference between an agent demo that works on a clean run and an engineering system that can recover when reality becomes messy.
See how LoopCodeLab divides work in the build team guide, learn how to build a web app from one prompt, or start a build and watch the recovery model in action.