Mr.PlanB Logo

    Newsletter

    Subscribe our newsletter

    Get new infrastructure guides, comparison reports, and migration notes in your inbox.

    Infrastructure notes, guides, and new tools. Unsubscribe anytime.

    Back to Blog
    AI
    DevOps
    Automation
    Kubernetes
    Infrastructure

    AI Didn't Kill DevOps, but It Made the Stakes Way Higher

    December 17, 2025
    9 min read

    There's a running joke among engineers right now that "two people with AI can create the tech debt of fifty." It's funny because it's true, or at least uncomfortably close to it.

    AI hasn't replaced DevOps. If anything, it's dragged DevOps further into the spotlight. The decisions that used to sit unnoticed in YAML files, Terraform modules, and shell scripts are now happening faster, more often, and sometimes without the person typing fully understanding what they just shipped. Velocity is up, while confidence is… complicated.

    Whether AI works in DevOps is mostly settled, because it clearly does. The open question is what happens when speed collides with infrastructure, security, and production systems that don't forgive mistakes.

    Faster doesn't mean safer

    Most engineers agree on one thing: AI is great when you already know what you're doing. If you understand Kubernetes networking, IAM policies, or deployment pipelines, an LLM can feel like a power tool. It fills in boilerplate, reminds you of flags you forgot, and saves you from writing the same Helm chart scaffolding for the fifteenth time.

    When that understanding isn't there, though, AI speeds you up in the wrong direction.

    Infrastructure code isn't like frontend code, where a bad decision throws a console error and ruins a button hover. Infra fails loudly, or worse, silently: a backup script that always logs success, a scaling policy that looks right but drains capacity at the wrong time, an IAM role that's just a little too permissive.

    These problems are real, and they're the kinds of bugs that sit unnoticed until someone else is on call at 3 a.m., staring at logs and wondering who thought this was a good idea.

    "Vibe coding" hits different in production

    There's a reason the phrase "vibe coding" makes experienced engineers twitch. Writing application code with a fuzzy understanding of the internals is one thing. Doing that with infrastructure is another.

    AI is very good at producing things that look correct, like clean YAML, plausible Terraform and confident explanations. That confidence is part of the danger. Hallucinated fields don't look hallucinated, and invented flags don't raise red flags until something breaks.

    Once AI-generated changes start landing in production systems, the blast radius gets real. Rollbacks aren't always clean, and state doesn't always revert. Cost optimization "suggestions" can turn into deleted resources, and auto-remediation can become auto-destruction.

    The irony is that the more abstracted modern platforms become, the easier it is to trust the output without questioning it. When everything already feels a bit magical, AI just becomes another layer of "trust me."

    Security teams are right to be nervous

    If there's one group that hasn't been swept up in the hype, it's security and compliance teams, and their caution is realistic.

    AI tools don't understand the full context of your organization. They don't know which risks are acceptable and which aren't. They don't know your regulatory obligations, your threat model, or the one legacy system that breaks if you touch it wrong.

    Giving an AI agent execution access to production environments is a governance decision as much as a tooling one. Who approved this change? Who's accountable when it goes wrong? How do you audit actions taken by a probabilistic system that can't explain its reasoning in a way that holds up under scrutiny?

    A lot of teams are learning this the hard way. AI works great… until it doesn't. And when it doesn't, it tends to fail with confidence.

    Where AI actually shines in DevOps

    The story isn't all doom and gloom. In fact, some of the most compelling uses of AI in DevOps don't involve writing code at all.

    Log analysis, alert clustering, incident summarization and change correlation are all places where humans are slow and tired and machines are very good. AI can scan mountains of noise and surface patterns that would take a person hours to piece together.

    Used this way, AI becomes a force multiplier rather than a decision-maker. It helps engineers reason faster without taking the wheel away from them, and it reduces cognitive load instead of increasing risk.

    Documentation is another low-key win. Auto-generating README updates, change summaries, or migration checklists saves time without touching production state. The same goes for small, well-scoped scripts that are reviewed, tested, and understood before they run.

    What these uses share is restraint. AI works best when it's boxed in.

    The experience gap is widening

    One uncomfortable side effect of AI-assisted development is that it amplifies differences in experience. Senior engineers tend to use AI as a shortcut for things they already understand. Junior engineers sometimes use it as a replacement for understanding altogether.

    Nobody should treat that as a moral failing, since it's a natural outcome of tools that promise speed. But it does mean teams need to be more intentional about guardrails, reviews, and expectations.

    When someone can generate five microservices in a weekend, "can they?" is the wrong question. Ask whether they know what they just built, and more importantly, whether they can debug it when the AI isn't there to help. AI lowers the barrier to entry, and it also raises the bar for judgment.

    Kubernetes didn't get simpler

    If anything, AI exposes how complex modern infrastructure already is. Systems like Kubernetes were never designed to be forgiving. They assume a certain level of understanding, reward careful design, and punish guesswork.

    AI doesn't change that. It just accelerates how quickly you can get into trouble if you skip the fundamentals.

    That's why so many experienced engineers land on the same position: AI is fine, even great, as long as a human stays firmly in the loop. Suggestions are welcome, and auto-approval is not.

    AI concentrates responsibility

    The biggest change AI brings to DevOps is responsibility density. One person can now do the work of several. That sounds efficient until you realize it also means one person can create the problems of several.

    Organizations that treat AI as a way to cut corners are setting themselves up for expensive lessons. Organizations that treat it as a way to sharpen engineers tend to get better outcomes.

    The future probably holds just as many DevOps engineers and far fewer excuses. When tools are this powerful, "we didn't have time" stops being a defense.

    So… adopt or wait?

    Most teams won't have the luxury of opting out. AI is already here, baked into editors, terminals, and cloud platforms, so the choice is about how to use it.

    Use it to learn faster, to reduce toil, and to explore ideas and sanity-check assumptions. But don't hand it the keys to production and hope for the best.

    DevOps was always about reliability, feedback loops, and shared ownership, never automation for its own sake. AI doesn't change that philosophy. It just makes the consequences of ignoring it much bigger. AI didn't kill DevOps, but it made DevOps a lot harder to fake.