AI for Infrastructure as Code

AI for infrastructure as code is the use of a model to draft, explain, or classify Terraform and OpenTofu work — not to become the cloud account.

The useful split is: models are good at language and pattern completion. Clouds punish confident wrong APIs. Governance exists so the second fact wins.

What is actually working

Drafting modules from intent or a repo. Given a service's Docker files, Helm values, or existing cloud resources, a model can propose a first topology: network edges, a data store, IAM skeletons. A human still has to pin versions, decide tenancy, and delete the fictional aws_perfect_vpc.

Explaining a plan to a reviewer. “This plan replaces the listener rule and opens 443 to 0.0.0.0/0” is a better approval surface than 400 lines of HCL. The model must be grounded in terraform show -json, not in the prompt.

Classifying drift. Models can bucket diffs into security / reliability / hygiene if you give them the plan JSON and a rubric. They should not auto-reconcile.

Answering “what does this module do?” Onboarding and review get faster when the explanation is tied to addresses in state.

What still fails in production

• Hallucinated resources and arguments. Provider schemas change. A model will happily emit an attribute that never existed.
• Silent blast radius. “Make it highly available” can mean a second region and a four-figure bill.
• Skipping the plan. Chat output is not a saved plan. Apply the file you reviewed.
• Training on your secrets. Prompts that include state, tfvars, or plan JSON need the same data-handling rules as any other SaaS.

If a vendor demo jumps from a sentence to green infrastructure with no plan in the middle, treat it as a demo.

A safe loop for AI-assisted IaC

1. Ground. Start from a repo, an inventory, or an existing module — not a blank chat.
2. Generate a draft. Modules and variables, not a one-file snowflake if you can avoid it.
3. Machine-check. fmt, validate, terraform test where you have tests, and policy on the plan.
4. Review like a PR. High-risk types still follow who approves a terraform apply.
5. Apply the saved plan. Then watch drift like you would for any other change.

That is the same loop as good CI, with a faster author.

What you should still refuse

A draft from a repo is useful. An apply without a plan is not.

If you want that loop on a real repository — infer topology, emit Terraform or OpenTofu, then stop for policy and review — start with repository intelligence and generation. The walkthrough is repo to infrastructure.