Why IaC remains the cornerstone of DevOps, even in the AI era
Two observations recently caught my attention:
First, a friend built an impressive app in their spare time—code flowing smoothly, everything working beautifully—until deployment hit. That’s where things fell apart.
Second, I’ve seen numerous AI showcases where people deploy infrastructure (say, a Kubernetes cluster) using Markdown or AI Skills. It looks impressive to those who’ve never run production systems. But burning tokens to do what a bash script handles reliably? That’s a questionable trade-off.
These incidents reminded me of a foundational topic: Infrastructure as Code. It’s not just a tool. It’s a revolution that solved one of DevOps’ most fundamental conflicts.
Why “As Code” Matters
Code is one of the few things in this world that actually does what it says.
Deterministic: Code produces the same result today, tomorrow, and next week. It’s precise, unambiguous, and predictable—a lifeline in production environments.
Automatable: Humans get tired, distracted, and make mistakes. Code doesn’t. A well-configured CI/CD pipeline works 24/7 without complaint.
Testable: You can verify behavior in local and staging environments before touching production. Manual operations? You’re left hoping for the best.
Traceable: Git tracks every change—who changed what, when, and why. When issues arise, you can pinpoint the cause instantly. Rollback? One command.
The “as code” philosophy extends beyond infrastructure:
- Infrastructure as Code (Terraform, Ansible) turns servers, networks, and databases into versioned code
- Policy as Code (OPA/Rego) makes security and compliance rules reviewable and testable
- GitOps treats your Git repository as the single source of truth
The core principle: if it can be written as code, don’t rely on manual execution.
The Revolution IaC Brought
Before Infrastructure as Code, every server was a handcrafted artifact.
Operations teams would SSH into machines and run commands one by one: install Nginx, update configs, restart services—all manual work. Over time, only the person who originally configured that server knew its hidden quirks. Handoff to someone else? Good luck.
The real problem was that Dev and Ops couldn’t effectively collaborate:
Dev: “The code runs perfectly on my machine!”
Ops: “But it doesn’t work in production. How am I supposed to know what you have installed locally?”
This is the origin of the classic “works on my machine” meme.
IaC bridged this gap:
- Developers gained the tools and confidence to manage infrastructure themselves
- Operations work shifted from artisanal craftsmanship to engineering—with version control, testing, and reproducibility
In short, IaC brought infrastructure into the industrial age.
Three Core Principles of IaC
Declarative Programming
Imperative approach: You tell the machine “do A, then B, then C”—step by step, hand-holding every operation.
Declarative approach: You describe the desired state. The tool figures out what needs to change and converges to that state.
Example:
- Imperative Shell script: apt install nginx && systemctl start nginx && ... (you worry about each step)
- Declarative Terraform: resource "aws_instance" { ... } (you specify the target state; Terraform calculates the diff)
This is why Terraform and Kubernetes manifests became mainstream. Who wants to manually calculate deltas?
Idempotency
Running the same configuration once or a hundred times produces identical results.
What does this mean? You can safely re-run CI/CD pipelines without worrying about duplicate resource creation or accumulating side effects.
Idempotency is a byproduct of declarative design and the foundation of scalable IaC adoption.
Immutable Infrastructure
Traditional (mutable) approach: When a server has a bug, SSH in and patch it: apt upgrade, tweak a config. Sounds flexible, but it's actually the beginning of configuration drift. Over time, you lose track of what's actually running.
Immutable approach: Don’t patch running systems. Destroy the old, deploy the new.
- Docker images are the canonical example—once built, they never change. To update, you rebuild.
- AWS AMI + Packer follows the same philosophy at the VM level.
The benefit? Every deployment starts clean, with no accumulated technical debt.
The IaC Tooling Landscape
Configuration Management
Solves “install software and configure settings on existing machines.”
- Ansible: Agentless, YAML-based, push model—currently the most popular
- Older options include Chef (Ruby DSL), Puppet (declarative, pull model), and SaltStack—now less common
Infrastructure Provisioning
Solves “create and destroy cloud resources.”
- Terraform: Multi-cloud, declarative, HCL syntax—the de facto standard. OpenTofu is its open-source fork.
- Pulumi: Write IaC in real programming languages (Python, Go, TypeScript)—more developer-friendly
- Cloud-native options (AWS CloudFormation, Azure Bicep, GCP Deployment Manager): Deep integration with vendor ecosystems, but platform-locked
Container Orchestration
- Docker/Dockerfile: Images as immutable artifacts—the foundation of modern IaC
- Kubernetes manifests/Helm/Kustomize: Declarative application runtime descriptions, core to GitOps
GitOps Controllers
- ArgoCD, Flux: Monitor Git repo changes and automatically sync configurations to clusters—GitOps in practice
Policy as Code
- OPA (Open Policy Agent) / Rego: Write security and compliance rules as code, embed in CI/CD for admission control
The AI Era: Don’t Get Fooled by Hype
Back to the opening scenario: people converting Terraform code into Markdown or AI Skills for showcase demos.
Let me be blunt: that’s theater, not engineering.
Why?
1. LLM outputs are probabilistic, not deterministic. In production, “probably correct” is a problem. Would you let GPT manage your production servers? I wouldn’t.
2. Markdown isn’t code. No syntax validation, no type safety, no testing framework. You’ll only discover errors when things explode in production.
3. IaC code written by DevOps teams has real value. Don’t rewrite it into “friendlier” formats for demo points—that’s not user-friendly, it’s self-sabotage.
That said, AI isn’t useless:
- Use agents to surface existing IaC assets through friendlier query or deployment interfaces
- Use LLMs to assist generating IaC snippets (but you must review and test them yourself)
The core principle: compare the cost of running an Ansible playbook versus an AI Skill. Know the trade-offs.
DevOps exists to save cost. If your “innovation” increases costs instead, it’s not innovation—it’s vanity. Always ask: “But at what cost?”
Key Takeaways
- Code is deterministic—the foundation of reliable systems
- IaC bridged the Dev/Ops divide by making infrastructure reproducible and testable
- Declarative, idempotent, immutable—the three pillars of IaC design
- Choose the right tool for your context: Ansible for configuration, Terraform for provisioning, Kubernetes for orchestration
- Don’t mistake AI demos for production-ready solutions—engineering requires certainty, not probability
Final Thoughts
Infrastructure as Code isn’t new, but it remains the backbone of successful DevOps practices.
If you’re still manually SSHing into servers or arguing over “works locally but not in production,” it’s time to adopt IaC.
If you’re already using Terraform or Ansible, keep refining your skills. Don’t get distracted by shiny AI demos. Engineering is about certainty, not probability.
A principle to live by: If it can be written as code, don’t do it manually. If it can be automated, don’t rely on faith.