AI for DevOps, Explained: AIOps, GenAI Tooling and What Actually Changes

A student asked me last month whether he should still bother learning Terraform properly, since ChatGPT writes it anyway.

Fair question. Also the wrong one, though it took me a while to work out how to explain why.

Most writing on this topic doesn't help with that. It's either vendor material, where every feature works and every limitation is a reason to upgrade, or it's panic content written by people who have never carried a pager. Neither tells you what to do on Monday.

So: what AI actually does in DevOps work right now, what the research found when people measured it instead of asking how it felt, and what I'd tell that student to learn. I should say upfront that we run a DevOps course with GenAI in it, which makes me an interested party. The way I've tried to handle that is by including the research that makes our pitch harder, not easier.

Two Different Things Wearing the Same Name

Most confusion about this topic comes from one place. "AI for DevOps" gets used for two technologies that share almost nothing except the letters.

AIOps is machine learning, and lately language models, running over your operational telemetry. Metrics, logs, traces, events, deploy history, service topology. It lives in the monitoring stack. Gartner named the category around 2017, and honestly, for the first five or six years the only thing it reliably did was turn four hundred alerts into six. Somebody senior buys it, usually about a month after a bad on-call quarter.

GenAI tooling is a language model sitting next to one engineer while they write a Terraform module or read a stack trace. It lives in your editor. Nobody procures it. You started using it before anyone in your company wrote a policy, which we'll come back to, because that's a real problem and not a small one.

Different buyers. Different failure modes. Different evidence base. Different skills.

And the failures aren't comparable either. An AIOps tool failing means a page goes to the wrong person at 3 AM. A GenAI tool failing means you merge a security group that's wider than you thought. I've seen both. They do not feel the same the next morning.

	AIOps	GenAI tooling
What it is	ML and LLMs over operational telemetry	A language model assisting one engineer
Where it runs	Monitoring and incident stack	Your editor, terminal, browser
Who adopts it	Platform lead, SRE manager, procurement	You, probably last Tuesday
What it costs	Licences, credits, integration work	A subscription, or nothing
How it fails	Confident wrong correlation mid-incident	Plausible code that's quietly incomplete

Everything below keeps them separate. Where a point covers both, I'll flag it.

GenAI in Daily DevOps Work: What It's Genuinely Good At

Baseline first, because it's an odd one. DORA's 2025 research found roughly nine in ten technology professionals using AI tools, and about four in five saying they felt more productive. In the same study, close to a third said they had little or no confidence in the code those tools produced.

Nine in ten use it. A third don't trust it. Learning to hold both of those at once is most of the skill.

Writing infrastructure code

The demo everyone gives. It works, with a catch that's worth showing rather than describing.

Ask a model for an S3 bucket with versioning enabled, for storing application backups. You get maybe fifteen lines of HCL back. Bucket resource, versioning block, a tags block, all neat. It applies without complaint.

Now look at what isn't there. No server-side encryption configuration. No public access block. So whether that bucket is exposed depends entirely on account-level settings you may or may not have got right eighteen months ago.

Terraform won't complain. There's no error to catch. A reviewer who has been burned by S3 before spots both gaps in about four seconds; someone in their first year sees working code and approves the PR.

That's the shape of the problem with generated infrastructure code. Not wrong. Incomplete, and specifically incomplete in the places where the defaults are unsafe. Which is a terrible combination for a beginner and a mild time-saver for someone experienced.

If you're still learning what a good module looks like, our Terraform explained for beginners guide will do more for you than a chat window will.

Reading things faster than you can

Nobody makes YouTube videos about this one. It's the use case I'd defend hardest.

Pipeline fails. Four hundred lines of Java stack trace and Maven output. You paste it in, ask what broke, and thirty seconds later you have a hypothesis instead of ten minutes of scrolling. Same story with a Helm chart you've never seen, or a nine-hundred-line YAML file inherited from someone who left in 2023, or a Terraform plan that wants to replace a resource and you cannot for the life of you see why.

The reason this is safer than generation: you can check it immediately. The answer is either in the log or it isn't. Nobody merges a hypothesis.

The writing nobody wants to do

Postmortem first drafts. Commit messages. Runbook docs. The stakeholder Slack update during an incident, which is genuinely hard to write while also fixing the thing.

Low risk, real time saved, and it targets the part of the job most engineers quietly avoid. A postmortem draft that exists and needs editing beats the perfect one that never gets written, and I say that as someone who has left postmortems unwritten.

Where it falls over

Three places, consistently.

Your environment. The model doesn't know your staging cluster runs a different ingress controller, that the migration job has to finish before the deploy, or that there's one service nobody restarts between 9 and 6 because of a client contract.

Security. Veracode's research on GenAI-produced code has repeatedly found meaningful rates of insecure patterns across a broad set of tasks and models. Treat generated security config as a draft from a bright intern who has never been paged.

And the subtle category: anything where almost-right is worse than obviously wrong. A model that hands you a working IAM policy with a wildcard in it has done more damage than one that hands you nothing, because the broken version gets fixed and the working one gets merged.

AIOps Explained: What the Tools Actually Do

Definition, so the rest of this makes sense. AIOps is machine learning and, increasingly, language models applied to IT operations data, so that detection, correlation, triage and part of the response happen without a human reading every alert. The data being metrics, logs, traces, events, deploys and topology.

Now the honest version, capability by capability.

Alert correlation and noise reduction

Oldest capability. Still the one that works most reliably. Six services depend on a database, the database falls over, you get one incident instead of six pages.

Practitioner write-ups and vendor case studies report large drops in alert volume. Some of the numbers are very large. Read them as results from specific deployments rather than something you're guaranteed, because the variable that matters isn't the tool.

It's your alerting discipline. Correlation quality is downstream of alert quality, and if your alerts are already noisy and badly labelled, what you buy is well-organised noise. That's not a criticism of the category. It's just where the value actually comes from, and it's the part vendors have no incentive to lead with.

Anomaly detection

Learns what normal looks like for a metric, flags the deviations. Good for the class of failure that never trips a static threshold: slow memory leaks, latency that creeps up over three weeks.

You pay for it in false positives, and that cost is real but hard to put on a spreadsheet. Every false anomaly spends a little of your team's patience. Teams who tune hard in the first two months tend to keep using it. Teams who leave the defaults on are usually ignoring the alerts again by the next quarter, which is exactly where they were before they bought anything.

Root cause analysis

Two schools. Correlational tools look for signals that moved together. Causal tools build a model of what depends on what and reason over that. Vendors in the causal camp make a lot of noise about explainability, and in fairness they're right to: mid-incident, a conclusion you can't verify is worse than no conclusion at all, because now you're debugging the tool as well as the outage.

Either way, topology matters as much as telemetry. A tool that doesn't understand your service graph is pattern-matching on charts.

What the LLM era added

This is the visible change since about 2024. Current tools don't just group alerts. They read the storm, check it against recent deploys, write a paragraph proposing a probable cause, suggest a runbook step, and open a Slack thread with whoever is on call.

At 3 AM that's genuinely valuable, because your own reasoning at 3 AM is not what it is at 3 PM. It is also confident in a way it hasn't always earned, which is the same problem as generated code, relocated to a room where the stakes are higher and everyone is tired.

Agentic AIOps and AI SRE agents

Through 2025 and into 2026, most of the big observability vendors shipped something called an SRE agent. Microsoft's Azure SRE Agent reached general availability. Datadog shipped Bits AI SRE, New Relic released its own, Dynatrace added an autonomous SRE agent plus a way to build your own.

Where's the actual line? These agents do parallel triage, investigate across signals, draft postmortems. What they mostly don't do is push high-risk changes to production unsupervised. Rollbacks, restarts, scaling decisions still go through a human at most places. That's a deliberate design choice, not a technical limit, and I'd expect it to hold for a while.

Gartner has forecast that agentic AI will run much of enterprise IT infrastructure by 2029. Gartner has also warned that more than 40% of agentic AI projects will be scrapped before 2027. Same analyst house, both forecasts, and you should probably take them as a pair instead of quoting whichever one supports your slide. If the underlying observability side is shaky for you, start with monitoring, logging and reliability.

What the Research Actually Shows

This is the section I wanted to write the article for.

DORA, which is Google Cloud's long-running research programme on software delivery, published something awkward in its 2024 State of DevOps work. AI adoption was associated with higher individual productivity, better flow, more job satisfaction. It was also associated with a decline in delivery throughput and, more noticeably, in delivery stability.

People felt faster. The system got shakier.

The 2025 follow-up, based on surveys of around five thousand technology professionals plus a lot of interview work, named the mechanism. AI is an amplifier. It magnifies whatever it lands in. A team with real automated testing, working CI and small batches gets meaningfully better. A team without those gets worse more quickly, because AI raises the volume of change flowing into a process that was already struggling. DORA's own phrasing was that AI will not fix broken engineering systems.

Which, if you sell AI training, is not the sentence you'd choose. It's still the most useful finding in the whole field.

Why everyone thinks it's working better than it is

There's a second thread worth knowing before you quote a number in a meeting.

Self-reported gains run consistently ahead of measured ones. Ask engineers how much faster they are and you get impressive figures. Measure the telemetry and you get smaller ones. In at least one randomised study, experienced open-source developers took measurably longer with AI assistance while believing they'd been faster.

That's not people lying. It's what happens when a tool removes friction from the visible parts of work, typing and looking things up, and adds time to the invisible parts, reading and verifying. Twenty minutes checking generated code doesn't register as work the way twenty minutes writing it does. I catch myself doing this most weeks.

The queue nobody budgeted for

Third finding, and it explains why individual speed keeps failing to show up as team speed.

More output doesn't flow straight to production. It piles up at code review and approvals, at every point where a human has to judge something. DX's measurement work and Atlassian's Teamwork Lab research reached this independently during 2026, which is a much stronger signal than either on its own.

Your reviewers become the bottleneck. And reviewing AI-written code is slower per line than reviewing a colleague's, because you can't assume the author understood it.

What happens to the codebase

GitClear has been analysing changed-line data at serious scale, hundreds of millions of lines, tracking maintainability as AI assistance spread. Their findings point at duplication and churn: more repeated code, more code rewritten soon after it was written.

Neither is a crisis in month one. Both are the kind of thing that compounds into a codebase nobody volunteers to work on.

The dip before the gain

DORA's more recent work on AI return describes a J-curve. Things get worse before they get better, because the habits and systems around AI take time to build.

The practical consequence is a bit grim. Plenty of teams quit during the dip and conclude the whole thing was hype. Others push through without fixing their testing and CI, and simply stay in the dip.

One thread runs through all of it. AI isn't a substitute for automated testing, continuous integration and small batches. It raises the value of having them and the cost of not having them. If your CI is a half-abandoned Jenkins job that three people trust and everyone else works around, fix that before you spend anything on models. How CI/CD pipelines work covers the ground.

Will AI Replace DevOps Engineers?

No. But not for the reason people usually give.

The comfortable answer is that AI can't do the creative parts. That's not really it, and anyone who has watched a model design a reasonable multi-region architecture knows it isn't.

The actual reason is accountability. AI increases how much change flows through production, and somebody has to own what happens next. Somebody decides whether a rollback is safe at 2 PM on a Friday. Somebody writes their name on the postmortem. Somebody redesigns the system so the next failure is smaller than this one. None of that transfers to a model, because responsibility doesn't transfer to a model.

The job is changing, though, and pretending otherwise would be dishonest.

Shrinking: hand-writing boilerplate Terraform and manifests. First-pass log reading. Routine docs. Tier-one alert triage. Remembering exact flag syntax for commands you use twice a year.

None of that was the interesting part. It was, however, how a lot of juniors accumulated their first year of pattern recognition, and losing it is a genuine problem for people starting out now. I don't think the industry has an answer yet.

Growing: judgement during incidents. Architecture and cost calls. Security review. Reviewing AI output, which turns out to be a separate skill from writing code. Running the platform all this tooling sits on. Picking the right explanation out of three plausible ones.

For the student I mentioned at the top, the honest version is this. The floor moved. Nobody gets hired now for being able to write a Dockerfile, because a model writes Dockerfiles. You get hired for looking at generated output and saying, precisely, why it's wrong. And that ability comes from understanding the systems underneath, which is an argument for learning fundamentals harder rather than skipping them. What a DevOps engineer actually does has more on where the role sits.

AI DevOps Tools, Organised by the Problem You Have

No ranking here, deliberately. Rankings in this space age within months and usually reflect who funded the article. We have no commercial relationship with any vendor below, and there are no affiliate links on this page.

Find your problem, then look at the row.

Your problem	Category	Representative tools	What to watch for
Drowning in alerts	Correlation, noise reduction	PagerDuty AIOps, BigPanda, built-ins in Datadog and Dynatrace	Output quality tracks your alert hygiene, not the vendor
Investigations take forever	AI-native investigation	Datadog Bits AI, Dynatrace Davis, New Relic, Rootly	Per-investigation pricing spikes on your worst day
Kubernetes keeps breaking	K8s-specific operations	Komodor, Metoro	Narrow by design; great if K8s is the pain, limiting otherwise
Incidents are chaotic	Response workflow	incident.io, Rootly, FireHydrant, PagerDuty	This is a process problem first; AI helps at the margins
Writing code and IaC	Developer assistants	GitHub Copilot, Claude Code, ChatGPT	Your review discipline matters more than the choice
Must stay on open standards	OTel-native observability	Grafana Cloud, Prometheus ecosystem	More assembly, less lock-in

Two things about money. Integration effort eats most AIOps budgets, not licence fees. Wiring five monitoring systems into a correlation engine is a quarter of work, not a signup form. And check the pricing model carefully, because several investigation tools bill per investigation or per credit. Fine on a quiet Tuesday. Expensive during a cascading incident, which is the exact day you want it running flat out.

One question worth putting to any vendor: what does your tool do when telemetry is incomplete? Because yours will be. The answer will tell you more than the demo did.

Where AI Belongs in a Pipeline, and Where It Doesn't

Stage	What AI does today	Guardrail
Plan	Drafts tickets, summarises requirements, finds gaps	A person still owns the decision
Code	Writes and completes code, suggests refactors	Human review; no exceptions for infrastructure code
Build	Explains failures, proposes fixes	Check the actual log, not the summary of it
Test	Generates cases and fixtures	Generated tests can bake in the same wrong assumption as the code
Release	Drafts notes, flags risky changes	Approval stays human
Deploy	Suggests rollout strategy, spots bad deploys	Automated rollback only with a tested, tight blast radius
Operate	Correlates alerts, drafts causes and postmortems	On-call confirms before acting

Notice the shape. AI pays off most at the two ends, writing code and understanding incidents, and least in the middle of the delivery path.

That's not an accident. The middle is where you want determinism. Your deploy should do the same thing every single time, and putting a probabilistic system in that position is a liability dressed as innovation.

One rule I'd hold firm: nothing changes production state unless a human can explain afterwards why it changed. That isn't hostility to automation. Deterministic automation changes production all day and that's fine, because you can read the script. The problem is an action nobody can reconstruct while writing the postmortem. The DevOps lifecycle walks the full path, and GitOps explained covers the deterministic way to change production state.

Governance and Trust: The Part Nobody Puts on a Course Page

Open-source maintainers had to answer the AI-contribution question years before most companies wrote a policy, and their answers are useful precisely because they had to be specific.

A RedMonk review of AI policies across seventy open-source organisations in early 2026 found the whole spectrum. NetBSD and Gentoo banned AI-generated code outright. Apache allows it with disclosure. The Linux kernel drafted guidance around a Co-developed-by tag, which in plain terms means a named human takes responsibility for AI-assisted code.

Different rules, same underlying principle: it's fine when a human understands it, has tested it, and owns it. Dumping model output into a PR is not.

Three habits follow from that.

Before you commit generated code, be able to explain every line. Not roughly. Specifically why that IAM action is in the policy, specifically why that timeout is thirty seconds. If you can't, you've handed off a decision you'll be asked about later, probably in front of people.

Second: "the AI wrote it" means nothing in a postmortem. Your commit, your name in git blame, your incident. Worth internalising now rather than during your first real outage.

Third, watch what goes into the prompt. Production config, customer records, internal architecture, credentials. All of it gets pasted into chat windows constantly by people in a hurry. Find out your company's policy before you need it, and if there isn't one, assume the strict version. DevSecOps basics is related reading.

What to Actually Learn, and in What Order

Here's what I told the student.

First: fundamentals, and harder than before

Linux, networking, Git, containers, Kubernetes, Terraform, CI/CD. Not because AI can't help with them. Because of the amplifier finding.

If you can't read a Kubernetes event stream yourself, you have no way of knowing when an agent's explanation of it is wrong. Every layer of AI you add raises the value of being able to check its work.

Concretely: read a Terraform plan and predict what it'll do before you apply. Follow a request from ingress all the way to the pod. Explain what CrashLoopBackOff actually means instead of just saying the word. Start at Linux skills DevOps actually uses, and the 2026 DevOps roadmap handles sequencing.

Second: using GenAI well

Smaller skill than the internet suggests, and mostly discipline rather than clever prompting.

Give the model the context it can't guess: your cloud, your region, your compliance constraints, how your modules are structured. Ask for what you actually want rather than the minimum version. Read output as a reviewer, not a recipient. And develop a feel for when to stop arguing with a model and go read the docs, which for me is usually two failed attempts in.

Third: observability literacy

Every AIOps tool is downstream of telemetry. What a trace is, why cardinality bites, what you lose when you sample, how to write an alert that fires on something a human should actually do something about. Get that wrong and an AIOps layer just organises your noise more neatly.

Fourth: the new layer

Agents, MCP servers, wiring AI into your own workflows. Least crowded thing in job ads right now, which cuts both ways. It's a differentiator, and it's the part most likely to look completely different in eighteen months. After the first three, not instead of them.

What to skip

ML theory and model training, unless you want to become an ML engineer, which is a different career. Vendor certifications for platforms you don't run. And whatever tool is trending on LinkedIn this week.

If you'd rather do this with a cohort and someone reviewing your work, that's what our DevOps course with GenAI is. If you're self-studying, the order above doesn't change, and the tool priority ranking covers what comes next.

Where This Leaves You

The tools are real. AIOps does cut alert noise and shorten investigations. GenAI does save an engineer real time on code and logs. Neither claim needs inflating.

The research is messier than the marketing, and it's messy in a consistent direction: AI amplifies whatever system it lands in. Good teams get faster. Struggling teams get worse, sooner.

So the conclusion is a bit anticlimactic for an article about AI. Learn the fundamentals properly. Use the tools every day, but read what they give you like a reviewer would. And try to be the person in the room who can tell when the confident paragraph on the screen is wrong.

That person is going to be worth more every year, not less. Which is roughly what I told the student, and he did end up learning Terraform properly.