For the past two years, almost every conversation about AI has revolved around the same topic: output quality. How do we reduce hallucinations? How do we improve prompts? How do we optimize RAG? How do we increase benchmark scores?
Those questions made sense when most teams were experimenting with LLMs. The challenge was proving the technology could produce useful answers.
But once an AI product reaches production, something interesting happens.
The biggest problem is no longer what the model says. It’s whether your users get an answer at all.
According to Datadog’s 2026 State of AI Engineering report, roughly 5% of LLM requests fail in production. And most of those failures have nothing to do with the model: around 60% come from rate limits and capacity constraints (HTTP 429).
Think about that for a second.
If your SaaS processes one million LLM requests every day, a 5% failure rate means 50,000 requests never complete. Most of them killed by a 429, not a bad prompt. Your customers don’t know whether the failure came from a rate limit, a timeout, a provider outage or an overloaded endpoint. They only know one thing:
Your product didn’t work.
That’s a very different engineering problem from prompt optimization.
Traditional AI discussions still focus on making models smarter. Production teams are increasingly focused on making systems reliable.
Because in production, reliability compounds. A slightly worse answer is often acceptable. No answer at all usually isn’t.
The irony is that many teams keep pouring effort into better prompts while their biggest source of user frustration lives somewhere else entirely: in the infrastructure that sits between their application and the model. Retries, rate limits, provider availability, latency spikes, timeouts, streaming interruptions. Those problems rarely make headlines, yet they cause a surprising amount of production pain.
We’ve lived through this before.
Twenty years ago, web engineering evolved from “building websites” to operating distributed systems. Developers discovered that databases fail, caches become inconsistent, networks partition, and third-party APIs become unavailable. Entire disciplines emerged to solve those operational problems: observability, SRE, incident management, and chaos engineering. Reliability became a product feature.
AI engineering is now entering the same transition. The difference is that instead of managing databases and microservices, we’re managing external models that evolve continuously and that we don’t control.
That’s why the conversation around AI needs to evolve.
The next competitive advantage won’t come from finding a better prompt. Every team has access to similar frontier models, prompting techniques spread quickly, and benchmarks become obsolete within months.
Reliability, on the other hand, is much harder to copy.
The companies that build resilient AI systems will create better customer experiences than those chasing marginal gains in model quality. Because users don’t remember that your prompt was clever. They remember whether your product worked.
I suspect that over the next few years, we’ll stop talking about “AI Engineering” as a single discipline. We’ll separate building AI systems from operating them. Prompt engineering helped us build prototypes. Reliability engineering will decide which AI products survive production.
That’s the layer we’ve been building at Manifest: fallback across providers when one fails, and self-healing on the bad requests before they ever reach your user.
Not a smarter model. A system that doesn’t break.