Why Your AI Can't Handle Infrastructure Decisions (And What You Should Do About It)

Why Your AI Can't Handle Infrastructure Decisions (And What You Should Do About It)

May 25, 2026 infrastructure-as-code terraform ai-development devops cloud-architecture application-design vibe-coding

Why Your AI Can't Handle Infrastructure Decisions (And What You Should Do About It)

You've probably seen the hype: "Let the AI write your code." And honestly? For application logic, it works remarkably well. Route handlers, database queries, utility functions—these are areas where large language models genuinely shine. But there's a critical blind spot that nobody talks about enough.

The moment you hand your AI model a Terraform file, everything falls apart.

The Infrastructure Context Problem

Here's the uncomfortable truth: AI models are fantastic at syntax. They'll write valid HCL all day long. The problem isn't the code—it's the reasoning behind the code.

Consider a simple scenario: you ask your AI agent to add a new event to your messaging system. Maybe it's an order-created event that needs to be published through SNS and queued in SQS. The model dutifully generates:

  • SNS topic
  • SQS queue with dead-letter queue
  • Topic subscription
  • IAM policies scoped to the publishing service

Looks good, right? Except every single number and scope decision in that configuration is a shot in the dark. Should the visibility timeout be 60 seconds or 600? Should that IAM policy be scoped to a specific bucket or use wildcards? Should message retention be 14 days or the default?

The AI model picks values that "looked right" in its training data, with zero understanding of your actual workload, your team's operational patterns, or last quarter's incident where someone got bit by a replay window.

The Hidden Cost of Code Review

Here's what really stings: the code review burden doesn't shrink. It explodes.

Reviewing application code is relatively straightforward. You're checking logic, testing edge cases, maybe auditing for security issues. But reviewing auto-generated infrastructure? That's now cross-checking:

  • HCL syntax against AWS IAM semantics
  • Your proposed resources against existing pipeline architecture
  • Team conventions and tacit knowledge that was never written down
  • Whether the consuming service's role even exists in this account

The reviewer becomes a human compiler, carrying all the context the AI couldn't see. And when something ships wrong—wrong timeout, wrong scope, wrong retention policy—your pager goes off at 3 AM, not your CI pipeline.

The Real Problem: Separated Concerns

The gap isn't actually a tooling problem. You could layer custom modules, service catalogs, and policy validators around your AI agent indefinitely. None of it closes the gap because the gap's root cause is architectural.

Your application code and infrastructure code live in separate repos with separate review cycles. The AI makes infrastructure decisions isolated from the application logic they'll actually support. The context needed to make those decisions correctly simply doesn't exist in the file being edited.

More tooling just adds more bureaucracy to a broken system.

The Better Approach: Infrastructure as a Compile-Time Problem

What if infrastructure wasn't a separate concern at all?

Imagine this: instead of writing application code that vaguely hints at what infrastructure you need, you declare your infrastructure as part of your typed application code. The framework handles the rest—provisioning, IAM scoping, dead-letter queues, subscriptions, all derived from what the typed code actually needs.

Now a pub/sub topic declaration looks like this:

export const orderCreated = new Topic<OrderCreatedEvent>("order-created", {
  deliveryGuarantee: "at-least-once",
});

No separate HCL file. No hand-audited IAM policy. No guessing at timeout values. The framework knows exactly what this topic needs because it can see the application code consuming and producing it. The dangerous infrastructure decisions move from "something an AI agent made blindly" to "something the framework computed deterministically based on declared types."

Your PR is now a single TypeScript diff instead of a TypeScript diff plus fifty lines of Terraform plus policies you need to manually verify.

Why This Matters for Vibe Coding

This is the crux of why "vibe coding your infrastructure" requires a fundamentally different architecture than vibe coding your application. You can safely delegate application logic to an AI when the code is typed, tested, and isolated. But infrastructure decisions require context that lives elsewhere in your system.

The solution isn't better AI prompts or more sophisticated tooling. It's removing the seam between application and infrastructure entirely. When your framework compiles infrastructure from your application code rather than alongside it, the dangerous decisions move out of the hands of your AI agent—and out of the hands of code reviewers playing human compiler at midnight.

That's infrastructure you can actually vibe code with confidence.

Read in other languages:

RU BG EL CS UZ TR SV FI RO PT PL NB NL HU IT FR ES DE DA ZH-HANS