When agents do the typing, the code stops mattering. What matters is what you meant, what is running, and the record of every change between them.

I have managed infrastructure across hundreds of AWS accounts with CloudFormation, CDK, Terraform, and Pulumi. Earlier this year I wrote a long comparison of all four, and I meant every word of it. Then, over the summer, I stopped writing any of them for my own infrastructure.

Every change to my AWS estate now goes through a tool I built called Foundry. There is no HCL in it, no templates, no state file, and no modules. I describe what I want, sometimes in a sentence, and Foundry turns that into a typed record, plans it against what is actually running in AWS, tells me exactly what it will do and what else that could break, and keeps a permanent record of what it did. My AI agents use it the same way I do.

I have started calling this Infrastructure as Intent. This article is about what that means, why I think it is where infrastructure management is going, and what it costs.

What Infrastructure as Code was actually for

It is worth remembering why we started writing infrastructure as code in the first place, because the code itself was never the point. We wanted four things:

Code was the best medium available in 2011 for getting all four at once. Text files fit into the tools engineers already had: editors, diffs, git, CI. That was a real win, and it is why IaC took over.

But code also brought a set of problems that we have spent fifteen years treating as normal:

• The state file. Terraform keeps its own idea of what exists, separate from what actually exists. When the two disagree, you spend an afternoon with terraform state mv and a strong drink.
• Drift as an embarrassment. Someone fixes production in the console at 2 AM. The code is now wrong, and the tool's answer is to undo the fix on the next apply.
• Brownfield is a project. Bringing an existing account under management means writing code that matches every resource exactly, then importing each one by hand.
• Abstractions that hide blast radius. A module, a for_each, a loop in CDK: they make the code shorter and make it harder to see what a change actually touches.
• A language to learn. HCL, or a CDK construct library, or Pulumi's flavor of your favorite language. Every one of them is a second job.

None of this is a criticism of the people who built these tools. They are excellent. The point is that the medium has costs, and we accepted them because typing the definition by hand was the expensive part and code made it repeatable.

That is no longer the expensive part.

What changed

My agents write most of my code now. When an agent can produce a correct Terraform module in seconds, the module stops being the valuable artifact. Nobody is going to cherish a file they didn't write and won't read closely.

What stays valuable is the stuff around the code:

1. What I meant. "A private Postgres database for Vita, reachable only from its service, backed up nightly, tagged to the fleet cost center."
2. What is actually running. Not what a state file believes. What AWS says, right now.
3. What a change will do. The exact list of creates, updates, and deletes, and everything else in the account that depends on them.
4. What happened. Every change, who or what made it, and the state of every resource at any point in time.

Infrastructure as Intent keeps those four things and drops the code in the middle.

The model

Here is the shape of it, as Foundry implements it:

Intent becomes a record, not a file

A Foundry stack is a flat collection of resources using AWS's own type names (AWS::EC2::VPC, AWS::RDS::DBInstance) with properties shaped like CloudFormation's. There is no language to learn because there is no language. A stack is data, stored in Postgres, versioned on every change.

You can create one by filling in a form, by calling one of Foundry's 153 MCP tools, or by describing it in English. The English path is where people get nervous, and they should, so here is the important part: the model that turns your sentence into a stack can only use resource types Foundry actually knows how to manage, and every property has to pass that type's schema. It cannot invent a resource or a property. The output is the same typed record you would have built by hand, and it goes through the same plan.

Live AWS is the source of truth

Foundry has no state file. Every resource type is a small Python class with create, read, update, and delete methods that call the AWS SDK directly. A plan reads the live resource, compares it with the record, and produces a typed diff. If someone changed something in the console, the plan shows it, and you decide whether the record or the console was right.

Drift stops being an embarrassment and becomes an event. Sometimes the 2 AM console fix was correct, and the right move is to take it into the record.

The plan is the review

In IaC, the review happens on the code, and you trust that the code means what you think it means. In Infrastructure as Intent, the review happens on the plan: the exact actions, counted, against the exact live state.

Foundry's plan also runs a blast-radius check before anything applies. It walks the dependency graph of the whole organization, managed and unmanaged, and scores everything that relies on what is about to change: anything that references it, sits in its security group or subnet, or uses its KMS key. A high-risk change does not apply until a person has looked at it.

My standing rule for my agents is simple: never apply a Foundry deployment without reading and counting every planned action. An agent can draft the change, plan it, and summarize it. A count that doesn't match the intent stops the work.

Every change is in the ledger

Stack versions, deployments, and CloudTrail events are fused into a per-resource history, effectively a git log for each resource. Foundry can reconstruct the exact properties of a resource at any past moment and roll a single resource back to it. That covers the "history" and "recovery" jobs that git and re-apply used to do, with more precision, because it records what really happened rather than what the code said should happen.

Brownfield is a command

This one surprised me the most. Foundry's inventory scan reads every account in the organization. The last scan of mine found 4,132 resources across nine accounts. An adoption pass then groups unmanaged resources into dependency-coherent stacks, using tags, naming, VPC placement, and the dependency graph, and imports each one as a stack whose first plan is empty. Nothing changes in AWS. The estate is just under management now.

Writing Terraform to match an existing account by hand is weeks of work. This is an afternoon of review.

The day I knew

In July, I moved nineteen of my tools off Terraform and onto Foundry. All nineteen came back healthy, and no database was touched.

The moment I knew I was done with code-first infrastructure came during the dry run. To retire each tool's old Terraform resources, the natural move was terraform destroy -target on that tool's task role. It turned out that a for_each elsewhere in the configuration built the policy attachments for every tool's role from a single map. Targeting one tool's role would have cascaded into destroying all eighteen attachments and stripped the runtime permissions off every live service at once.

The code was correct. It did exactly what it said. You just couldn't see what it said by reading it, because the abstraction that made it short also hid how far one change reached. A counted plan with a blast-radius score would have shown eighteen deletions where I expected one.

What it costs

I don't think Infrastructure as Intent is free, and anyone selling it as free is selling something. Here is what you give up, honestly:

There is also a trust question that is easy to wave away. If the model that writes your infrastructure is wrong, it is confidently wrong. Infrastructure as Intent only works if the intent becomes something checkable, a typed record against a schema, and if a person approves the plan before anything applies. Take either one away and you are just letting a chatbot loose in production.

What does not change

Some things carry over exactly, and they matter more than the medium:

• Review before apply. Still mandatory. It moved from the code to the plan.
• Least privilege. The tool that applies changes should hold the permissions to make them and nothing else.
• Tag at creation. Foundry refuses to apply a resource that is missing a required cost tag, because a tag added later never shows up in historical billing.
• People own production. Agents draft, plan, and explain. A person signs off on anything that matters.

Where this goes

I think the next decade of infrastructure management looks less like writing code and more like stating intent, reviewing plans, and reading ledgers. The skills that matter shift with it: less fluency in HCL, more judgment about what a plan should look like, what a blast radius is telling you, and when drift was actually the right answer.

Infrastructure as Code taught us to want repeatability, review, history, and recovery. Those were the right goals. Code was simply the best way to get them when people did all the typing. Now that the typing is free, we can keep the goals and drop the medium.

I have been running my own estate this way since July. I'm not going back.