By mid-2026 “vibe coding” isn’t a joke term for people who don’t read their own code anymore — it’s just how a lot of software gets written, including a fair amount of mine. I let an agent scaffold a FastAPI service, write the first pass of a React component, or draft a migration, and I review the output instead of typing every line myself. That’s a real productivity gain and I’m not interested in pretending otherwise.
Infrastructure is where I stopped applying that same level of trust, and it took a near-miss to figure out exactly where the line was. It isn’t “AI for app code, no AI for infra code” — that’s too blunt a rule and it throws away most of the value. The actual line is about two properties of the change, not about which layer of the stack it touches.
The two questions that actually matter
Is it reversible? A bad React component ships, someone notices the layout is broken, you fix it and redeploy. Total cost: minutes, and nobody’s data was at risk. A terraform apply that destroys and recreates a database is not reversible in the same sense — the fix isn’t “redeploy,” it’s “restore from backup and explain the gap.”
What’s the blast radius if it’s wrong? A broken unit test fails in CI and blocks a merge. A broken IAM policy silently opens something to the internet, or silently locks a service out of something it needs, and you may not find out which one happened until much later.
Put those two together and you get a rough grid, not a rule about which tool wrote the code:
Most infrastructure work lands in the top-left box by default, which is exactly why it’s the category where I slowed down after the Terraform incident I wrote up separately. State changes, IAM policies, anything touching production data, and destroy operations of any kind get read fully, not skimmed — regardless of whether a human or an agent produced the diff. The agent isn’t the risk factor. Irreversibility is.
Where AI assistants are still genuinely bad at infrastructure
Setting aside the reversibility question, there’s a narrower, more mechanical gap: AI coding agents don’t have a model of state. They’re extremely good at producing configuration that looks correct in isolation — valid HCL, a plausible Kubernetes manifest, a Dockerfile that builds. What they don’t reliably reason about is what already exists and how the change interacts with it: is this resource address already tracked somewhere else, does this port already have something bound to it, will this migration run against a table that already has rows in it.
That’s not a criticism specific to any one tool or model generation — it’s a structural gap. State lives outside the file the agent is editing, in a state file, a running cluster, a database. An agent reasoning about the diff in front of it is reasoning about intent; the system it’s about to touch is reasoning about history. Closing that gap is on the person running apply, not on better prompting.
The practical version of this rule
I don’t ask “did an AI write this” before deciding how carefully to review something. I ask “if this is wrong, how long does it take to notice, and how bad is it once I do.” Everything downstream of that answer — how carefully I read the diff, whether I run it in a scratch environment first, whether I want a prevent_destroy lifecycle block or a feature flag as a safety net — follows from blast radius and reversibility, not from provenance.
The productivity gain from AI-assisted coding is real and I’m keeping it. The discipline that has to sit next to it isn’t “trust it less,” it’s “know which category of change you’re looking at before you decide how much trust to extend.”