Zeke Lares
Every engineering org has now built the impressive AI demo. You wire up a model, feed it context, and watch it do something that would have taken a sprint to hand-code. The demo is real and the capability is real. But there's a canyon between a demo that delights a room and a service that a paying customer's workflow silently depends on at 3am. Crossing that canyon — putting AI on the critical path — is the actual job.
The uncomfortable property
Traditional software is, for the most part, deterministic. Given the same input, you get the same output, and when it breaks it tends to break the same way twice. Language models are not like that. The same prompt can produce different answers, confidently wrong ones among them. If you bolt that property directly onto a load-bearing path, you've imported non-determinism into a place that was previously predictable.
You don't make a model reliable. You build a reliable system that contains a model.
That reframing changed everything about how we shipped. We stopped asking "is the model good enough?" and started asking "what's the blast radius when it's wrong, and what catches it?"
Three rules that earned the model its seat
Before an AI component could go anywhere near a production path, it had to satisfy three things.
- Bounded output. The model never speaks freely into the system. It returns structured, schema-validated output, and anything that fails the schema is rejected before it can do harm — the same way you'd treat untrusted user input.
- A deterministic fallback. Every AI path has a non-AI answer it can fall back to. Degraded, maybe — but never a hard failure because a provider was slow or a response didn't parse.
- Reversibility. The AI's action is observable and undoable. If a decision turns out wrong, we can see it happened and unwind it, rather than discovering the damage downstream.
Treat the model like a brilliant, fast, occasionally-hallucinating contractor. You'd never let that person commit straight to main. You'd give them a sandbox, review the output against a spec, and keep a way to revert. Same posture, in code.
Where AI actually paid off
The highest-leverage uses weren't the flashy ones. They were the places where the work was previously either manual or impossible — translating messy third-party IoT payloads into our normalized schema, drafting the first version of an integration, surfacing anomalies in oceans of telemetry that no human was going to read line by line.
We also lean on AI heavily in the development loop itself — agentic coding tools, code review assistance, and the Model Context Protocol to give those tools structured access to our own systems. Used well, it compresses the distance between "we should build that" and "it's in review." Used carelessly, it generates plausible code that nobody fully understands, which is technical debt with extra steps. The discipline is the same as everywhere else: the human stays accountable for what ships.
// the pattern, stripped down let draft = model.infer(prompt, schema: StrictSchema)?; match validate(draft) { Ok(result) => apply_reversibly(result), Err(_) => fallback.deterministic(), // never a hard fail }
Trust is a budget, not a switch
We didn't flip a switch and declare the model trustworthy. We gave it a small, low-stakes responsibility, watched it under real traffic, and widened its mandate only as it earned that mandate — exactly the way you'd onboard a new engineer. Confidence is accrued, not assumed.
The result is a platform where AI does real work on real paths, and where a bad day for a model provider is a non-event for our customers. That's the whole game: not the cleverest possible use of AI, but the most boring possible failure mode when it's wrong.
The line I keep coming back to
AI in production isn't a model problem. It's a systems problem with a model-shaped component. The engineers who'll do this well over the next decade aren't the ones with the best prompts — they're the ones who already know how to build systems that stay calm when a part of them misbehaves.