Most software is designed on the assumption that it will do what it is told. Buttons do not improvise. A form either saves or it does not. The failure modes are predictable, and the interface can prepare for them with an error message and a retry button.

AI breaks that assumption. An AI assistant sometimes gives the right answer confidently, and sometimes gives the wrong answer with exactly the same confidence. The failure is not a bug to be fixed before shipping. It is a permanent property of the product.

Which means error is not an engineering problem. It is a design surface.

The assumption AI breaks

Traditional software is deterministic. Given the same input, it produces the same output. If it fails, the failure is a bug, and the interface just needs to handle the bug gracefully until it is fixed.

AI is probabilistic. Given the same input, it produces a plausible output that may be right or wrong. The wrongness is not a defect to be patched out. It is inherent to how the system works. A model that never got anything wrong would be a model that never said anything useful.

This means the design question changes. For a form, the question is how to prevent errors. For an AI feature, the question is how to live with errors, because they are not going away.

Error is a feature, not a bug

Teams often approach AI errors as a quality problem. Improve the model, reduce the error rate, ship. But no realistic error rate reaches zero, and even a small error rate, applied confidently at scale, produces a constant stream of confident mistakes.

The right framing is that error is a feature of the product, something to be designed for rather than eliminated. This changes what the interface is for. It is no longer just a way to present output. It is a way to help the user judge whether to trust the output.

Confidence without calibration is noise

The most dangerous AI output is the confident wrong answer. The model states a falsehood with the same tone it uses for a certainty, and the user, who has learned to trust software, accepts it.

The interface can help by making confidence visible and honest. Show the sources an answer was drawn from, so the user can check. Show what the model is less sure about. Avoid presenting a single authoritative answer when the model is actually guessing.

The goal is calibration: the interface's expression of confidence should match the model's actual reliability. That is hard to do well, but even a rough attempt is better than the default, which is a confidently wrong statement with no signal at all.

Designing for uncertainty

Designing for an interface that gets things wrong means a few concrete patterns.

  • Show the work. Cite sources, show reasoning, link to the underlying data. Give the user a way to verify instead of asking them to take it on faith.
  • Flag low confidence. A "this may be incomplete" or "low confidence" marker on uncertain outputs is worth more than it costs.
  • Offer alternatives. Presenting several candidates with a "pick the best" framing signals that the model is not certain, and it gives the user agency.
  • Keep a human exit. Every AI flow needs a path back to a real person or a manual fallback, because some failures cannot be self-served.

None of these are technical. They are interface decisions, and they are where the actual trust in an AI product is built or lost.

Recovery as a first-class flow

Because errors are constant, recovery cannot be an afterthought. The user needs to be able to correct, regenerate, refine, and undo without friction.

A good AI interface treats the output as a draft, not a result. "Try again," "make it shorter," "this part is wrong" are first-class verbs, not error handling. The user steers, the model iterates, and the wrong turns are cheap to reverse.

This is the practical difference between an AI feature that feels magical and one that feels broken. Both make mistakes. Only one makes the mistakes easy to fix.

Trust is the product

For an AI product, trust is not a nice-to-have. It is the product. A user who has been burned once by a confident wrong answer will not trust the next one, and an AI product without trust has no value, because its entire output is a claim.

Trust is not built by eliminating error, since that is impossible. It is built by being honest about error: showing uncertainty, showing sources, making failure cheap to recover from. A product that admits when it is unsure is trusted more than one that never does, because the admission is a signal the product knows its own limits.

This is a specific instance of a larger point about AI products, and where to put the human in the loop, which is the subject of copilots and autopilots.

The takeaway

Designing for AI is designing for a product that gets things wrong on purpose, in the sense that wrongness is unavoidable. The interface's job shifts from presenting output to helping the user judge output. Calibrate confidence, show the work, make recovery cheap, and treat trust as the actual product. The teams that do this will build AI features people keep using. The teams that treat error as a bug to be fixed will ship a feature that looks impressive in a demo and stops being used the first time it confidently lies.