Two engineers vibe-code on a Friday afternoon.
The first one ships a dashboard widget. The AI wrote it, the demo looked right, they merged it. There's a bug: dates render wrong for timezones east of UTC. On Monday, a user in Singapore files a ticket, someone fixes it in ten minutes, and the world keeps turning.
The second one ships a Terraform module. The AI wrote it, the plan looked right, they applied it. There's a bug: the lifecycle rule on the S3 bucket is subtly wrong. Nothing happens Monday. Nothing happens for six weeks. Then a compliance audit asks for logs that were quietly expired after 7 days instead of 7 years, and now it's not a ticket, it's a meeting with legal.
Same workflow. Same model. Same "looks right, ship it" energy. Completely different physics. That difference is the whole argument of this post: vibe coding isn't a bad practice, it's a practice priced for the wrong blast radius.
I say this as a serial vibe coder
Let's get the hypocrisy check out of the way. I've shipped 86 browser tools that are almost entirely AI-written. I maintain a prompt library for vibe coding. When I finally audited those 86 tools adversarially, the AI found about 60 bugs in its own work: inverted SQL logic, dropped permission bits, biased password generation.
And it was still the right call to ship them the vibe-coded way. Because the failure cost was a wrong answer in a free browser tool, caught eventually, fixed in an afternoon. The expected value of speed exceeded the expected cost of bugs. That's not recklessness, that's correct pricing.
The problem is engineers running the same expected-value math with the wrong numbers when the artifact is infrastructure.
Application bugs decay. Infrastructure bugs compound.
Here's the asymmetry that changes the math:
| Property | App code bug | Infra code bug |
|---|---|---|
| Feedback loop | Fast: user sees it, ticket filed | Slow: silent for weeks, then catastrophic |
| Failure mode | Wrong pixels, wrong data on screen | Wrong permissions, wrong bills, data gone |
| Rollback | Redeploy previous version | Sometimes impossible (deleted data, leaked creds) |
| Cost curve | Flat: bug costs the same Monday or May | Compounding: NAT gateway misconfig bills every hour it exists |
| Who finds it | Your users | Your CFO, your auditor, or an attacker |
A frontend bug announces itself. An IAM wildcard does not. The s3:* on Resource: "*" that the AI helpfully generated to "make the error go away" will work perfectly, silently, indefinitely, right up until it's the finding in someone's incident report.
I've now audited enough AI-assisted teams to see the pattern repeatedly: in the 12-team audit, the five-figure leaks weren't in application logic. They were in the config and infrastructure layers, where "it applied cleanly" gets mistaken for "it's correct."
And the models make this worse, not better, in one specific way: AI-generated infra code is fluent. It's well-formatted, sensibly commented, and passes terraform validate. Every surface signal that a human reviewer uses as a proxy for "someone careful wrote this" is present. The care is not.
The fix isn't slowing down. It's a permission boundary for vibes.
The standard take here is "always review AI infrastructure code carefully," which is true and useless, like "always read the terms and conditions." Careful review doesn't survive contact with a Friday backlog. What survives is structure. Three pieces:
1. Draw the vibe line explicitly. Decide, as policy, what may be vibe-coded and what may not. My line: anything stateless and rollbackable qualifies (UI, scripts, dashboards, dev tooling). Anything touching IAM, networking, data lifecycle, or billing does not, no matter how trivial the diff looks. A one-line security group change is not a one-line risk.
2. Make the machine review the machine. Human attention is the scarcest resource in your pipeline; spend it last, not first. Run an adversarial agent pass over infra diffs with the instruction "prove this is broken," which yields dramatically more than "check this". Then policy scanners (tfsec, checkov, OPA). Then a human, reading a pre-annotated diff instead of raw HCL.
3. Put the guardrails where probabilism can't reach them. The mistakes that must never happen can't be prevented by prompts, because prompts are suggestions to a probabilistic system. They're prevented by deterministic checks that fire every time: hooks that block destructive commands, plan gates that require approval on any destroy, budget alarms that page before the bill compounds. The $47K near-miss on my watch was caught by a 30-line hook, not by anyone's vigilance.
Notice none of this says "don't use AI for infrastructure." I use it daily; most of my automation is AI-built. The claim is narrower: the vibe workflow, where plausibility substitutes for verification, is priced for blast radii the size of a widget. Infrastructure needs the grown-up workflow: same AI, same speed on the draft, plus boundaries that don't depend on anyone feeling careful that day.
The one-sentence policy
If a bad merge means a bad pixel, vibe away. If a bad merge means a bad bill, a breach, or a 3 AM page, the vibes need a permission model.
Your dashboard widget can be wrong for a weekend. Your S3 lifecycle rule can't.