The quiet engineering that makes AI features reliable

Anyone can wire a language model into a product in an afternoon. The demo will be spectacular. Then the model returns malformed output at 2am, the provider has an outage during your busiest hour, and the monthly bill arrives with a number nobody budgeted for. The distance between an AI demo and an AI feature is not intelligence — it is engineering discipline.

Building the AI infrastructure for Business111.com meant putting language models into more than a dozen production paths: conversational search, transcription, summaries, tagging, narrated video, newsletters. Across all of them, the same handful of patterns kept the product reliable. Here they are.

Grounded, never free-form

Wherever AI writes something a user will read, it is constrained to summarise or transform supplied source text — never to answer from its own knowledge. Search answers are generated only from retrieved documents. Discussion openers are generated from the article they introduce. Resource descriptions are generated from the scraped page itself.

The principle: the model is a writer, not a source of truth. Facts come from your data; the model arranges them. This single constraint eliminates the majority of hallucination risk before any other mitigation is needed.

Fail-soft by design

Every AI call has a non-AI fallback, decided before the feature ships. The question is never whether the model will fail — it is what the user sees when it does:

• Video captions are timed by the speech-to-text model; when it fails, the system falls back to an even time-split of the script across the known audio duration. Captions are never missing.
• Forum discussion openers are AI-written; when the model errors, the system posts the source text unchanged and still creates the topic.
• Automatic tag extraction returns an empty list on failure rather than blocking an article from publishing.
• Social copy generation backfills any missing platform with a neutral template line, so a partial model response never blocks publishing.

In every case the failure mode is degraded quality, not a broken feature. Users may get something plainer; they never get an error page because a third-party AI service hiccuped.

Never trust model output

Model output is input — hostile input, from a component that does not read your schema documentation. Production code validates and repairs everything the model returns:

• Enumerated values are clamped: an invalid mood or voice name silently becomes a safe default.
• Length limits are enforced by code, with word-boundary truncation — not by hoping the prompt was obeyed.
• Out-of-range output triggers regeneration; structurally missing output triggers the fallback.
• Anything destined for another system — hashtags, captions, file names — is filtered against an allowlist in code.

Prompts express intent. Code enforces contracts. Confusing the two is the most common way AI features embarrass their owners.

Cost under control

AI spend is an architecture decision, not a finance surprise:

• Cache aggressively. Identical questions and repeated transformations should never pay for the same model call twice.
• Gate with heuristics. Cheap deterministic checks run first; the model is only called when they cannot decide. Many pipeline steps need no model call at all — semantic matching, for instance, can be pure arithmetic on precomputed embeddings.
• Rate-limit at the edge. Per-user and per-visitor caps keep any single actor from consuming the budget.
• Tier the models. Routine steps run on small, inexpensive models; only the steps where quality is user-visible get the large ones. Model choices live in configuration, so tiering decisions are reversible without a deploy.

Isolate, record, retry

AI steps run isolated from the transactions around them. An embedding failure never rolls back a content save; the error is recorded on the row, everything else proceeds, and a periodic backfill sweep retries whatever failed. Long-running AI work — transcription, rendering — runs in queued workers with explicit status fields, so operators can see exactly which item failed at which step and requeue it.

The habit that ties this together: every AI integration is written with the assumption that it will fail regularly, be wrong occasionally, and be replaced eventually. Systems written that way survive contact with production.

The pattern behind the patterns

None of this is exciting. All of it is the difference between a product that uses AI and a product that is occasionally broken by AI. If you are adding AI to a system your business depends on, these disciplines are the actual work — the model call is the easy part.

DevNest builds AI features with exactly this discipline — grounded, fail-soft, cost-controlled. See devnest.ro/ai for what we build, or the Business111 case study under Our Work for the system these lessons come from.