Your Infrastructure Spec Already Moved Into Your Code

Yesterday, Evan You stood in front of a camera, announced that Vite+ is open source under MIT, and then did the "one more thing." Void. A deployment platform where your code is your infrastructure. void deploy scans your source, detects what you use — database, KV, queues, cron, auth, AI inference — and provisions it. No config files. No dashboard clicks. Built on Cloudflare.

The reaction was predictable. Half the room said finally. The other half said I'll never trust magic provisioning in production.

Both are right. And neither is asking the real question.

#The Spectrum

Every infrastructure tool exists on a single axis: how far is the spec from your application code?

The direction is unambiguous. The debate is about how fast to move.

#Why This Is Happening Now

Two forces are colliding.

AI agents need coupled context. To be fair: LLMs can generate decent Terraform. They can get most of the way there. And you can give an agent access to CLI tools — gcloud, aws cli — to inspect live configuration and validate it against the spec. It's not hopeless.

But here's the thing: your application code is coupled to your infrastructure. Your API needs that database, that queue, that KV store. The code won't work without them. Yet the spec that describes that infrastructure lives in a different file, maybe a different repo, written in a different language — HCL, YAML, CloudFormation JSON — with no compile-time check that the two agree. The coupling is real but the contract is informal. You don't find out they've drifted apart until deploy time, or worse, runtime.

YAML is the worst offender. It's not strongly typed. Terraform will catch syntax errors at plan before anything touches production — that part works. The dangerous failures are the ones that parse fine but mean the wrong thing. A misspelled key name is valid YAML. A missing environment variable is a valid ConfigMap. It deploys cleanly and breaks at runtime. No linter catches it because no linter knows what the key should be. That's why tools like Pulumi moved to real programming languages — TypeScript, Python, Go — where you get type checking, IDE support, and at least some compile-time guarantees. That was already the right instinct.

Pulumi got halfway there — real languages, real types. But you're still writing infrastructure about your application in a separate place. Encore and Void take the next step: infrastructure inside your application. new SQLDatabase("users") or import { KV } from "void" — the coupling becomes explicit. One codebase, one type system, one dependency graph. An agent isn't reasoning about two separate descriptions of the same system. It's reading the system itself. That's not a developer experience story. That's a leverage story.

Developer time is too expensive for a parallel mental model. A Terraform setup for a typical backend — database, Pub/Sub, cron — can run to hundreds of lines of HCL across multiple files. Someone has to understand, review, and update that code every time the application changes. For a five-person team without a dedicated DevOps engineer, that overhead competes directly with shipping product.

When your AI agent writes a feature that needs a new queue, and the queue requires a separate infrastructure PR with its own review cycle, you've created a serial bottleneck in what should be a parallel workflow. The infrastructure layer becomes a tax on the thing you actually care about: the product.

#The Layers Nobody Draws on the Same Whiteboard

Before I get further into this, I should name the thing I'm glossing over. That spectrum table above is really about provisioning — who creates the cloud resources. But provisioning is one of at least four distinct layers that are all collapsing simultaneously:

Each of these layers has its own ecosystem, its own debates, its own conferences. And each one is independently moving in the same direction: closer to the application code, further from standalone config.

At large companies, these layers get split across teams — a platform team for Terraform, SRE for ArgoCD, a build team for CI. I've never worked at a company like that. I've been at a small engineering team — ranging from just me to maybe a dozen — for twelve years. Which means I'm all three of those teams, and I feel the coordination tax every time I ship: I changed my application and now I have to update three separate systems to get it running.

The collapse isn't just about any single layer. It's about the gap between layers — the coordination cost of keeping provisioning, delivery, pipelines, and platform in sync with each other and with the application. Every time you add a queue to your app, you're touching Terraform and ArgoCD manifests and GitHub Actions workflows and maybe updating Backstage. The tools that are winning are the ones that eliminate the gap, not the ones that make any individual layer easier.

Void's bet is that all four layers collapse into one command — but only within Cloudflare's boundary. If your world fits on Workers, KV, D1, and Queues, you genuinely never touch another tool. The moment you need something outside that boundary — AWS RDS, GCP Pub/Sub, a managed Postgres that isn't D1 — you're back to Terraform for that piece, and the clean collapse gets messy. Encore collapses provisioning and delivery but deploys to your own AWS/GCP. SST collapses provisioning and pipelines on AWS. Each tool picks a different set of layers to absorb, and a different set of constraints to accept.

With that framing, the GitOps problem gets clearer.

#The GitOps Paradox

GitOps is specifically about the delivery layer — but it has a problem that bleeds into everything above and below it.

GitOps says: Git is the source of truth. You declare your desired state in YAML, commit it, and a reconciliation agent (ArgoCD, Flux) continuously syncs the cluster to match. Elegant in theory. In practice, it breaks in ways that look like success.

The failure mode is always the same: someone commits a change, the sync goes green, health checks pass, and production is broken. A typo in a ConfigMap key name. A missing environment variable. A canary annotation that got forgotten. The system synced perfectly to the wrong state. ArgoCD doesn't know the difference between "DATABASE_CONNECTION" and "DATABASE_CONECTION" — it just reconciles what you told it.

The deeper problem is the model itself. GitOps treats Git as the authoritative truth about what your infrastructure should be. But Git is an archive — it captures what someone intended at commit time. The actual truth is what's running in the cluster right now. And there's always a gap between the two. Configuration drift isn't a bug in GitOps. It's the fundamental physics: desired state and actual state are maintained in different systems, synchronized by a polling loop. The gap is structural.

For a human DevOps engineer, that gap is manageable. You build validation webhooks, OPA policies, canary rollouts, manual sync gates. You add layers of defense between the commit and the cluster.

For an AI agent? That gap is a cliff. The agent commits YAML to a repo and has no way to verify whether what it described is what actually happened. It can't read the cluster state. It can't interpret the difference between "synced successfully" and "synced successfully to a broken state." The GitOps model assumes a human in the loop who understands the semantics of the configuration, not just the syntax. When you replace that human with an agent, the semantic layer disappears.

This is why the spectrum is collapsing toward code. Not because GitOps is wrong — it was a genuine advance over SSH-and-pray. But because the gap between "what I declared" and "what's actually running" becomes more dangerous as agents do more of the declaring.

#The Lock-In Trap

OK — so the spectrum is collapsing. But toward what? Here's where I get skeptical.

The more implicit the tool, the faster the onramp — and the steeper the exit ramp. Void's zero-config is real. So is the fact that if you need to leave, you're rewriting your infrastructure layer from scratch. There is no void eject that hands you a Terraform state file.

Encore is more honest about this — it's open source, deploys to your own AWS/GCP account, and encore build docker gives you a portable image. But you're still using Encore's declarative patterns. The thin wrapper is still a wrapper.

The spectrum has a symmetry: explicitness is proportional to portability. Terraform is painful to write and trivial to migrate. Void is effortless to write and nearly impossible to migrate.

The right answer isn't maximum implicitness. It's ergonomic explicitness — keep the spec in code you own, make it simple enough that nobody reaches for the escape hatch.

For us, that looks like a thin TypeScript wrapper over our Wrangler bindings, a canonical wrangler.jsonc template, and a one-command bootstrap for new services. Not magical. Not zero-config. But legible to agents, portable between platforms, and ours.

#What Void Actually Showed Us

Void's real contribution isn't the product. It's the proof that the infrastructure-as-separate-codebase model is ending.

When the creator of Vue and Vite — someone who understands developer tooling at a level most of us can only squint at — looks at the landscape and says "the spec should live in the code," that's a directional signal. Not because Evan You is always right. Because the economics force the same conclusion from every angle:

• AI agents can't reason about YAML dashboards. They can reason about TypeScript.
• Small teams can't maintain two codebases. They need one.
• The feedback loop from "I need a queue" to "the queue exists" should be seconds, not a PR cycle.

The teams that win the next three years aren't the ones who picked the right tool. They're the ones whose infrastructure is most legible to their agents. Context-driven infrastructure isn't a developer ergonomics story. It's a leverage story. The same leverage story that's playing out in every layer of the stack right now.

#The Pattern

This is the same collapse that happened to build tooling a decade ago. Remember when you needed separate tools for compilation, bundling, minification, source maps, and hot reload? Then webpack absorbed them. Then Vite absorbed webpack's job and did it faster. Now Vite+ absorbs linting, formatting, and testing into a single binary. Each generation, the spec moves closer to the code and the boundary between "your application" and "the infrastructure it runs on" gets thinner.

Void is Evan You betting that deployment is the next thing to collapse into the application layer.

He's probably right about the direction. The question is whether you want to be on the platform that does the collapsing, or whether you'd rather steal the pattern and keep the keys.

I know which one I'd pick. But I've been burned by magic before. Twelve years of burned. The thing about scrap wood is you learn which glue holds and which glue looks like it holds.