{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3zfkrfv7xc4iitazbcagopngvkxkufjuxnmo75wbv6yw4rbfi2i",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3movnhapz32i2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreic52rzqhh3lt44m3uj7xrocs75mbxjfq4zfl7425s3xyyb7y7h5ui"
    },
    "mimeType": "image/webp",
    "size": 69056
  },
  "path": "/jjoyneriv/vibe-coded-infrastructure-how-to-ship-fast-without-torching-production-3l83",
  "publishedAt": "2026-06-22T19:05:48.000Z",
  "site": "https://dev.to",
  "tags": [
    "vibecoding",
    "devops",
    "ai",
    "productivity",
    "parsing a Terraform plan for AI-assisted review",
    "catching risky shell commands before they run",
    "hardening a bash script with strict mode, traps, and back-out paths",
    "building an AI ops copilot with guardrails",
    "searchable prompt library",
    "devopsaitoolkit.com",
    "start-here tour",
    "fixed-price infrastructure audits"
  ],
  "textContent": "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.\n\nIt's also how you accidentally `terraform destroy` a production VPC at 2 p.m. on a Tuesday.\n\nI 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.\n\n##  Vibe coding is great at drafts and terrible at consequences\n\nThe 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.\n\nThe 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.\n\n##  Rule 1: Vibe the draft, never the apply\n\nThe 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.\n\nConcretely, that means I demand a plan I can read before anything touches a real system:\n\n\n\n    terraform plan -out=tfplan\n    terraform show -json tfplan | <paste into the model>\n\n\n> \"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.\"\n\nThat `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.**\n\n##  Rule 2: Make destructive commands earn a second look\n\nVibe-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:\n\n> \"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).\"\n\nThis 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.\n\n##  Rule 3: Stage everything the vibe touched\n\nVibe 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:\n\n  * **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.\n  * **Smallest blast radius.** Apply to one node, one namespace, one non-prod env. Watch it. Then widen.\n  * **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.\n\n\n\nNone of this slows the vibe down much. It just moves the \"oh no\" moment from production to a terminal where it's free.\n\n##  Rule 4: Vibe-code the toil, hand-hold the crown jewels\n\nNot 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.\n\nMatch 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.)\n\n##  Rule 5: Keep a prompt library so your vibes are reproducible\n\nThe 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.\n\nI 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.\n\n##  The honest takeaway\n\nVibe 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.\n\nSo: 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.\n\n_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._",
  "title": "Vibe-Coded Infrastructure: How to Ship Fast Without Torching Production"
}