AI features that survive contact with production
A demo that works once is not a feature. What separates AI that ships from AI that stalls is measurement, not model choice.
Most stalled AI projects did not fail because the model was not good enough. They failed because nobody could tell whether a change made things better or worse.
The demo trap
A prompt that produces an impressive answer in a meeting is evidence of almost nothing. You have one sample, chosen by the person who wants it to work. Production traffic is adversarial by comparison: users phrase things strangely, paste in half a spreadsheet, and ask questions your retrieval corpus simply cannot answer.
The gap between a demo and a feature is not model quality. It is knowing your failure modes before your users find them.
Build the evaluation first
Before shipping any AI feature, assemble a test set of real inputs and expected behaviours. It does not need to be large — a hundred well-chosen cases beat ten thousand generic ones. Include:
- Typical requests that must work flawlessly
- Edge cases you know are hard
- Adversarial inputs, including prompt-injection attempts
- Questions that should be refused or escalated to a human
Run this suite on every prompt change, model upgrade, and retrieval tweak. Without it, you are making changes on vibes and hoping.
Ground answers in your own data
General models know general things. Your users ask specific things about your business. Retrieval closes that gap — but retrieval quality, not generation quality, is usually the bottleneck.
If the right document never enters the context window, no model will rescue the answer. Spend your effort on chunking strategy, hybrid search, and reranking before you spend it comparing model providers.
Design for being wrong
Assume the model will sometimes be confident and incorrect. That assumption should shape the interface:
- Show citations, so users can verify without trusting blindly
- Require human approval for consequential actions
- Log full traces, so any answer can be audited afterwards
- Provide an obvious path to a human
A feature that admits uncertainty earns more trust than one that never does.
Watch cost and latency like features
Token spend and response time are product characteristics, not infrastructure trivia. Track cost per request and p95 latency per endpoint from day one. Both tend to drift upward quietly as prompts grow, and both are far easier to control early than to claw back later.
The short version
Measure first, ground your answers in your own data, design for failure, and watch your unit economics. Model selection matters far less than any of these — and it is the one thing most teams spend all their time debating.
