Progressive Enhancement: AI Features That Work When AI Doesn’t
6 min read · updated August 3, 2026
Progressive enhancement is an old idea from the web: build something that works, then improve it for clients that can do more. Applied to model-backed features it is deeply unfashionable, because it means writing the boring version first — and it is right for reasons that have very little to do with availability.
The argument
A feature built model-first has its availability, its latency and its cost defined entirely by the model. When the model is unavailable the feature is gone; when the model is slow the feature is slow; when usage grows the cost grows linearly with it. There is no floor, because nothing was built underneath.
A feature built deterministic-first has a floor. Search still returns results, ranked by relevance and filters; the summary panel shows the first paragraph; the categoriser falls back to the rules that covered the common cases anyway. Then the model improves each of those: reranks the results, writes a real summary, catches the cases the rules miss. The user experience degrades from excellent to adequate rather than from excellent to absent.
The objection is that this is twice the work, and sometimes it is. But notice how often the deterministic version already exists — you had keyword search before, you had rules before — and the model-first rewrite quietly deleted it. That is not building less; it is throwing away a working floor to save the effort of keeping it.
A test for a feature you already shipped
For each model-backed feature, answer four questions honestly:
- If the model were unavailable for six hours, what does the user see? If the answer is an error or an empty state, there is no floor.
- Can the user reach the same outcome manually? Not the same experience — the same outcome. If the AI is the only path to a result the user needs, you have made a model a hard dependency of your product.
- What fraction of requests does the model actually improve? If most inputs are handled correctly by an obvious rule, you are paying per call for a rule.
- Would a user notice if the model were quietly disabled? An uncomfortable question with a genuinely informative answer either way.
Features that fail all four are not necessarily wrong — some products are the model — but they should fail them knowingly, with the availability of the dependency written into whatever target you have committed to.
What the floor looks like in practice
| Feature | Description |
|---|---|
| search | Floor: full-text search with filters and sensible ordering. Enhancement: semantic retrieval and a reranker. The floor is what runs when the embedding service is down, and it is also what runs for the exact-match queries where lexical search is simply better. |
| summarisation | Floor: the first paragraph, the document's own abstract, or extracted headings. Enhancement: a written summary. Keep the source one click away in both cases. |
| classification / routing | Floor: rules over structured fields, plus an explicit 'unsorted' bucket. Enhancement: a model for the residue. Most real corpora have a long tail and a very fat head. |
| autofill / suggestions | Floor: an empty, editable field. This is the easiest one, because the floor is doing nothing — the requirement is only that the field is usable while the suggestion is pending or absent. |
| chat over your data | Floor: the underlying documents, browsable and searchable. If the only way to reach an answer is to ask, the model's availability is your product's availability. |
A pattern runs through that table: the floor is usually the thing the model is summarising, ranking or paraphrasing. Keeping the underlying artefact reachable is most of the work, and it is also what lets a user verify an answer they doubt.
Three benefits that are not availability
Cost, at the shape of the distribution
If a deterministic rule handles the head of the distribution confidently, the model only sees the tail, and your cost per request falls in proportion. This is a real architectural saving rather than a discount, and it improves as the corpus grows and the head gets fatter. The design that supports it is a confidence threshold on the cheap path with an explicit escalation, not a coin flip.
You get a baseline to evaluate against
Without a deterministic version there is nothing to compare the model against, so “is this working” becomes a matter of opinion. With one, you can ask the only question that matters — how often does the model beat the floor, and on which inputs — and you can answer it by running both. Plenty of features turn out to be improved by a model in ten per cent of cases and made slower and less predictable in the other ninety, and there is no way to discover that without a baseline.
Trust, and the ability to disagree
A user who can see the sources, edit the suggestion or switch back to the plain view is a user who can recover from a wrong answer. A user with only the generated output has to either accept it or abandon the task. The manual path is not a fallback for outages; it is the thing that makes the automated path safe to trust, because trust requires the ability to check.
Build order, and when to ignore all this
The order that follows: build the deterministic path, ship it, measure where it is inadequate, then add the model to that specific inadequacy. This gives you a working feature early, a precise statement of what the model is for, and an evaluation set made of the real failures rather than of imagined ones.
The order most teams use is the reverse, and it is not irrational — the model version is more impressive, it demos better, and it is often faster to build because the prompt replaces a week of rules. If you go that way, at least write down what the floor would have been. A feature whose floor exists on paper can have it implemented in an afternoon when it is needed; a feature nobody ever thought about the floor for cannot.
And ignore all of this where the model genuinely is the product. A translation tool, a code assistant, an image generator — there is no meaningful deterministic floor under those, and pretending otherwise produces a worse product. The honest response there is not progressive enhancement but explicit dependency management: multiple providers, a real availability target, and a status page that tells the truth when the thing your product is made of stops answering.