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 — parsing a Terraform plan for AI-assisted review — but the one-liner is: the model reads the plan; you approve the apply.

Rule 2: Make destructive commands earn a second look

Vibe-coded shell scripts are where people get hurt fastest, because bash will cheerfully rm -rf "$DIR/" when $DIR is empty. Before I run anything a model handed me, it goes through a risk pass:

"Scan this script for anything destructive or irreversible — deletes, overwrites, force-pushes, drops, prod credentials. For each, tell me the blast radius and a safer version (dry-run flag, confirmation prompt, backup first)."

This catches the stuff vibe energy skips: missing set -euo pipefail, an unquoted variable that word-splits, a kubectl delete with no namespace scoping. I keep a whole pattern for catching risky shell commands before they run, and another for hardening a bash script with strict mode, traps, and back-out paths. Vibe-code the first draft; harden it before it runs once.

Rule 3: Stage everything the vibe touched

Vibe coding tempts you to skip the boring safety rails because the loop feels so fast. Don't. The fast loop needs the rails or it's just a faster way to break things:

• Dry-run first. --dry-run=server, terraform plan, ansible --check. If the tool has a no-op mode, the vibe-coded change runs there first, every time.
• Smallest blast radius. Apply to one node, one namespace, one non-prod env. Watch it. Then widen.
• Back-out before apply. If you can't answer "how do I undo this in 60 seconds," you're not ready to apply it — no matter how confident the model sounded.

None of this slows the vibe down much. It just moves the "oh no" moment from production to a terminal where it's free.

Rule 4: Vibe-code the toil, hand-hold the crown jewels

Not all infrastructure is equal. I'll vibe-code a Grafana dashboard, a CI lint job, a one-off migration script, or a dev-env bootstrap with barely a glance — the downside is a wasted ten minutes. I will not vibe-code an IAM policy change, a database failover, a network ACL, or anything in the path of customer money without reading every line like it's a hostile PR.

Match your scrutiny to the blast radius. The model doesn't know which is which; you do. (If you're standing up an AI helper that runs alongside real systems, the same principle scales — I wrote about building an AI ops copilot with guardrails 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 searchable prompt library — filterable by stack, difficulty, and whether they include production-safety guidance — so the next time I vibe-code a Postgres index or a Kubernetes rollout, I'm starting from a prompt that already bakes in the guardrails. Reproducible vibes beat lucky ones.

The honest takeaway

Vibe coding isn't the enemy of careful engineering — it's a power tool, and power tools are exactly as safe as the operator. Used well, you draft in seconds and spend your real attention on the 5% that can actually hurt you. Used badly, you ship confident nonsense at machine speed.

So: vibe the draft, read the plan, stage the apply, scope the blast radius, and keep a human's name on the change ticket. Do that and "vibe-coded" stops being a confession and starts being a workflow.

I write about running AI alongside real production infrastructure at devopsaitoolkit.com. New there? The start-here tour has the free toolkit and the incident assistant. And if your production is painful enough that vibe-coding won't fix it, I do fixed-price infrastructure audits.