Everyone in your organization has an opinion right now.
The CISO thinks AI will make security pipelines smarter. The CTO just greenlit an AI platform team. The VP of Engineering forwarded three articles this week alone. Your performance rating depends on your adoption and use of AI in everything you do. Sometimes it feels you're expected to make coffee using the latest AI agent. And DevOps engineers? They're quietly wondering if their job will look the same in a year.
Here's our take. We won't soften it.
Welcome to on: DevOps, the newsletter from DevOpspolis for engineers, managers, and leaders who build, ship, and operate software at scale.
We're here because the DevOps conversation deserves better than vendor noise and conference theater. Every issue you'll get a short, opinionated take on something that actually matters. And views which are practical, experienced, and honest.
What you can expect from us:
- Real insight from people who've operated production systems, not just written about them
- Strong opinions, held loosely. We'll argue our position, show our reasoning, and listen
- Actionable thinking, and practical solutions, not textbook theory. We've been there
- No agenda except to be useful to you
We're not here to tell you what you want to hear. We're here to tell you what we think is true.
Now. Back to the question.
Will AI Kill DevOps?
Let's start with what's undeniably true.
Six months ago, AI-assisted tooling was haphazard. Engineers were experimenting with Copilot for boilerplate, using ChatGPT to explain error logs, coding with Cursor or Claude Code, maybe generating a Terraform module or two. Impressive, but contained. Results were sporadic. For every time it impressed you with a well written pipeline update, it also left trails of chaos to clean up like a pile of dirty dishes overflowing the kitchen sink. I sometimes found myself angrily responding to it for forgetting or ignoring what we just discussed 5 minutes ago using ALL CAPS, hoping it would listen this time. I can't count the number of times I've heard the proclamation from senior DevOps engineers that AI would never replace us because we can write better code. And everytime I hear it I remember 'computer' was once a person's job title.
That world is already gone. AI is better, we are better at using it.
Today, agentic AI systems are writing and executing CI/CD pipeline, triaging incidents with context pulled from runbooks and Slack history, and making autonomous decisions about rollback thresholds. AI has become our pair programming partner, and we're learning how to use it. Eight months ago I turned Claude Code loose on creating a program. I wanted to see what it could do. It created a mess. Certainly nothing I would release to production, but it helped me understand what I could and couldn't trust it to do. I found it particularly effective at writing Pull Request comments which I hate doing. I starting planning more instead of jumping directly into coding. For years coding was an exploration for me, like a composer on a piano. It was easier to try something and toss it away than spending days whiteboarding it to "perfection". Fail fast is the mantra, and I did. That worked well eight months ago, but not today. Fortunately we're finding better ways to work with AI. I now start by giving it as much context as I can - product vision, customer needs, constraints, technical stack, cost, and scope. I give it my thoughts on a high level architecture and ask it to research both that pattern as well as alternatives. I tell it to document everything; Product vision, strategy, architecture, and implementation plan. Only when I think it has a strong understanding do I let it move to writing code. Even then it's a tightly controlled phased approach. I stop it often and ask questions - "Why did you do that?", "Wouldn't this be a better approach?", "What would the code do which this sample data?" I've found that coaching it, instead of telling it whenever possible and having it work through it's response improves results.
AI is already changing DevOps. Significantly. Some repetitive, and pattern-matching work will shift to AI as well as tasks such as documentation. For decades developers have hated writing documentation, using dismissive responses such as "the code is self documenting". AI is even better at documenting than the built in solutions embedded in different programming languages, and it's able to document for a non-technical audience. As a DevOps Engineer I spent many years having the same conversations with people when moving companies from manual to automated processes. Gently showing them that they won't lose control or value, but will have better control and improve the accuracy and reliability of what they deliver. Ensuring everything I built made their jobs easier and more productive. It's now time to have that conversion with ourselves. Our work has changed, but the need for our expertise hasn't. We need to think like solution architects, customer advocates, and domain experts while broadening our scope across the overlapping disciplines of DevOps, SRE, Platform Engineering, Security, and Solutions Architecture.
But here's where the hype gets dangerous.
The hardest problems in DevOps have never been about automation. They've been about something far more difficult: making complex systems behave reliably and repeatably in production, under constantly changing conditions you can't control, and nobody fully anticipated.
Think about your last major incident. Was the root cause that someone didn't write a script fast enough? Or was it an unexpected interaction between three services, a config change made under pressure, and an alert threshold that hadn't been reviewed since the system was half its current size? Werner Vogels famous quote "Everything fails, all the time" is what any senior automation engineer designs for. "When this fails, how can I recover?", "Where's the escape hatch in this workflow?", "What's the blast radius?", "What's the cost impact?"
While it will become increasingly easier to vibe code a product pipeline, the expertise to do so securely, repeatably, and reliably, still depends on human experience and expertise. The repetitive, pattern-matching, and documentation parts will move to AI. That's the natural order of automation, which DevOps engineers of all people should understand better than anyone.
AI is extraordinarily good at pattern recognition in well-defined problem spaces. Production systems are the opposite of that. They are accumulated decisions, undocumented assumptions, organizational history, and technical debt; layered on top of each other, running live, with real consequences for failure.
The repeatability problem is unsolved.
Ask any team running AI-assisted operations seriously today and they'll tell you the same thing: the outputs are impressive until they aren't, and "until they aren't" is what wakes you at 3am.
AI isn't deterministic. LLMs hallucinate. Wednesday's answer is different than Tuesdays. Agentic systems confidently make wrong decisions, of course apologizing when you point it out . The failure modes are novel, hard to predict, and difficult to instrument for. Reliability engineering is built on the premise that you can define, measure, and improve system behaviour over time. AI-driven automation introduces a new class of failure: decisions that are non-repeatable, made by systems that cannot fully explain their own reasoning, in pipelines that are harder to audit, and impacts which are harder to bound.
That's not an argument against using AI in DevOps. Use it. Teach it, and learn from it. It is an argument against outsourcing your thinking to it.
AI won't kill DevOps, but it will remake it.
It will kill the parts that were never really DevOps; the mechanical parts which were necessary to make it function in a pre-AI world.
The engineers and teams who understand the difference will be in higher demand than ever. The ones who don't will be automated past.
The honest question isn't whether AI will change your role. It's whether you're building the kind of expertise that survives the change.
Now Agile and Scrum? That's a different matter.
What do you think? How is AI reshaping your team's work — for better or worse?
We'd genuinely like to know. Send your thoughts, challenges, and topic requests to on-devops@devopspolis.com — we read everything.
If this resonated, subscribe to on: DevOps and share it with a colleague.
DevOpspolis — Practical. Experienced. Opinionated.