Ship it so it fails safely

Assume the model will be confidently wrong in front of your most important user. Now design for that. This is not pessimism, it is the same reasoning that puts a fuse in a circuit.

A fuse does not make the wiring better. It decides in advance what happens when the wiring is worse than you thought, and it makes that outcome boring. Features get switched off after launch less often because the model was bad than because nobody decided what the bad case looked like. So it designed itself.

Three failure modes, three different mitigations

Wrong but plausible is the dangerous one, because nothing looks broken. The mitigation is to show your work: quote the source passage, cite the record, display the number the answer came from. A user who can see the evidence catches an error you never will. This is also why a feature that cites its sources gets trusted faster than one that is merely more accurate.

Where the evidence sits decides whether that is real. A citation behind a hover or a collapsed panel is decoration — it is there for you, not the reader. Put the fact the answer depends on in the same sentence as the answer, at the same size. If the output is “this invoice is 34 days overdue,” the due date belongs beside it.

Refused or empty is the easy one, and most teams handle it badly by showing a spinner forever or a raw error. Write the copy for this state before you launch. Say what happened and what to do instead: “I could not find anything in your records about that. Try naming the specific visit, or search directly.”

Two things make that sentence work. It does not apologize, because an apology is not information. And it ends with a route the user can take without you — a different query, a plain search, a named person. An empty state with no exit is where sessions end.

Slow is the one that quietly kills adoption. A model that takes twelve seconds is worse than no feature for anything interactive. Either stream the output so something appears in under a second, or move the work off the request entirely and tell the user when it is done. A spinner for eight seconds teaches people the feature is a tax, and they route around it permanently.

Write the three sentences before you write the feature

Take an example: a box in a support tool that answers questions about a customer’s order history. Before it exists, write the three sentences.

Wrong: “Answered from orders placed in the last 18 months. Check the order number before acting on this.” Empty: “Nothing in this customer’s orders matches that. Search the order list directly.” Slow: “Still reading this customer’s orders. Longer than usual — keep working and come back.”

Now read what those sentences forced you to decide. That the tool sees 18 months, a scope decision you had not made. That there is an order list to send people to, a dependency on somebody else’s screen. That the work can continue in the background, an architecture choice with a deadline attached. Half an hour of copy writing produced three requirements that would otherwise have arrived in week six as surprises.

That is the opening. The rest of the lesson — the remaining sections, the exercise and the check-your-understanding questions — is behind the gate below.