PTN—41
Graceful degradation
When the AI can’t perform — offline, rate-limited, low confidence, out of scope — fall back to something still useful.
AI features fail more ways than traditional software: the model is overloaded, the context is too long, the question is out of distribution, the confidence is garbage. Graceful degradation is deciding, at design time, what each failure hands back to the user. The floor should never be a spinner that gives up or a cheerful non-answer; it should be a smaller, honest capability — search instead of synthesis, a template instead of a draft, the raw documents instead of the summary.
The design move is a capability ladder. Full capability at the top; below it, degraded modes that still move the task forward; at the bottom, the manual path, which must always exist and always be visible. Products that bet everything on the model — no search fallback, no manual editor, no cached results — convert every model hiccup into a total outage of the user’s task, not just of your feature.
Degradation must be legible, not cosmetic. If the fast model silently substitutes for the good one under load, users get inexplicably worse answers and blame themselves — or stop trusting the good days too. A one-line banner (“High demand — responses may be slower / using a faster model”) costs a moment of polish and buys back the whole relationship. Failing quietly is the expensive option.
When to use
- The feature depends on remote inference that can slow, fail, or be rate-limited.
- Confidence or retrieval quality varies enough that some answers shouldn’t ship as answers.
- Requests will regularly fall outside the model’s competence and need a dignified “no.”
- The AI layer sits on top of a workflow people could still complete by hand.
Design considerations
- 01Design the capability ladder explicitly: full → degraded → manual, with a named behavior at each rung.
- 02Keep the manual path permanently reachable — never gate the underlying tool behind the AI front door.
- 03Announce degraded modes in one plain sentence; never swap models or truncate context silently.
- 04Return partial value on failure: sources found, a draft outline, the search results the synthesis would have used.
- 05On low confidence, downgrade the claim, not just the wording — offer retrieval instead of generation.
- 06Preserve user input through every failure; a timeout that eats the prompt turns one failure into two.
- 07Rehearse rate-limit and outage states in design reviews with the same rigor as the happy path.
Pitfalls
- ✕The confident fallback: the system can’t do the task, so it does something adjacent and presents it as the answer. Worse than an honest error, because the user ships the wrong thing.
- ✕Silent model swaps under load — quality drops with no explanation, and users learn the product is randomly unreliable.
- ✕Error states written for engineers (“context length exceeded”) with no recovery action a normal person can take.
- ✕AI-first redesigns that delete the manual path, so a model outage is now a product outage.
In the wild
- Perplexity
- Grounded in search: even when synthesis is weak, the cited sources remain useful — the degraded mode is a good search engine, not an empty state.
- Claude
- Declines out-of-scope or beyond-cutoff questions by stating the limit and suggesting how to get the answer, rather than improvising one.
- GitHub Copilot
- Fails soft by design — when no completion arrives, the editor is just an editor. The manual path is the default surface, so degradation is nearly invisible.
- Google Search (AI Overviews)
- Simply omits the AI overview on queries where it isn’t confident, degrading to classic results instead of forcing a synthesis.