There’s a distinction few people articulate when talking about AI applied to development: it’s not the same to let an assistant like Claude Code write an email validation function as letting it write the Terraform that deploys your production environment.

The first you review in three minutes and, if it’s wrong, the worst that happens is a test fails. The second, if it’s wrong, can leave your database publicly exposed at two in the morning and you find out on Monday from an AWS email.

And yet most of the “vibe coding” enthusiasm with AI focuses on application code. Infrastructure as code (IaC) gets less attention and, in my experience working with teams using Claude Code for Terraform, Pulumi or AWS configurations, it’s exactly where AI changes the rules of the game more than anywhere else.

This article is what we’ve learned. It isn’t a guide to “how to use AI for infrastructure”. It’s a reflection on what changes, what doesn’t, and where the real limits are.

What AI does well with infrastructure as code

Terraform files, Kubernetes manifests, CloudFormation templates, Ansible configurations — they all share a feature that makes them particularly suitable for AI assistance: they’re declarative.

You don’t explain step by step what the machine has to do. You declare the final state you want (“a PostgreSQL 16 database in eu-west-1 with automatic backup and replication to eu-west-3”) and the tool takes care of comparing against the current state and applying the necessary changes.

That fits perfectly with how an assistant like Claude works. AI is good at describing desired states from intent. It’s much better at translating “I want a load balancer with automatic SSL and managed certificates” into correct Terraform than at generating complex procedural code from scratch.

Three things that go really well in my flow with Claude Code applied to IaC:

Generating reasonable initial configuration. You give it your project context and ask for the first version of a VPC with public and private subnets, NAT gateway, security groups and the rest. In three minutes you have eight hundred lines of Terraform that are mostly correct. Removing names and specific decisions, that’s the part that used to eat the most time.

Refactoring to use better practices. “Convert these five separate recipes into reusable modules.” “Migrate from count to for_each.” “Pull hardcoded values into variables.” Mechanical tasks a human does badly out of boredom, AI does consistently.

Reviewing configurations for obvious problems. Asking Claude “review this Terraform and tell me what’s wrong or missing” is surprisingly effective. It catches over-permissive security groups, missing standard tags, inconsistent network configurations, and things a human reviewer would skip.

What AI does badly and why

The good part comes with a dangerous flip side. There are three types of errors Claude Code makes with regularity in infrastructure, and all are of the “looks correct until you deploy to production” variety.

Invents attributes or resources that don’t exist. This is the classic “hallucination” but with expensive consequences. It generates Terraform that uses aws_lambda_function.runtime_version_2 when that attribute doesn’t exist, and since you’ve never applied that module before, you don’t catch it until terraform apply. There’s no debate here: any AI-generated configuration has to go through terraform plan before being reviewed.

Mixes provider versions. AWS Provider 4.x syntax isn’t exactly 5.x syntax. It may be mixing documentation from both. The version it generates might not compile against your current provider version.

Doesn’t know what you already have deployed. If your codebase has specific conventions (a mandatory tag suffix, a custom module for creating encrypted S3 buckets, a specific naming pattern), AI is going to ignore all of it unless you tell it explicitly. And it will generate technically correct code that’s incoherent with your ecosystem.

These three problems are why letting it write IaC without context is dangerous. With context, it works. Without context, it generates architecture that looks fine and breaks in production.

The fundamental shift: AI accelerates, doesn’t decide

The most common misunderstanding I see when a team starts using AI for infrastructure is the idea that the tool can make architecture decisions.

It can’t.

Deciding whether your system needs a relational or NoSQL database isn’t an isolated technical decision — it depends on the data model, access patterns, consistency requirements, budget and the team that will maintain it. That decision is made by a human architect.

What AI does excellently is execute that decision once made. “We’re going to use Aurora PostgreSQL with two replicas” translates to correct Terraform in seconds. But “we’re going to use Aurora PostgreSQL” is the work of the human brain that understands the business.

The practical result is that the role of the person doing infrastructure is changing. Less time writing recipes and more time deciding what to ask for, validating what AI produces, and keeping the system context updated so AI can generate within the right boundaries.

The three rules we apply to not break anything

Through trial and error, we’ve landed on three hard rules when working with Claude Code on infrastructure.

Rule 1: nothing applies without a plan reviewed by a human. The Terraform plan shows exactly what will change. Any suspicious diff (resources being deleted when you didn’t expect them to be, changes in production when you thought you were touching staging) is a signal to stop and review. This isn’t distrust — it’s basic responsibility.

Rule 2: secrets never go through the conversation with AI. API keys, database passwords, private certificates — those don’t enter the chat with Claude. They’re managed with a dedicated secrets system (AWS Secrets Manager, HashiCorp Vault, sealed secrets in Kubernetes) and the IaC code references secrets by name, not by value. This applies to humans too, but with AI the discipline has to be absolute.

Rule 3: separating environments isn’t optional. Having development, staging and production in separate Terraform states, with different permissions and differentiated review, isn’t a luxury. It’s the safety net that prevents a misapplied command from tearing down production when you were touching another environment. This rule existed before AI, but with AI it becomes critical because errors happen faster.

When NOT to use AI for infrastructure

Although AI applied to IaC works well in general, there are situations where it adds risk without compensating.

Critical migrations that depend on exact timing. If the cost of a failure is service interruption for hours, AI shouldn’t have direct control. It should suggest, a human executes
Systems with strict regulatory compliance. Sectors like healthcare, financial or defense have audit requirements where every change must be traced and justified by an identifiable person
When the reviewer doesn’t understand the output. If whoever reviews the AI-generated Terraform can’t seriously read Terraform, they’re not reviewing — they’re trusting blindly. That’s not AI use, it’s irresponsible delegation

The practice that actually moves the needle

The most useful thing we’ve added to the flow isn’t elaborate prompting or specific model configurations. It’s something more boring but more effective: maintaining a written, up-to-date system context that AI reads before generating code.

That context includes which providers we use, which versions, which shared modules are available, which naming and tagging conventions we follow, what’s expressly prohibited (resources without tags, security groups open to 0.0.0.0/0 in production), and which architecture decisions are already made.

When Claude Code reads that context before generating, the result goes from “code that looks correct” to “code that fits our ecosystem and can be applied as is with minimal changes”. The difference is night and day.

If you work with Claude Code on infrastructure and are thinking about how to structure the flow so AI accelerates without breaking things, this is exactly the kind of problem we solve. I share the workflow step by step in a video series in preparation — sign up and I’ll let you know when it’s ready.