Provisioning an environment through the console is fast the first time and expensive forever after. Nobody remembers who opened that port, why the database ended up on a different subnet, or exactly what changes if the environment has to be rebuilt in another region. Terraform solves this by turning infrastructure into versioned code. And AI assistants have changed the economics of writing it: what used to be a month of modules and refactoring is now a week of technical conversation plus review.

In this article we set out what AI genuinely accelerates in infrastructure as code, what it still does not do on its own, the five-step method we use in the field and the guard-rails we refuse to give up. The backdrop is concrete: we built the cloud infrastructure of a Brazilian insurer with AI-assisted Terraform, and applied the same logic to the Windows desktop estate through our own Intune as Code framework.

Why IaC stopped being optional

Three demands killed off manual provisioning. The first is reproducibility: if production and staging do not come from the same code, the test proves nothing. The second is auditability — in regulated sectors, “who changed what and when” needs an answer, and the repository history is the cheapest answer available. The third is reversibility: an environment described in code returns to its previous state with a revert, not with memory and luck.

There is also a side effect nobody anticipates: the code becomes the documentation. When somebody asks how the network is designed, the answer is not an out-of-date spreadsheet — it is the file. That is why we treat IaC as part of the infrastructure discipline, not as a preference held by the development team.

What AI genuinely changes

Four gains show up consistently. None of them is “AI did it on its own”.

• Module generation. Describing “a VPC across three zones, public and private subnets, NAT gateway and cost-centre tags” and getting a structured module back saves the mechanical work. The bigger gain is not the typing: it is that AI comes out with variables, outputs and a README that a human would leave for later.
• Plan review. A terraform plan for a large change spits out hundreds of lines. Asking an assistant to summarise what will be destroyed, what is being renamed and what forces recreation turns diff reading into a conversation. This is where AI catches the silent replace of a database that nobody had spotted.
• Drift detection. Someone always touches the console during a small-hours incident. Feeding the output of plan -refresh-only into analysis quickly separates harmless drift (a tag) from dangerous drift (a security group rule left open).
• Living documentation. Diagrams, resource tables and change notes generated from the real code. Documentation born from the current state does not age the same way.

What AI does not do on its own

It does not know your network topology, the IP blocks already reserved or the contract with the provider. Nor does it know which database holds production data and which one is disposable — and a confident assistant proposes destroy just as naturally as it proposes create. On top of that, it gets provider attributes wrong when they change between versions, producing code that looks right and fails at validate.

The five-step method

1. Take inventory before writing. Survey what already exists and import it into the state, instead of rebuilding on top. An orphan resource outside Terraform is guaranteed debt.
2. Define the skeleton by hand. Naming conventions, mandatory tags, folder structure and environment separation. That contract is short and human — and it is precisely what makes AI generate coherent code afterwards.
3. Generate module by module, not whole environments. Network, compute, database, identity, observability. Each module with validate, lint and a clean plan before moving on to the next.
4. Review the plan with AI and with people. AI summarises and raises the hypothesis; the engineer decides. Every destroy or force replacement line needs an explicit justification.
5. Close the loop with a pipeline. Automatic plan on the pull request, apply only after approval, and periodic drift checks. Without that, the repository becomes fiction within three months.

Non-negotiable guard-rails

• Remote state with locking. State on somebody’s machine is an accident waiting to happen. Remote backend, versioned, encrypted and with locking — two simultaneous apply runs corrupt the state.
• Secrets outside the code. Passwords, keys and tokens live in a managed vault, referenced by identity. Worth remembering: a variable marked as sensitive still does appear in the state file.
• Human review of the plan. No automatic apply in production. The approved plan is the one that runs, and the approval is recorded.
• Policy as code. Rules that stop the pipeline: a public bucket, port 22 open to the world, a resource with no cost-centre tag, a region outside the permitted list. A policy that depends on somebody remembering is not a policy — and, without a cost tag, FinOps work starts blind.
• Least privilege for the pipeline. The credential that applies infrastructure is the most powerful one in the environment. It deserves the same rigour as any security control: minimum scope, rotation and an audit trail.

Before and after: an insurer’s case

The cloud environment of a Brazilian insurer was provisioned by hand. Standing up a new environment took days and produced divergence between staging and production — the classic “it worked in staging”. There was no reliable inventory, and every audit turned into a hunt for console screenshots.

With AI-assisted Terraform, the base was rewritten as modules: network, compute, database, identity and observability. After that, standing up an equivalent environment became a matter of hours, using the same code and only different variables. The gain that mattered, though, was not the speed — it was the audit becoming a diff, and drift becoming an alert rather than a late discovery.

We extended the same idea to the Windows desktop estate with an Intune as Code framework in PowerShell over the Microsoft Graph API: exporting tenant policies to versioned files and applying them back in a controlled way. The effect is Terraform’s, in another domain — configuration stops being a portal click and becomes reviewable code. Not by chance, that inventory became a direct input to the FinOps work: a tagged resource is a resource you can explain on the invoice.

If your environment is not yet in code, the step before that is usually the cloud design. At Inove Academy we publish the quick guide to cloud migration, which helps you decide what goes by lift-and-shift and what deserves a redesign before becoming Terraform. And, to size the return, the FinOps calculator shows where the waste is concentrated — usually in the very resources nobody can say who created.

One methodological caveat, to close. Taking non-SAP systems to the cloud, moving SAP to the cloud and converting to S/4HANA are three different conversations, each with its own risks and timelines. AI-assisted Terraform speeds up the infrastructure foundation for all three, but replaces none of them — and treating everything as a single project remains the fastest way to delay all three.