Reliability in the AI Era: Why We Need Reliability Guardrails

We recently sat down with Kolton Andrus, co-founder and CEO of Gremlin, to talk about what’s actually happening beneath the surface of the AI coding boom. We covered why AI is quietly increasing the number of defects reaching production even as it accelerates how fast teams ship, what “AI guardrails” mean in practice, and why trust has become the real bottleneck in reliability engineering. This conversation matters because every company racing to adopt AI is making a bet on speed. Almost none of them have stopped to ask who’s checking whether the systems built at that speed can actually withstand contact with the real world.

Watch&Listen to the full episode here.

Why Guardrails, Why Now

Kolton Andrus has spent nearly two decades on the side of the industry nobody notices until it fails – first as an engineer carrying the pager at Amazon and Netflix, then as the founder of a company built to break things on purpose, before customers do it for you. He talks about guardrails – the idea that AI is now moving fast enough, and with enough access to production systems, that the industry needs a structural safety net, not just good intentions. That’s the thread running through everything below.

Five Questions, Five Answers Worth Watching In Full

1. AI is writing more code than ever. Is it also writing better code?

No, not really. If we’re shipping ten times as much code because of AI, we’re also shipping roughly ten times as many quality defects and bugs along with it. Throughput has gone up, but quality hasn’t followed. If anything, it’s stayed flat or slipped a little. There’s an assumption that these models must also be getting better at writing secure, performant, production-grade code, the same way they’ve gotten better at writing code that looks plausible on the surface. I don’t think that’s true yet. Honestly, we’re not doing much better than we were before, and in some cases, we’re doing slightly worse.

That gap between how fast we can ship and how well what we ship actually holds up is the whole reason guardrails matter right now. Speed without a real investment in verification isn’t speed at all. It’s just the same problems, moving downstream, arriving later and costing more to fix.

2. What do “AI guardrails” actually mean in practice, not as a buzzword, but as something you build?

I was at an event recently with a group of CIOs, and that phrase, AI guardrails, came up over and over. Everyone in the room was circling the same question. If we’re going to give AI broad access to our systems, what’s actually standing underneath it to catch a mistake? My favorite way to explain it is a racetrack. You don’t put up guardrails because cars crash constantly. You put them up because at high speed, the one time something does go wrong, it can go very, very wrong. The guardrail is what turns a small mistake into a minor inconvenience instead of a headline.

For engineering teams, that idea splits into two very practical problems. The first is that most AI systems writing code today have never actually run a reliable system in production. They’re pattern-matching on what code tends to look like, not on what happens when that code meets a host reboot at 3 am, a memory spike, or a dependency that just disappears. That’s fixable. You deploy the code, throw the real failure modes at it, and feed what you learn back into the model, so it gets better at writing resilient code the next time, not just plausible code.

The second problem is speed of detection. It’s one thing to catch an issue. It’s another to catch it before a customer feels it. That’s the part I’m genuinely excited about right now. The goal isn’t a dashboard someone checks after the fact. It’s closer to calculus. Real-time signal, caught as it happens, or better yet, caught right before it happens, so the fix lands before anyone downstream notices anything was ever wrong.

3. Customers used to be nervous about letting outside systems touch production. Has that changed with AI?

Genuinely, yes, and it caught me off guard. A few years ago, if I told a customer we wanted to run automated tests against their production system, the answer was almost always a hard no. Nobody wanted an outsider anywhere near the systems that paged them at 2am. Today, that same conversation goes completely differently. People say, if AI can do it, great, just go get it done. That’s a full flip in default attitude, and honestly, building that trust turned out to be harder than building the technology itself.

You can actually watch it show up in how our product has changed over time. We started simple: give engineers tools to run their own experiments and see what breaks. Then we added monitoring and alerting, because running an experiment is useless if you can’t tell whether it actually passed or failed. From there, something interesting happened. Customers stopped wanting to dig through the results themselves. They just wanted the answer. And now, they don’t want the answer either. They want the fix, already applied.

We’re not fully there yet, and honestly, I don’t think we should rush it. Most engineering teams still want to see the recommended fix and talk it through before anything touches a live environment, and that’s a healthy instinct. That’s the entire point of a guardrail.

4. With AWS, Azure, and Google all now offering some version of chaos and reliability testing, why does a dedicated guardrail layer like Gremlin still matter?

Competition is a good thing – if you’re completely alone in a category, that’s a bad sign about the market. I’m genuinely glad this space we’ve worked on for a decade is becoming mainstream enough that the hyperscalers are building their own versions.

But it’s a bit like the choice between CloudWatch and something like Datadog. The built-in tools are good enough for some use cases. They’re not best-in-class, and they’re not built by a team whose only job is reliability; they’re playing catch-up on a category someone else defined. Most enterprises also aren’t running entirely inside one cloud. If you’re multi-cloud, on-prem, or you need something that works in a fully air-gapped government environment, a single provider’s bundled tool doesn’t reach far enough. That’s exactly the gap a dedicated guardrail layer has to fill, something that works the same way no matter which environment the AI-generated code eventually lands in.

5. Does this mean SREs eventually become unnecessary – fully self-healing systems, no humans required?

Not any time soon, and I don’t think that’s a bad thing. You still want a human in the loop, because there are judgment calls that shouldn’t be automated away. For the small, well-understood failures, AI and automation can absolutely take action. But for the big decisions like shifting all your traffic between data centers, making a major infrastructure change, I think people will still want someone accountable, making that call.

Take our banking customers as an example. A thirty-second outage can cost more than most engineers earn in a year, sometimes a decade. Against that, the cost of keeping a human available and ready is tiny. The real issue with today’s AI systems is that they’re non-deterministic – you can run the same analysis twice and get two different answers. That’s the whole tension of this moment: how do we build enough trust and consistency to lean further into automation, without removing the human checkpoint that catches the one time it gets it wrong?

(There’s more in the full conversation, including his very candid account of stepping down as CEO in 2022 and later returning, and a story about a Tesla road trip that changed his mind about how much he’s willing to trust autonomous systems. Worth watching in full.)

The Numbers Behind The Conversation

The cost of unreliable systems is well documented, and it continues to climb:

– Across the Global 2000, unplanned outages now cost a combined $600 billion a year, up from $400 billion just two years earlier, according to the Splunk/Cisco Hidden Costs of Downtime 2026 report, which puts the average cost of downtime at roughly $15,000 per minute.

– Splunk’s 2026 research specifically flags AI workloads and “shadow AI”, models deployed without proper performance profiling, as a growing and distinct cause of infrastructure instability.

– According to ITIC’s Hourly Cost of Downtime Survey, per-hour downtime costs in regulated, high-stakes sectors like banking and healthcare regularly exceed $5 million.

Put together, these numbers make the case Kolton was making in plain business terms: reliability guardrails aren’t a defensive afterthought for engineering teams to get to eventually. They’re a balance-sheet risk that’s growing faster than most companies’ current ability to manage it.

A Final Thought

There’s a nice irony in building a career around breaking things on purpose to make them stronger – deliberately triggering the failures nobody wants to see, so customers never have to feel them. Thank you, Kolton, for that essential work and for being so open about both the technology and the harder, more personal decisions behind building it!

This piece is drawn from a video interview conducted for The Prime View. Kolton Andrus is Founder and CEO of Gremlin.