AWS Is Not Simpler. Agents Just Got Better at Reading It.

A developer argues that as AI agents improve at reading complex infrastructure, explicit infrastructure-as-code becomes more valuable than black-box abstractions. Comparing Terraform on AWS versus Cloudflare, the developer finds that AWS's more detailed provider schema gives agents richer context to understand the operational contract, even though AWS is not simpler to set up. The developer notes Cloudflare's alternative approach of intent-based, framework-native provisioning but concludes that for agent-driven development, explicit infrastructure like AWS provides higher-signal context.

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. | 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. 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 | wrangler.json , Worker code, D1 migrations, package.json , framework conventionsThe 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. 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 https://www.cloudflare.com/press/press-releases/2026/cloudflare-acquires-voidzero-to-build-the-future-of-the-ai-native-web/ 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. 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. | | 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. 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.