AI and Infrastructure as Code: IaC Made Provisioning Repeatable. Agentic Makes It Adaptive.

Infrastructure as Code solved a genuine problem, and it is worth remembering how bad things were before it. Infrastructure lived in someone’s head and in a console someone had clicked through eighteen months ago. Environments drifted apart for reasons nobody could reconstruct. Rebuilding meant archaeology.

IaC fixed that. Declare the state you want, put it in version control, apply it, get the same result every time. It is now the baseline expectation for any serious team — Terraform alone holds around 76% share by the CNCF’s 2024 survey, and the argument about whether to codify infrastructure ended years ago.

But notice what IaC is: a definition of a desired state that then waits. It waits for a human to notice drift. It waits for someone to decide to scale. It waits for an engineer to open a laptop at 3 AM and start reading logs. Reproducible, yes. Adaptive, no. That gap — between infrastructure that is defined and infrastructure that responds — is what agentic automation is actually for.

First: nothing is replacing Terraform

A lot of content in this space implies that AI is coming for your IaC tooling. It is worth killing that idea immediately, because getting it wrong will make every other decision worse.

Terraform, Pulumi, OpenTofu, and CloudFormation are the substrate. An agent that manages infrastructure does so by producing and applying IaC — and that is the point, not an implementation detail. The IaC layer is what makes an agent’s actions reviewable in a pull request, versioned in git, diffable against last week, and reversible when wrong.

Strip it out and picture what remains: an agent making direct API calls against your cloud account, with no declared state to compare against and no artifact to review. That is not a more advanced system. It is the pre-IaC world with a language model in it, and it is unauditable in exactly the way IaC was invented to fix.

Intent to infrastructure, concretely

The clearest picture of what agentic adds is a pattern sometimes called intent-to-infrastructure. Walk it through, because the abstraction is slippery and the steps are what matter.

An engineer describes a need in plain language: a Postgres cluster for the billing service, multi-AZ, with point-in-time recovery and thirty-day backup retention. An agent turns that into actual Terraform — not a snippet from a tutorial, but code shaped to this organization’s module conventions. It validates that code against the policy guardrails that already exist: encryption required, approved instance families, mandatory tags, no public subnets for data stores. Then it opens the result as a proposal for a human to review.

What did that add? Not the ability to write Terraform — a competent engineer can do that. It removed the twenty minutes of looking up the module signature, the argument about which backup setting the policy requires, and the review round-trip where someone points out the missing tag. Every step is logged, and the output is ordinary IaC that goes through your ordinary review.

That is genuinely useful and it is not autonomy. The engineer still decides. Which brings us to the part that decides whether any of it works.

The blindness problem

Here is the failure that catches teams, and it is under-discussed relative to how much damage it does.

Generating infrastructure code is stateless. The model knows what you asked for. It does not know what is already deployed. It does not know your existing VPC IDs, your current IAM role structure, your Route 53 zones, or which resources a new module is about to collide with. It has never looked at your account.

And it will not tell you that. It will produce clean, idiomatic, confident Terraform for an estate it has never seen — code that would be perfect in an empty account and is quietly wrong in yours. It references a security group that does not exist. It creates a subnet that overlaps. It names a resource that is already taken. The code reviews well, because there is nothing wrong with it as code.

The fix is one step, and it is the step that separates a system worth having from one that quietly reintroduces the inconsistency IaC existed to eliminate: read first. Query the actual live state before generating anything. What exists, what it is called, what it is connected to, what would conflict. Then generate a change that accounts for reality, check it against policy, and put it in front of a human.

Be clear-eyed that this is a current gap rather than a solved problem. Live-state awareness is named in the research as an open weakness in AI-assisted infrastructure work, not something the tooling handles for you by default. When you evaluate anything in this category, that is the question to lead with: does it look at my infrastructure before it proposes changes to it? A surprising number of things do not.

The reviewed plan is the line

The same staged-autonomy principle that governs agentic pipelines applies here, and the stakes are higher because infrastructure mistakes are less reversible than a bad build.

The credible default in 2026 is a reviewed plan before anything executes. The agent proposes; a human reads the plan; then it applies. Teams further along typically start in recommend-and-approve mode for anything sensitive — production changes, IAM policy edits, anything touching data — and widen autonomy only as the system earns it in that specific environment.

That sounds conservative until you consider the failure mode it prevents, which is the best argument in this whole article:

That scenario is why “detect drift and fix it automatically” is a worse product than it sounds. Drift is not a category of error. Sometimes it is a mistake; sometimes it is the only thing keeping the site up. Telling them apart requires knowing why a human did something, which is exactly the information an agent watching the estate does not have.

Which is not an argument against drift detection — detection is enormously valuable, and the data says so. Firefly’s State of IaC 2026 found a third of respondents tied drift to a costly production incident, 8% to significant downtime, and nearly 20% have no drift detection or remediation process at all. The gap is real. It is the automatic remediation half that needs a human, not the detection half.

What is genuinely useful today

Three use cases have real traction, ordered roughly from safest to most ambitious.

• Incident-context gathering. A critical alert fires. Before anyone is properly awake, an agent has assembled the relevant logs, what changed in the last few hours, which dependencies are involved, and what the equivalent alert meant last time. It has changed nothing. It has just done the twenty minutes of gathering that used to happen after you found your laptop. This is the safest of the three and frequently the most immediately valuable, because it is pure augmentation with no write path at all.
• Drift detection. Continuously compare live state against declared state and surface the differences with context: what changed, when, by whom if that is knowable, and whether it matters. Surface it. Let a human decide what it meant.
• Predictive scaling. Adjust resources ahead of anticipated load rather than reacting after latency has already climbed. Reactive autoscaling is inherently late — it responds to a problem your users already felt. Anticipating a known pattern is genuinely better, and it is bounded: the blast radius of scaling is usually cost rather than an outage, which makes it one of the few places wider autonomy is defensible early.

Where Macrosol fits

Every one of the decisions above is environment-specific, and that is the whole difficulty. Which changes are routine enough for an agent to propose and apply unattended, which need a human on the plan, whether drift in a given resource is worth reverting or worth asking about, whether your agent can even see the live estate before it writes about it — none of that has a generic answer, and getting it wrong costs you either an incident or an expensive system nobody trusts. Macrosol Technologies helps teams design those guardrails and staged-autonomy boundaries for their actual cloud environment, on top of the IaC they already have rather than in place of it, as part of our DevOps & Cloud Native practice.

From reproducible to adaptive

Infrastructure as Code made infrastructure reproducible, and that was the hard part. What it did not make it is responsive — it still waits for a human to notice, decide, and act. Agentic automation closes that gap: infrastructure that observes itself and can move before someone opens a laptop.

But the version of that worth building is unglamorous. It reads your live state before it says anything about it. It proposes rather than applies, until it has earned more. It knows the difference between what it can see and what it can understand — and the 3 AM patch is the permanent reminder that those are not the same thing. Build it that way and you get infrastructure that adapts without becoming a black box nobody can audit six months later. Skip the reviewed plan because the demo was impressive, and you will find out which kind you built during an incident.