Guardrails for shipping an LLM feature
A demo that works on your ten favourite examples is not a feature. What turns one into the other is evaluation, boundaries, and a plan for being wrong.
Adding a language model to a product is easy to start and easy to get wrong in ways that only show up in front of customers. The engineering is mostly in what surrounds the call.
Evaluate before you ship
You cannot improve what you cannot measure, and vibes do not survive a prompt change. Build a set of real cases with known-good outputs and score against it automatically.
Without that harness, every change is a guess, and quality drifts downward silently as prompts get edited by different people.
Constrain the output
Free-form text is the hardest thing to integrate and to validate. Where the result feeds anything downstream, require structured output and validate it against a schema before use.
If validation fails, retry once, then fall back to a deterministic path. Never pass unvalidated model output into something that writes to a database.
Decide what happens when it is wrong
Not if. The design question is what the failure looks like:
- Can the user see and correct it before it takes effect?
- Is there a deterministic fallback?
- Does a wrong answer cost money, or just time?
- Is it obviously wrong to the user, or plausibly wrong? Plausible is far more dangerous.
Features where a wrong answer is invisible and consequential are the ones to be most careful about.
Cost and latency are product constraints
Per-token pricing means an expensive prompt on a high-traffic path is a recurring bill, and a multi-second response changes what the interface can be. Both belong in the design conversation, not in a surprise at the end of the first month.
Cache aggressively. Many requests are near-duplicates.
Be straight with users
Say what is automated. Give people a way to correct it and a way to opt out. Trust is lost quickly here, and a feature that quietly guesses is worse for a product than one that clearly assists.