Shipping LLM features without shipping nonsense
Evals, guardrails and the boring plumbing that decides whether an AI feature survives contact with users.
Most production LLM features fail for unglamorous reasons. The model is often capable enough; the product around it is not. Nobody agreed what a useful answer looked like, failure states were designed after launch, and the first real cost forecast arrived with the cloud bill.
Start with the evaluation, not the prompt. Write down the job the feature must do, then build a small set of representative inputs: routine requests, ambiguous ones, hostile ones and the awkward edge cases your users will discover in an afternoon. For each, describe an acceptable result and an unacceptable one. That dataset becomes the product specification as well as the regression test.
Score the qualities that matter separately. Factual accuracy, tone, format compliance and completeness are different failure modes, so a single pass-or-fail score hides too much. Some checks can be deterministic; others need a carefully defined human rubric or a model-based judge that has itself been tested against human decisions.
Treat retrieval and tool use as ordinary software boundaries. Validate inputs, constrain outputs and record which sources or tools contributed to the answer. If the model can trigger an external action, put explicit permissions and a human confirmation step between suggestion and execution. A fluent sentence is not evidence that the underlying action is safe.
Design for slow, wrong and unavailable responses before designing the ideal one. Stream useful progress, provide a visible stop control and make retry behaviour predictable. When confidence is low, say so plainly or fall back to a deterministic workflow. A useful limitation earns more trust than a confident invention.
Cost belongs in the feature design. Log input and output tokens, cache stable context, cap unnecessarily long responses and measure cost per completed user task rather than cost per API call. The cheapest prompt is irrelevant if users need three attempts to get a usable result.
Release gradually. Run the evaluation suite on every meaningful prompt, model or retrieval change, then compare production feedback with the cases you designed in advance. The goal is not a feature that never fails. It is a feature whose quality, failure modes and operating cost are visible enough for the team to improve deliberately.