DOP 360: What Is an AI SRE?

Episode 360

Show Notes

#360: Assume your production systems go sideways at 3:00am. Your phone doesn’t ring. You wake up to a clean incident report - the system caught the problem, fixed itself, and left a Slack note saying it handled things at 3:15. Would you trust it? Viktor wouldn’t, not at first. Same as a new hire, a new tool, a new anything. Trust gets earned. A few months in, if it hasn’t messed up, then maybe.

So what’s actually new? We had self-healing in decades past, and Kubernetes brings a crashed pod back without anyone awake to watch. Birol Yildiz, co-founder and CEO of ilert, puts the line where it belongs: the old stuff runs on predefined patterns - known problem, known fix, automate it. The new part is diagnosing a root cause nobody wrote a rule for and then knowing what to do about it. And no, ilert isn’t training models on your data. The agent runs on foundational models from the frontier labs, feeds them the same context any SRE would pull - telemetry, recent changes, the health of your infra - runs the investigation loop, and hands you a root cause with the evidence attached.

Then the real argument starts, and it’s about knowledge. Viktor keeps circling the blind spot he sees at every company: the wiki, the runbooks, the tribal stuff nobody keeps current. Birol’s answer is blunter than you’d expect from a guy selling this - dump your Confluence and your hundred stale runbooks into the agent and you cause more damage than results. Code is the documentation that’s actually true. ilert’s agent doesn’t even read runbooks. It builds a live service topology straight from tracing data and rebuilds it when things drift.

What happens when a bad incident month turns your $100 bill into $10,000 - Birol’s answer is a credit budget with a human paged when you blow past it. Who’s accountable when the agent makes it worse? Has to be a human. Agents are tools. You don’t get to blame your AI coding agent for shipping garbage code, and ilert doesn’t get to blame the model either. Trust is binary - five good runs and one bad one, and you strip its write access. But even in observe-only, the value is real, because the time sink in an incident was never the fix, it was finding the needle. Cut root cause from 45 minutes to a few. And the closer nobody wants to hear: if you skipped observability and fifteen years of homework, an AI SRE isn’t going to save you. You can’t skip the parts you skipped.

Frequently Asked Questions

What is an AI SRE and what does it actually do?

Birol Yildiz of iLert describes it on DevOps Paradox episode 360 as an agent that runs the investigation an on-call engineer would run. It reads telemetry, recent changes, infrastructure health, CI/CD pipelines, and source code, then produces a root cause analysis with recommended actions. Instead of being paged to a blank alert, the engineer opens a completed investigation. Being able to verify its own fix is the part he says matters most.

How is an AI SRE different from AIOps or self-healing?

Viktor Farcic draws the line on DevOps Paradox episode 360: self-healing runs on predefined patterns, so a crashed pod gets restarted because somebody anticipated that case. Birol Yildiz adds that AIOps trained models on your own data and largely did not deliver what it promised. His approach trains nothing at all, using frontier foundation models inside a harness that supplies context and runs an investigation loop.

Should you feed your runbooks and wiki to an AI SRE?

Birol Yildiz argues against it on DevOps Paradox episode 360, noting his product has no runbook integration at all. Pointing an agent at hundreds of stale runbooks and a Confluence wiki, in his view, causes more damage than it produces results. The most current documentation is the code and the telemetry. Viktor Farcic agrees the company knowledge is garbage, while suspecting you cannot reach the final destination without some of it.

How autonomous should an incident response agent be?

Birol Yildiz lays out four levels on DevOps Paradox episode 360: observe only, human in the loop, pre-approved classes of action where confidence is high, and full autonomy. He says no iLert customer runs fully autonomously in production, and his own team has reached level three only in staging. Trust is binary in his experience, so a single bad mistake strips an agent’s write access entirely.

Who is accountable when an AI SRE makes an incident worse?

Birol Yildiz’s answer on DevOps Paradox episode 360 is that it has to be a person, because an agent cannot carry accountability. He draws the parallel to coding agents: if the code is bad, blaming the model does not transfer the responsibility anywhere. To help people judge the output, iLert attaches a confidence level to each hypothesis and links every key finding back to the deployment or log line behind it.

Does your company need to be mature before adopting an AI SRE?

Birol Yildiz is direct about this on DevOps Paradox episode 360: if you have skipped the homework for fifteen or twenty years, there are things worth fixing before adopting AI in production. Some prospects have no observability at all and hope an agent lets them skip that step. Viktor Farcic’s version is that the success of any AI adoption tracks closely with where a company already sits technologically.

What is the DevOps Paradox podcast?

DevOps Paradox is a weekly podcast co-hosted by Darin Pope and Viktor Farcic, covering DevOps, platform engineering, and modern software delivery. Episode 360 features Birol Yildiz of iLert on what an AI SRE actually does during an incident, how far teams should let one act on its own, and who carries the blame when it gets the diagnosis wrong. Every episode page carries audio, video, and a full transcript.

Share and Download

Guests

Birol Yildiz

Birol Yildiz

Birol Yildiz is the Co-founder and CEO of ilert, where he leads the company with a unique blend of technical and product expertise. Previously, he served as the Chief Product Owner for Big Data products at REWE Digital. With a solid background in computer science, Birol bridges the gap between developers and product strategists, continually striving to innovate and deliver\ customer-centric solutions at ilert.

Hosts

Viktor Farcic

Viktor Farcic

Viktor Farcic is a member of the Google Developer Experts and Docker Captains groups, and published author.

His big passions are DevOps, Containers, Kubernetes, Microservices, Continuous Integration, Delivery and Deployment (CI/CD) and Test-Driven Development (TDD).

He often speaks at community gatherings and conferences.

He has published DevOps Paradox and Test-Driven Java Development.

His random thoughts and tutorials can be found in his blog The DevOps Toolkit.