You described what you wanted in plain English, the model wrote the Terraform, you ran apply, and it worked. No docs, no Stack Overflow, no fighting HCL syntax for an hour. That's vibe coding — building by describing intent and riding the model's output — and for infrastructure it is genuinely, addictively fast.
It's also how you accidentally terraform destroy a production VPC at 2 p.m. on a Tuesday.
I run production OpenStack, Kubernetes, and Terraform for a living, and I vibe-code a lot of it now. Here's the honest version of how to keep the speed without the smoking crater — the rules I actually follow.
Vibe coding is great at drafts and terrible at consequences
The thing a model is brilliant at is turning "I need a rate-limited NGINX reverse proxy in front of this service" into 40 lines of config in two seconds. The thing it has no idea about is that this service shares an upstream with the billing API, that your last outage came from exactly this kind of change, and that the "harmless" reload will drop in-flight connections during your peak hour.
The model writes code. It does not carry the consequences. You do. So the entire game of vibe-coding infrastructure safely is keeping the human on the hook for the blast radius while letting the machine do the typing.
Rule 1: Vibe the draft, never the apply
The single most important habit: the AI is allowed to propose changes. It is never allowed to make them. There's a world of difference between "here's the kubectl patch you'd run" and a bot that runs it for you.
Concretely, that means I demand a plan I can read before anything touches a real system:
terraform plan -out=tfplan
terraform show -json tfplan | <paste into the model>
"Read this plan. Tell me in plain English what changes, flag anything that destroys or replaces a resource, and rank the three riskiest changes. Don't tell me it's fine — tell me what could go wrong."
That force-replace buried on line 200 is exactly the thing vibe-coding glosses over and a careful read catches. I wrote up the full version of this — , and another for that proposes and never silently acts.)
Rule 5: Keep a prompt library so your vibes are reproducible
The dirty secret of good vibe coding is that it's not actually vibes — it's good prompts. A throwaway "fix my nginx config" gets you a throwaway answer. A prompt that says "act as a senior SRE, here's my config and the error, give me ranked causes and the nginx -t to verify before I reload" gets you something you can trust.
I keep the ones that work in a . New there? The .
SOCIAL SHARE CARD GENERATOR