Is Infrastructure as Code the Next Abstraction to Fall?

Stephen Jones
February 17, 2026

Table of Contents

I’ve been staring at a Terraform module for the last ten minutes, and I can’t stop thinking about a question that would have been absurd two years ago: why am I writing this?

Not “why am I provisioning this infrastructure.” That part makes sense. But why am I writing HCL, a domain-specific language that exists to describe infrastructure in a way that humans can read, when I have an AI agent sitting in my terminal that can call the AWS API directly?

It’s the kind of question that sounds naive until you realise the same logic is playing out across every layer of the stack. And the more I look at it, the more I think we’re watching the early stages of a fundamental shift in how we interact with machines.

The Pattern Nobody Is Connecting

Here’s what I keep noticing. The same structural change is happening everywhere, and most people are only seeing it in their own domain.

HTML is getting a Markdown layer. On 12 February 2026, Cloudflare launched “Markdown for Agents”, a feature that converts HTML pages to Markdown in real time at the CDN edge. A Cloudflare blog post that costs 16,180 tokens in HTML drops to 3,150 tokens in Markdown. An 80% reduction. Meanwhile, the llms.txt standard proposed by Jeremy Howard has been adopted by over 844,000 websites, providing a clean Markdown summary for AI agents at the site root.

Knowledge management is going filesystem-first. I’ve been moving my own systems from Notion to Obsidian, and the reason isn’t features. It’s access. Notion locks your data behind an API with OAuth tokens and rate limits. Obsidian stores everything as plain Markdown files on your filesystem. Claude Code can read, edit, and organise those files directly. No authentication, no format conversion, no intermediary. Steph Ango, Obsidian’s CEO, has been writing about “file over app” for years. That philosophy, conceived before the AI agent wave, has turned out to be retroactively prophetic. He even published obsidian-skills, open-source Agent Skills that teach AI agents how to work with Obsidian file formats.

Developer interfaces are moving to the terminal. Every major AI lab now ships a CLI tool: Claude Code, OpenAI Codex CLI, Google Gemini CLI. The reason is structural, not aesthetic. CLI tools are text-in, text-out. That’s the native language of context windows. A GUI that renders pixels is overhead when the consumer is a language model. As The New Stack puts it: “In 2025, the terminal is more than just a place for commands. It’s a collaborative workspace where modern AI agents now live.”

Repositories are getting agent configuration files. CLAUDE.md, AGENTS.md, .cursor/rules/, .github/copilot-instructions.md. These files exist for one reason: to give AI agents context about the project. A January 2026 study of AGENTS.md files across 10 repositories found a 28.64% median runtime reduction for AI coding agents. Not a marginal improvement. A fundamental efficiency gain from giving the agent the right context.

The pattern is the same every time. A format designed for human consumption is being supplemented (or replaced) by a format designed for AI consumption. HTML gets a Markdown layer. Cloud UIs get CLIs. Proprietary data stores get filesystem access. Human documentation gets agent configuration files.

Which brings me back to my Terraform module.

The IaC Question

Infrastructure as Code tools like Terraform, CloudFormation, and Pulumi exist because of a specific historical constraint: humans needed a readable, versionable, reviewable way to describe infrastructure. HCL, YAML, and JSON templates are human-readable formats for a human-driven workflow.

But if the primary consumer of infrastructure definitions is shifting from a human engineer to an AI agent, does the format need to change too?

The honest answer is: it’s already changing.

What the Vendors Are Doing

Pulumi has moved furthest. In September 2025, they launched Pulumi Neo, a fully agentic platform engineering AI agent that automates infrastructure provisioning end to end. Neo can independently execute complex tasks, understand dependencies across cloud resources, and generate detailed previews. Pulumi’s original bet, use real programming languages instead of a DSL, looks increasingly prescient. LLMs have extensive training data in TypeScript, Python, and Go. They struggle with HCL. Microsoft’s research confirms it: “AI coding agents excel at generating code for mainstream languages, but research shows their accuracy on domain-specific languages often starts below 20%.”

HashiCorp (now IBM, after the $6.4 billion acquisition) is taking a different approach. At HashiConf 2025, they unveiled Project Infragraph, a real-time infrastructure knowledge graph that connects infrastructure, applications, services, and ownership into a continuously updated relational model. The vision: AI reasons about the graph, not the code. They simultaneously killed CDKTF, forcing everyone back to HCL. The bet is that HCL becomes the structured language that AI agents consume and produce, with the graph as the reasoning layer on top.

Spacelift has gone the furthest toward proving the thesis. Their open-source Intent project, launched October 2025, enables natural language infrastructure provisioning with no .tf files, no plan-apply cycles. It calls provider APIs directly through Terraform providers. No HCL generated. No intermediate representation. Just natural language to infrastructure.

AWS is positioning AI as the generation layer. Amazon Q Developer can create Terraform, CloudFormation, or CDK templates for any architecture requested. The output is still IaC. The input is now natural language.

And all of them, HashiCorp, Pulumi, and AWS, have shipped MCP servers that let AI agents interact with their IaC tools through a standardised protocol.

Three vendors, three different bets on the same question. Pulumi says the answer is general-purpose code. HashiCorp says the answer is a knowledge graph. Spacelift says the answer is skip the code entirely. AWS says the answer is AI-generated templates.

Where My Thinking Is Right

The broad thesis holds. If you look at where things are heading:

DSLs are structurally disadvantaged. LLMs are trained primarily on general-purpose languages. HCL has limited representation in training data. A study from Terrateam found that most AI models are not trained on production-grade Terraform since the majority of production Terraform projects are private. The TerraFormer paper (January 2026) documents that state-of-the-art LLMs “struggle with Terraform synthesis, often hallucinating resource types and attribute names.”

The authoring interface is changing. Whether it’s Pulumi Neo generating TypeScript, Q Developer generating CloudFormation, or Spacelift Intent bypassing templates entirely, the trend is clear: humans describe intent, machines produce infrastructure. The days of hand-writing HCL modules are numbered for most use cases.

The format shift is real and broader than IaC. The HTML-to-Markdown, Notion-to-Obsidian, GUI-to-CLI pattern is not a coincidence. It’s a structural response to a new primary consumer of information. When the reader is a language model with a finite context window, token efficiency matters. Every format that reduces tokens per unit of meaning wins.

Where My Thinking Is Flawed

Here’s where the thesis breaks down. And this matters, because the counterarguments are not trivial.

State management. This is the big one. When an AI agent calls the AWS API directly, where does the state live? Terraform tracks every resource it has created. It knows what exists, what has changed, and what needs to be destroyed. Raw API calls have no memory. An agent that provisions a VPC today has no way of knowing that VPC exists tomorrow unless something tracks it. Firefly’s analysis puts it well: “When an AI agent works with IaC instead of calling cloud APIs directly, the agent’s work becomes visible.”

Governance and auditability. Cloud API logs tell you what happened. IaC captures why it was intended. That distinction matters enormously for compliance, auditing, and incident investigation. Without IaC as an intermediary layer, governing autonomous infrastructure changes at scale becomes difficult.

Idempotency. Declarative IaC systems converge on the intended state. You can apply the same configuration ten times and get the same result. Imperative API calls provide no such guarantee. An agent that runs CreateSubnet twice creates two subnets. That is physics, not a tooling limitation.

Trust. AI agents hallucinate. The plan/apply cycle in Terraform is not just a workflow convenience. It’s a trust boundary. You see what will change before it changes. Remove that, and you’re giving an AI agent unconstrained write access to your production infrastructure. That’s not a tooling decision. That’s a risk management decision.

Rollback. Version-controlled IaC gives you rollback capability. API call history does not. When something goes wrong at 2 AM, “git revert” is a lot more reassuring than “ask the agent to undo what it did.”

The honest assessment: IaC tools are not dying. They’re becoming more essential as the constraint layer between agent intent and cloud execution. The more autonomous the agent, the more you need the guardrails.

What’s Actually Happening

The reality is more nuanced than either “IaC is dead” or “IaC is fine.” A two-tier model is emerging:

Production and mission-critical infrastructure: IaC with GitOps, plan/apply, human review. AI augments the authoring (generating modules, reviewing plans, detecting drift) but does not replace the governance workflow. This is not going to change for years.

Non-production, ephemeral, and development environments: Natural language provisioning, direct API calls, policy guardrails instead of manual review. Speed matters more than ceremony. Spacelift Intent lives here. Pulumi Neo in autonomous mode lives here.

The DSLs themselves are shifting from being human-authored to machine-generated. That’s the real structural change. HCL and CloudFormation templates are becoming the assembly language of infrastructure: still there, still essential, rarely hand-written. Humans describe intent. AI produces the intermediate representation. Automation applies it.

This mirrors what happened to actual assembly language. Nobody mourned the decline of hand-written x86. The abstraction survived even as the primary author changed.

And there’s a third possibility that HashiCorp is betting on with Project Infragraph: the intermediate representation shifts from text files to a knowledge graph. Instead of AI generating HCL that gets applied, AI reasons about a graph of infrastructure relationships and proposes changes at a higher level of abstraction. That’s a genuinely different architecture, and it’s worth watching.

The Filesystem-First Principle

The thread that ties all of this together is something I keep coming back to in my own work. I’ve been moving my personal knowledge management from Notion to Obsidian. Not because Obsidian has better features. Because Obsidian stores everything as plain files on a filesystem.

That sounds like a minor architectural decision. It’s not. It’s a fundamental choice about who can access your information.

When your data lives in Notion, the AI agent needs an API key, has to deal with rate limits, and receives data in a proprietary format. When your data lives as Markdown files in a directory, Claude Code can read it directly. No authentication. No transformation. No intermediary. The information is just there.

This is the same principle playing out at every level:

Websites adding llms.txt files alongside their HTML
Repos adding CLAUDE.md files alongside their README
Developers choosing CLI tools over GUIs
Infrastructure engineers choosing general-purpose code over DSLs

The common thread: reduce the distance between the AI agent and the information it needs. Every intermediary (an API, a proprietary format, a graphical interface, a domain-specific language) is friction. Some of that friction is valuable (governance, safety, auditability). Some of it is just legacy.

The skill is knowing which is which.

The Bigger Picture

We’re in a transitional period where every abstraction layer is being re-evaluated based on a new question: who is the primary consumer of this format?

HTML was designed for browsers. HCL was designed for human infrastructure engineers. YAML was designed for human readability. Notion’s data model was designed for human interaction. All of these formats optimised for the same audience.

That audience is changing. Not disappearing. Humans still need to review infrastructure plans, read documentation, and understand what their systems are doing. But the primary author, the entity doing most of the typing, is increasingly an AI agent.

The abstractions that survive will be the ones that serve both audiences: human-reviewable and machine-generatable. The ones that only served human authoring convenience (looking at you, CloudFormation JSON) will be the first to fall.

IaC is not dying. But the hand-written IaC era is ending. And if you’re still spending your days crafting HCL modules by hand, it’s worth asking the same question I asked myself: why am I writing this?

I hope someone else finds this useful.

Cheers.

Sources: