The reliability problem
Large language models are powerful but unpredictable. They can generate brilliant responses one moment and confidently wrong answers the next. When you are building products on top of LLMs, this unpredictability becomes your biggest challenge.
Over the past year, we have shipped multiple LLM-powered features and learned hard lessons about what it takes to make them reliable.
Lesson 1: Structured outputs are non-negotiable
Free-form text generation is fine for chatbots, but most product features need structured data. We learned early that asking a model to "return JSON" in a prompt is not enough.
// Instead of hoping for valid JSON...
const schema = z.object({
summary: z.string().max(200),
sentiment: z.enum(["positive", "negative", "neutral"]),
confidence: z.number().min(0).max(1),
});
// Validate every response
const result = schema.safeParse(modelOutput);
if (!result.success) {
return fallbackResponse();
}
Always define a schema. Always validate. Always have a fallback.
Lesson 2: Latency budgets matter more than you think
Users have expectations about how fast things should be. A search autocomplete that takes 3 seconds feels broken. A document summary that takes 10 seconds feels slow but acceptable.
We set latency budgets for every LLM-powered feature before writing any code:
| Feature | Budget | Strategy |
|---|---|---|
| Autocomplete | 200ms | Small model, cached prefixes |
| Classification | 500ms | Batched inference |
| Summarization | 5s | Streaming response |
| Document analysis | 30s | Background job + notification |
Lesson 3: Evaluation is continuous
You cannot test an LLM feature once and ship it. Model behavior changes with updates, prompts drift as you iterate, and edge cases surface gradually.
We run automated evaluations on every deployment:
- Regression tests — a fixed set of inputs with expected outputs
- Quality scoring — LLM-as-judge on a sample of real traffic
- Latency monitoring — P50, P95, P99 tracked per feature
- Cost tracking — token usage and spend per feature per day
What we are building next
We are turning these internal tools into products. Our evaluation framework, Neural Eval Studio, will help other teams set up the same kind of continuous quality monitoring we rely on.
More details coming soon.