Forem: Yogesh VK

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

Yogesh VK — Fri, 10 Apr 2026 06:00:00 +0000

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:

medium.com

Using AI to Explain Terraform Plans to Humans

Yogesh VK — Fri, 27 Mar 2026 06:16:00 +0000

Turning raw infrastructure diffs into decisions engineers can actually understand.

INTRODUCTION

Terraform plans are incredibly precise. They show every resource change, attribute modification, and dependency update that will occur during an apply.
But precision is not the same as clarity.
For many engineers reviewing infrastructure changes, Terraform plans feel more like a wall of text than a meaningful explanation of what is about to happen. The information is there, but extracting the real implications often requires experience and careful reading.

This is exactly where AI can become useful. Not by executing infrastructure changes, but by translating Terraform plans into something humans can reason about.

THE PROBLEM WITH RAW TERRAFORM PLANS

Terraform's plan output is designed for correctness, not readability.
It faithfully lists changes such as resource replacements, attribute updates, and dependency adjustments. While this is ideal for machines and precise workflows, it can make reviews difficult for humans, especially in larger environments.
A simple plan might include:

hundreds of attribute updates
nested resource changes
implicit dependencies across modules

What reviewers actually want to know is much simpler:

What changed?
Why does it matter?
Is the risk acceptable?

Terraform itself does not answer those questions.

WHERE HUMAN REVIEW BREAKS DOWN

Experienced engineers eventually develop an instinct for reading Terraform plans. They scan for dangerous signals:
resource replacement

subnet or network changes
IAM policy expansions
scaling changes in compute clusters

But this intuition takes time to build, and even experienced reviewers can miss subtle interactions when reviewing large changes late in the day or under delivery pressure.
The real problem isn't lack of information. It's cognitive load.

Terraform tells us everything. Humans only need to understand the important parts.

WHY AI IS GOOD AT THIS PROBLEM

AI models are particularly good at summarizing structured text and identifying patterns.
A Terraform plan contains many signals that AI can interpret effectively:

which resources will be created, updated, or destroyed
whether replacements will occur
potential cost changes
security-sensitive modifications
large blast-radius changes

Instead of forcing humans to parse hundreds of lines of output, AI can produce a concise summary describing the operational impact.
This transforms the Terraform plan from a raw diff into an explanation.

AI AS A REVIEW ASSISTANT IN CI/CD

A practical place to integrate this capability is within CI/CD pipelines.
After generating a Terraform plan, a pipeline step can feed the plan output into an AI model. The model then produces a human-readable summary that is attached to the pull request.
Instead of reviewing raw plan text alone, engineers see a structured explanation such as:

Risk Summary: This change replaces the EKS node group, which will trigger a rolling replacement of worker nodes.
Security Impact: No IAM policies were expanded.
Cost Impact: Estimated monthly increase: approximately $120 due to increased instance size.
Operational Notes: Node replacement may temporarily reduce cluster capacity during rollout.

This type of explanation does not replace the Terraform plan. It simply helps humans understand it faster.

USING GITHUB ACTIONS FOR AI-ASSISTED PLAN REVIEWS

GitHub Actions provides a natural place to implement this pattern.
A typical pipeline already includes steps like formatting, validation, and plan generation. Adding an AI analysis step is straightforward and can operate entirely in read-only mode.
The workflow might look like:

Run terraform plan
Export plan output as JSON
Send plan summary to an AI model
Post a structured explanation as a pull request comment

The key point is that the AI does not change infrastructure or execute Terraform commands. It only interprets the plan and produces a human-readable summary.
This keeps the decision-making process firmly in human hands.

WHY THIS IMPROVES INFRASTRUCTURE SAFETY

When infrastructure reviews fail, it is rarely because Terraform produced incorrect output.
Failures occur because reviewers misinterpret the impact or miss important signals hidden within large plans.
AI-assisted explanations reduce that risk by highlighting the kinds of changes humans care about most:

replacements
deletions
network changes
permission expansions
scaling adjustments

The AI becomes a second set of eyes, helping reviewers focus their attention where it matters.

THE IMPORTANT BOUNDARY

Even though AI can interpret plans effectively, it should never be allowed to execute them.
Running terraform apply still requires human ownership and operational judgment. AI can explain consequences, but it cannot decide whether those consequences are acceptable.
That boundary is what keeps AI useful rather than dangerous.

CLOSING THOUGHT

Terraform already tells us what will change.
AI helps answer the more useful question: What does this change actually mean?

By turning raw infrastructure diffs into clear explanations, AI allows DevOps teams to review changes faster, understand risk better, and make more confident decisions.
And that is exactly where AI belongs in infrastructure workflows - helping humans think more clearly, not replacing their judgment.

How does your team review Terraform plans today - raw output, custom tooling, or something smarter?

Originally published on Medium:

medium.com

5 Expensive Terraform Mistakes I Keep Seeing in Real Infrastructure and How AI can Help

Yogesh VK — Fri, 20 Mar 2026 06:15:00 +0000

Small infrastructure decisions that quietly turn into large cloud bills
Infrastructure-as-Code has dramatically improved how teams manage cloud environments. Terraform in particular has made it possible to define infrastructure in version-controlled, repeatable configurations.

In theory, this should make infrastructure both predictable and efficient.

In practice, however, Terraform does not automatically make systems cost-efficient. It simply makes infrastructure changes easier to reproduce. If inefficient patterns exist in the configuration, Terraform will reproduce them perfectly.

Over time, small infrastructure decisions accumulate. Many of them appear harmless when introduced, but months later they become visible as unexpectedly large cloud bills.

Here are some of the most common Terraform patterns I keep seeing that quietly drive up infrastructure costs.

1. Oversized Compute That Never Gets Revisited

One of the most common patterns starts early in a project.

During initial development, engineers often choose slightly larger instance types to avoid performance issues. It is safer to start with extra capacity rather than risk under-provisioning a critical service.

The problem is that these instance sizes often remain unchanged long after workloads stabilize.

Terraform makes it easy to define infrastructure once and leave it untouched. As long as systems continue running without obvious performance problems, there is little incentive to revisit instance sizing decisions.

Over time, this leads to clusters and services running on instance types that are significantly larger than necessary.

This issue is particularly visible in Kubernetes clusters, where node groups are frequently defined with conservative sizing assumptions. If workloads later become more efficient, the underlying infrastructure may remain over-provisioned indefinitely.

Resource Replacements Triggered by Small Configuration Changes Terraform’s declarative model means that certain configuration changes require resources to be replaced rather than updated.

For example, modifying attributes such as subnet associations, encryption settings, or instance types may cause Terraform to destroy and recreate a resource.

While Terraform clearly reports these replacements in the plan output, the operational and financial impact is not always obvious during review.

Replacing compute clusters, databases, or node groups can temporarily increase infrastructure usage, create additional storage snapshots, or trigger redeployment processes that consume additional resources.

When these replacements happen frequently across environments, they can contribute to unexpectedly high infrastructure costs.

This is one reason many teams are beginning to use AI-assisted plan analysis in CI pipelines — to highlight resource replacements and explain their operational impact before they are applied.

Logging and Observability Configurations That Grow Without Limits Terraform is often used to provision logging pipelines and observability systems. These systems are essential for debugging and monitoring production environments.

However, logging configurations are frequently defined with very generous defaults.

For example, teams may configure:

high verbosity log levels
long retention periods
large ingestion pipelines These settings are useful during development but are rarely revisited as systems mature.

Because Terraform configurations remain stable over time, these logging pipelines can continue collecting massive volumes of data long after the original debugging needs have passed.

In some environments, observability costs eventually exceed the cost of the infrastructure being monitored.

Idle Infrastructure Environments Another common Terraform pattern involves environment duplication.

Many organizations create separate environments for development, staging, integration testing, and experimentation. Terraform makes it easy to spin up these environments using identical modules.

The problem is that these environments often remain running continuously even when they are rarely used.

A staging environment that runs databases, compute nodes, load balancers, and storage resources can easily cost hundreds of dollars per month. Multiply that across multiple teams and environments, and the cost grows quickly.

In many cases, these environments are only actively used during working hours.
Automated scheduling policies or environment lifecycle management can dramatically reduce this waste, but these controls are rarely implemented initially.

Storage That Quietly Accumulates Storage resources are particularly prone to long-term cost growth.

Terraform configurations frequently create:

snapshots
backups
object storage buckets
artifact repositories Because storage is relatively inexpensive per gigabyte, these resources often grow without much scrutiny.

Over time, however, storage layers accumulate historical artifacts that are rarely accessed but continue to incur costs.

Common examples include:

old database snapshots that were never cleaned up
log archives retained indefinitely
unused container images in registries
artifact storage from old CI pipelines Without lifecycle policies, these storage systems gradually become long-term archives rather than operational infrastructure.

Why These Issues Are Hard to Detect
The most expensive Terraform mistakes rarely appear as obvious misconfigurations.

Instead, they emerge gradually as systems evolve.

Each decision may appear reasonable in isolation. The instance size seems safe. The logging level helps debugging. The staging environment might be needed later.

The problem is that Terraform faithfully preserves these decisions over time.

Without regular review, infrastructure configurations slowly drift away from the actual needs of the system.

How AI Can Help Detect These Patterns Earlier
AI cannot fix infrastructure architecture problems automatically. But it can help identify patterns that humans might overlook.

For example, AI systems analyzing infrastructure configurations or Terraform plans can highlight signals such as:

compute resources that appear significantly over-provisioned
environments that remain idle for long periods
storage resources that grow continuously without access
resource replacements that may trigger unnecessary redeployments
These insights allow teams to review infrastructure decisions earlier rather than discovering problems only when the monthly bill arrives.

The Real Lesson
Terraform is an incredibly powerful tool for managing infrastructure. But like any automation system, it faithfully executes the decisions encoded within it.

If inefficient patterns exist in the configuration, Terraform will reproduce them perfectly every time.

The goal is not to avoid mistakes entirely. That is unrealistic in complex systems.

The goal is to detect small inefficiencies early — before they accumulate into large and expensive infrastructure problems.

Closing Thought
Cloud costs rarely explode because of one catastrophic decision.

More often, they grow quietly from dozens of small infrastructure choices that were never revisited.

Terraform gives us the power to manage infrastructure systematically. The challenge is making sure the systems we define remain aligned with how they are actually used.

That requires continuous review, feedback, and sometimes a second set of eyes — whether human or machine.

Originally published on Medium:
https://medium.com/@yogesh.vk/5-expensive-terraform-mistakes-i-keep-seeing-in-real-infrastructure-and-how-ai-can-help-9a4849ddfc91

AI for DevOps and Platform Engineering: Practical Use Cases That Actually Work

Yogesh VK — Fri, 13 Mar 2026 04:53:55 +0000

Moving beyond hype to real workflows where AI improves infrastructure engineering, and where AI is actually useful for DevOps and Platform Engineering teams today.

INTRODUCTION
AI is rapidly entering every corner of software engineering. DevOps and platform teams are no exception. New tools promise to generate infrastructure code, manage deployments, and even run operations autonomously.

But most experienced infrastructure engineers react with skepticism.

Infrastructure systems are complex, stateful, and deeply interconnected. Blind automation often introduces more risk than it removes. The question is not whether AI can be used in DevOps workflows — it is where it should be used, and where it should not.

The most effective teams are not replacing engineers with AI. They are using AI to reduce cognitive load, surface hidden risks, and make better operational decisions.

THE SHIFT FROM AUTOMATION TO ASSISTED DECISION-MAKING
For years, DevOps focused heavily on automation. CI/CD pipelines automated builds, tests, deployments, and infrastructure provisioning. Infrastructure-as-Code tools like Terraform allowed teams to define environments in reproducible ways.

AI introduces a new layer to this model.

Instead of simply automating actions, AI can assist engineers in understanding the consequences of those actions. It becomes a reasoning layer that helps interpret complex systems rather than directly controlling them.

In practice, this means AI is most valuable when it explains systems, analyzes changes, and highlights risk.

AI FOR INFRASTRUCTURE CODE REVIEWS
Infrastructure changes often carry significant risk. A single change in Terraform can replace compute clusters, modify network boundaries, or expand IAM permissions.

Traditional CI pipelines verify syntax and policy compliance, but they rarely explain the real impact of a change.

AI can help fill this gap by reviewing Terraform plans and summarizing their implications. Instead of manually scanning hundreds of lines of plan output, engineers can see a concise explanation of what will change and why it matters.

This turns infrastructure reviews into clearer conversations about risk and intent.

Raw Terraform Plan (excerpt):

# aws_eks_node_group.platform_nodes must be replaced
-/+ resource "aws_eks_node_group" "platform_nodes" {
instance_types = ["t3.large"] -> ["m5.large"]
scaling_config {
desired_size = 3 -> 3
}
}

AI-Generated Explanation:

Terraform Plan Summary
High Impact Change
- EKS node group "platform_nodes" will be replaced
- Worker nodes will be recreated
Operational Impact
- Pods will be rescheduled during node replacement
- Temporary capacity reduction possible
Cost Impact
- Instance type upgrade (t3.large → m5.large)
- Estimated monthly increase: ~$120

AI IN CI/CD PIPELINES
CI/CD pipelines are another natural integration point for AI.

Modern pipelines already perform many automated checks:

formatting validation
policy enforcement
dependency scanning
infrastructure plan generation
AI can extend this pipeline by interpreting the results of those checks.

For example, an AI step in a GitHub Actions workflow might analyze a Terraform plan and generate a structured summary highlighting resource replacements, cost changes, or security-sensitive updates.

The pipeline still requires human approval before changes are applied. AI simply improves the context available to reviewers.

name: Terraform Plan Review
on:
 pull_request:
jobs:
 terraform-plan:
   runs-on: ubuntu-latest
   steps:
     - uses: actions/checkout@v4
     - name: Run Terraform Plan
       run: terraform plan -out=tfplan
     - name: Convert plan to JSON
       run: terraform show -json tfplan > plan.json
     - name: AI Plan Analysis
       run: |
         ai-review plan.json > plan-summary.md
     - name: Post summary to PR
       uses: marocchino/sticky-pull-request-comment@v2
       with:
         path: plan-summary.md

The AI step reads the Terraform plan and generates a human-readable summary posted directly into the pull request.

AI FOR SHIFT-LEFT INFRASTRUCTURE SECURITY
DevSecOps practices encourage teams to identify security risks earlier in the development lifecycle. However, infrastructure security policies are often difficult to interpret or enforce consistently.
AI can assist by analyzing infrastructure definitions and identifying potential issues before they reach production.

For example, an AI assistant could flag:

overly permissive IAM policies
public exposure of internal services
misconfigured storage access
network boundary changes

These insights can appear during pull request reviews or pipeline checks, allowing teams to address security concerns before deployment.

Example PR comment:

Infrastructure Security Review
Issue Detected
- S3 bucket allows public read access
Resource
aws_s3_bucket.website_assets
Risk
Public exposure of application assets.

Suggested Fix
Add block_public_acls = true
Add block_public_policy = true

AI FOR OBSERVABILITY AND INCIDENT RESPONSE
Operations teams often face the challenge of interpreting large volumes of monitoring data.

Logs, metrics, and alerts can provide enormous amounts of information, but identifying the root cause of an issue still requires human reasoning.

AI can assist by analyzing telemetry data and highlighting patterns that indicate emerging problems. Instead of scanning dashboards and logs manually, engineers receive summaries that connect signals across systems.

Used carefully, this can reduce alert fatigue and accelerate incident investigation.

Example:
Raw logs:

ERROR connection timeout db-primary
ERROR connection timeout db-primary
ERROR connection timeout db-primary

AI explanation:

Alert Analysis
 Pattern Detected
    Repeated connection failures to database cluster.
 Likely Cause
    Database connection pool exhaustion.
Suggested Investigation
    Check RDS connection limits and application pool size.

This ties AI to real operations.

WHERE AI SHOULD NOT BE USED
Despite its strengths, AI should not be allowed to control critical infrastructure operations without human oversight.

Executing infrastructure changes, approving deployments, or modifying security policies are decisions that carry operational responsibility.

AI can provide insight, but it cannot own the consequences of those decisions.

The most effective DevOps teams treat AI as an assistant rather than an operator.

BUILDING AI-AUGMENTED PLATFORM WORKFLOWS
The real opportunity is not replacing DevOps workflows, but enhancing them.

A healthy AI-assisted platform might include:

AI explanations for Terraform plans
AI-generated summaries for infrastructure pull requests
AI-assisted security analysis during CI/CD
AI-powered analysis of observability data Each capability improves clarity and reduces cognitive load while preserving human ownership of operational decisions.

CLOSING THOUGHT
AI will undoubtedly influence how infrastructure systems are built and operated. But its greatest value will not come from replacing engineers.

It will come from helping them understand increasingly complex systems.

DevOps was originally about bringing development and operations closer together. The next phase may be about bringing human judgment and machine insight into better balance.

medium.com