The Night the AI Knew Before I Did

Part 1 of a series: Where DevOps Ends and AI Begins

It was 2:17 AM on a Thursday.

I know the exact time because my phone’s screen — the only light in the room — had a Slack notification glowing on it. A Zenduty P0. #incidents-prod. Payment service. Zero out of three pods running.

I’d been a DevOps engineer for six years at that point. I knew the drill. Stumble to the laptop. Open three terminals, two dashboards, one very strong cup of instant coffee. Start hunting.

ImagePullBackOff usually means one of a few things — a bad tag, a registry permission issue, a typo in the image name. Standard stuff. I was already mentally SSHing into the cluster, running kubectl describe, preparing to dig.

And then I scrolled down in the Slack thread.

Below the Zenduty alert, our AI agent had already replied. No one had asked it to. It had seen the same alert, pulled signals from the cluster, the ECR registry, the deployment history, and the node events — and posted its full analysis in 38 seconds.

A spot node had been evicted by AWS at 2:11. The pods rescheduled onto fresh nodes — no cached image. Kubernetes reached for ecr/payment-service:v1.8.3 in ECR. Gone. Deleted three days ago by an automated lifecycle policy that purges images not pulled in 30 days. The service had been running fine on nodes that already had the image cached. The moment those nodes disappeared, so did everything holding it together.

The agent had the causal chain, the ECR evidence, the exact kubectl command to patch it, and a note about preventing it with digest-pinned image refs — all sitting there before I'd even made it to my desk.

I sat there for a moment. Not because I was impressed. Because I realized the investigation I was about to spend the next hour doing — the log-diving, the registry spelunking, the cross-referencing of node events and deployment history — had already been done.

In the time it took me to read the alert and reach for my laptop, the answer was already there.

That moment changed how I think about my job

I’ve spent the better part of half a decade automating things. Writing Bash scripts to replace repetitive tasks. Building CI/CD pipelines to eliminate manual deployments. Crafting Terraform configs to make infrastructure reproducible.

I thought I understood automation.

What I didn’t understand — what that 2 AM incident forced me to confront — is that there are two kinds of automation.

The first kind is scripted automation: you define every step, every condition, every branch. The pipeline does exactly what you told it to do. No more, no less. It’s reliable, predictable, and completely blind to anything you didn’t anticipate.

The second kind — the kind AI brings — is adaptive automation: it observes, reasons, finds patterns across data you couldn’t have manually indexed, and makes decisions in contexts you never explicitly programmed for.

DevOps built its entire foundation on the first kind. AI is now quietly, persistently, inserting itself as the second.

And the intersection of those two things? That’s where I want to take you in this series.

What this series is really about

Over the next few articles, I want to explore four questions that I think every DevOps engineer — junior, senior, burnt-out, or just starting out — needs to sit with:

1. Will AI replace DevOps engineers? Short answer: no. Long answer: it will replace the parts of your job you hate, and demand new skills for the parts it can’t touch. We’ll dig into what those are.

2. What AI tools are actually worth using today? Not the hype. Not the pitch decks. The tools I and others are actually running in production pipelines — for code review, incident triage, infrastructure management, and observability.

3. What is AIOps, really? The term gets thrown around like a buzzword, but there’s something genuinely transformative underneath it: the idea that your operational environment can predict, detect, and sometimes heal itself. We’ll break down what that actually looks like in practice.

4. What happens when AI meets DevSecOps? Security has always been the awkward third wheel in the Dev-Ops relationship. AI is changing that dynamic in ways that are both exciting and a little terrifying.

But first — let’s talk about what DevOps actually is in 2026

Because I think there’s a gap between how DevOps is taught and how it’s lived.

Taught: a cultural philosophy. Break down silos. Developers and operations working together. Automate everything. Continuous integration, continuous delivery, everyone’s happy.

Lived: you’re the person who gets paged at 2 AM. You’re the one who knows where all the bodies are buried in the infrastructure. You’re the one whose Slack handle gets mentioned whenever something explodes in production, regardless of whether you wrote a single line of the code that caused it.

DevOps is equal parts engineer, archaeologist, firefighter, and therapist.

And AI? AI is becoming the partner that doesn’t need sleep. The partner that has read every runbook, every post-mortem, every log file — and can surface the relevant parts faster than any human ever could.

That’s not a threat. That’s leverage.

The engineers who will thrive in the next few years are the ones who learn to use that leverage. Who stop thinking of AI as something that competes with their expertise, and start thinking of it as a force multiplier for it.

What I want you to take away from this first post

I’m not here to tell you AI is magic. It isn’t. It makes mistakes. It hallucinates configurations. It confidently suggests things that will break your environment in new and creative ways if you don’t know enough to review its output critically.

But I’m also not here to dismiss it. The engineers who are dismissing it right now are in for a roller coaster of a surprise.

The truth is somewhere more interesting: AI and DevOps are not competing philosophies. They are a compounding stack.

DevOps gave us speed and reliability through cultural change and automation. AI is now giving us intelligence and adaptability on top of that foundation.

Together, they are building something we don’t have a clean name for yet. Some people call it AIOps. Some call it Platform Engineering 2.0. Some call it the end of on-call rotations as we know them (I remain cautiously optimistic on this one).

Whatever you call it — it starts with one honest question:

What would your job look like if you stopped doing the parts that a machine could do better, and spent all that recovered time on the parts only you can do?

I’ll see you in Part 2.

If this resonated, follow along — I’ll be publishing the next part within the week. And if you’ve had your own “2 AM AI moment,” I’d love to hear about it in the comments.

Tags: DevOps Artificial Intelligence AIOps Platform Engineering Software Engineering Career Tech