DEV Community

Cover image for Why AI and Automation Are Not Always the Right Answer in DevOps
Yogesh VK
Yogesh VK

Posted on • Originally published at Medium

Why AI and Automation Are Not Always the Right Answer in DevOps

In DevOps, AI, and platform engineering, speed without understanding can amplify failure.

Introduction

Every engineering team reaches this moment sooner or later.

A repetitive task appears. A process feels slow and folks just say:

Can we just automate this?

On the surface, it sounds like the right instinct. DevOps, after all, was built on the idea of reducing manual effort and increasing reliability through automation.

But in my experience, automation is not always the right first answer.

Sometimes the process is slow because it contains necessary human judgment. Sometimes the repetition is actually a signal that the underlying system design needs improvement. And increasingly, with AI entering DevOps workflows, there is a temptation to automate decisions that should still remain human.

The question is not whether something can be automated. The more important question is whether it should be.

Automation Often Scales Existing Problems

One of the most common mistakes teams make is automating a broken or poorly understood workflow.

A manual deployment process may feel slow and frustrating. But if the underlying release steps are unclear, automating them simply means the same confusion now happens faster and at larger scale.

In infrastructure systems, this can be dangerous.

A pipeline that automatically pushes Terraform changes into production may look efficient, but if reviewers do not fully understand the blast radius of those changes, automation simply accelerates risk.

The result is not better engineering. It is faster failure.

The Difference Between Repetition and Judgment

Not every repetitive task is suitable for automation.

Some tasks are repetitive because they are operationally necessary. Others require human context and judgment, even if the steps appear similar.

For example, reviewing a Terraform plan may seem repetitive. But what the reviewer is actually doing is not checking syntax. They are making decisions about:

  • operational risk
  • rollback impact
  • customer-facing downtime
  • security implications That is not repetition. I think that is judgment.

Automating the process without preserving that judgment layer often removes the most valuable part of the workflow.

AI Makes This Even More Tempting

The rise of AI in DevOps workflows makes this challenge even more relevant. AI tools can now can do all of these and more:

  • summarize pull requests
  • explain Terraform plans
  • analyze logs
  • suggest infrastructure changes These are genuinely useful capabilities. But there is an important boundary.

AI should help engineers understand systems better. It should not replace ownership of decisions.

For example, using AI to explain a Terraform plan is helpful. Using AI to automatically approve and apply infrastructure changes is often the wrong answer. The operational responsibility still belongs to humans.

Good Automation Removes Toil, Not Thinking

The best automation removes toil, not thought. Good examples include some of these:

  • automatic formatting checks
  • CI validation pipelines
  • policy enforcement
  • environment cleanup schedules
  • cost anomaly alerts These tasks are repetitive, rules-driven, and low in ambiguity. They benefit greatly from automation. What should remain human are workflows involving uncertainty, trade-offs, and accountability.

The Better Question to Ask
Instead of asking:

Can we automate this?

A better question is:

What part of this process is pure toil, and what part requires human judgment?

That distinction changes everything. Once you separate toil from judgment, automation becomes much safer and much more effective.

Closing Thought

In DevOps and platform engineering, automation is incredibly powerful.

But the goal should never be automation for its own sake. The goal is better systems in my opinion.

Sometimes that means automation. Sometimes it means improving engineers and systems understanding first.

And increasingly, with AI in the mix, it means being very deliberate about what we allow machines to decide on our behalf.

Because not every slow process is a bad one. Some of them are where engineering judgment actually lives..

Do you feel the same way?

Originally published on Medium:

Top comments (0)