I optimized my architecture for the wrong model.
I used to think black-box infrastructure was the right abstraction for AI-driven development.
Vercel, Supabase, Cloudflare Workers — a sharp contract in front, a managed backend behind — felt like the obvious fit. The less an agent had to reason about, the fewer places it could get lost. Give it a clean interface, hide the messy backend, move fast.
I still think that was right for the agents we had last year. I don't think it's right for the agents we're starting to use now.
The shift is not that AWS got simpler. It didn't. Setup still takes longer, CI/CD takes more work to wire, and cost control has real limits. The shift is that agents got better at reading complexity — and once an agent can actually use a large structured context, the things I treated as overhead (resources, provider schemas, IAM policies, explicit queues, explicit alarms, explicit networks) become the highest-signal context I can hand it.
To keep this concrete, I'm holding the tool constant. This is HCL/Terraform on AWS vs HCL/Terraform on Cloudflare — same language, same workflow, two providers.
The inversion
| Agents are… | Best served by… |
|---|---|
| Context-poor (last year's loops) | Black boxes — shrink the surface, hide the backend |
| Context-rich (now) | Inspectable systems — describe everything as code |
The one-line version:
The better agents get at reading, the more valuable explicit infrastructure becomes.
I didn't become more pro-AWS because AWS got easier. I became more pro-AWS because agents got better at reading it.
Same Terraform, two providers
The interesting comparison isn't AWS-elegance vs Cloudflare-elegance. It's how much of the infrastructure topology and operational contract an agent can reconstruct from the HCL plus the provider schema alone.
| Terraform × AWS | Terraform × Cloudflare | |
|---|---|---|
| Provider maturity | AWS provider is about as battle-tested as IaC gets; enormous public corpus of modules/examples | v5 is a ground-up, OpenAPI-generated rewrite — improving fast, but breaking and still stabilizing on a short cadence |
| Schema faithfulness | AWSCC is auto-generated from the CloudFormation resource schema, so it tracks CloudFormation coverage closely and picks up new services fast | Generated from OpenAPI; solid for resources, but Workers abstractions sit above what HCL expresses |
| What's visible in HCL + schema | Most of the infra topology and operational contract — queues, roles, permissions, schedules, alarms, networks, data-plane wiring | That a binding exists — but its behavior lives in wrangler.json, Worker code, D1 migrations, package.json, framework conventions |
| Infra shape reconstructable from HCL? | Infra shape: largely yes. App semantics: no. | Infra shape: only partially. App semantics live elsewhere. |
| Terse-prompt tolerance | High — common patterns are well-represented | High for small stacks; drops once Workers + D1/R2/KV/DO/Queues/bindings interact |
The Cloudflare row isn't a knock — it's the crux. A Terraform file can tell an agent that a binding exists. It can't, by itself, explain how that binding is used, where responsibility sits between Worker code and storage, how migrations relate to runtime behavior, or which framework conventions are doing invisible work. With AWS-via-Terraform, far more of the infrastructure topology and operational contract is visible through the same artifact: queues, permissions, schedules, alarms, networks, roles, policies, data-plane wiring. The application still matters — Lambda code, migrations, and API specs are not in the HCL either — but the infra shape is less hidden from the agent. That's not because AWS is simpler; it's because AWS puts more of the operational contract into the same inspectable artifact.
Cloudflare is a different bet, not the wrong one
Workers, D1, R2, KV, Durable Objects, Queues, and framework-native deploy form a genuinely coherent platform. For cost, speed, and operational lightness it's one of the best balances available, and I reach for it happily.
It just isn't optimized around the same kind of explicitness. Cloudflare is improving Terraform — v5 is a real, OpenAPI-generated step up in coverage and API alignment — but its more interesting strategic move is elsewhere: intent-based, framework-native provisioning (VoidZero/Vite, Astro), where you read intent from the framework and provision the infra. In its VoidZero acquisition framing, Cloudflare describes a future where a single Vite deploy command detects an app's need for a database or object store and provisions resources like D1 or R2 with no manual dashboard step. That's a coherent future. It's simply a different bet from "everything explicit as code," and it's why HCL-on-Cloudflare underdetermines the system today. Evaluate Cloudflare as framework-native infra, not as Terraform that happens to target the edge.
The safety boundary (this is not "walk away")
Inspectable substrate is half the story. The other half is a loop that closes correctness with plan, policy, and tests — not with the model's confidence. Two Terraform-specific studies make the same point: surface success is not the same as being correct.
| Looks like success | What actually happened | Study |
|---|---|---|
| Structured schema knowledge made the model a much better coder | Baseline overall success was 27.1%; with injection, technical validation reached 75.3% and overall success 62.6% — but intent alignment plateaued, the "Correctness–Congruence Gap." Valid HCL ≠ the infra you asked for. | Nekrasov et al., 2025 |
| One-shot security "fixes" made the flagged issue disappear 83% of the time | Only 10% were actually clean, and 57–71% were deceptive fixes — the scanner went green, the hole stayed open. | TerraProbe — Alsaid et al., 2026 |
TerraProbe in particular was run the way you shouldn't ship: first-pass, minimally-prompted repairs, not a high-context, closed-loop workflow. That's the point — it's evidence for the loop, not against agents. Nekrasov et al. make the complementary case: even when structured knowledge improves validity, valid HCL still isn't the same as the infra you intended. A green check is not proof. So the substrate feeds a closed loop:
| # | Stage | On failure |
|---|---|---|
| 1 | NL request | — |
| 2 | Pull provider schema + module docs (via MCP) | — |
| 3 | Generate HCL | — |
| 4 |
fmt / validate / plan
|
plan diff → back to 3 |
| 5 | Policy scan — Checkov / tfsec / OPA / Conftest | violation → back to 3 |
| 6 | Cost estimate | — |
| 7 | Smoke test in an ephemeral env | — |
| 8 | Apply — with human review | — |
The loop is the point: a plan diff or a failed policy check routes back to regeneration, never forward to apply.
Pulumi is the interesting exception here: it keeps most of the AWS schema substrate (its providers are bridged from the same Terraform providers) but swaps HCL for a real language — so the agent gets the compiler and type system as an extra oracle. The risk is the mirror image of the power: real languages also let agents get clever, so you lean harder on preview, policy-as-code, and tests to keep it declarative in spirit.
Why this isn't an AWS victory lap
I'm not returning to AWS because it's lighter. It isn't. Environment setup takes longer, CI/CD takes more work, cost control is harder than on a tightly scoped platform, and there's more surface area — more IAM, more policy, more wiring, more ways to be wrong.
But that surface area is also more explicit. For human-only development, the explicitness often felt like drag. For AI-driven development, it increasingly feels like leverage. The infrastructure I used to hide from the model is becoming the infrastructure the model needs to read.
That's the real shift.
Cloudflare may still win the intent-native path. Vercel and Supabase may still be the right answer when the contract is small and the backend should stay out of sight. But for enterprise requirements, complex systems, and agents that need to make grounded changes across infra and application code, HCL-on-AWS is hard to beat — not because it's elegant, but because it leaves more of the system inspectable as code.
Opaque platforms were useful when agents were context-bound. Explicit infrastructure becomes useful when agents are context-rich. We're crossing that line now.
If you've made the opposite call — betting on intent-native, framework-first infra for agentic dev — I'd like to hear how it's holding up. That's the fork I'm least sure about.
Top comments (0)