# The blast radius rule for AI coding > Source: > Published: 2026-09-01 22:34:35+00:00 *Originally published on indiecore.net.* My domain carries email as well as the website. When I moved this site to Cloudflare I sat looking at the DNS panel for a good ten minutes before touching anything, because deleting the wrong record there wouldn't break something I could see. It would break mail delivery: quietly, days later, for messages that no longer existed to resend. I have never once felt that way about a stylesheet. That gap is what I use now to decide how much of a task an agent does on its own. Not how hard the task is, and not how much I trust the model. Just one question — how expensive is this to undo after it ships? My instinct was to hand over the tedious work and keep the interesting work. Boilerplate, config, CSS, build scripts, redirect maps: all yours. The "real" logic: mine. That's backwards, and it took me an embarrassingly long time to see why. The tedious stuff is tedious *because it's plumbing*, and plumbing is precisely the part that touches things outside your repository — DNS, caches, crawlers, store metadata, ad configuration. Difficulty and consequence aren't correlated at all. Some of the most trivial edits in this project are the ones I'd least like to get wrong. There's a well-documented pattern now of projects that moved fast with AI for a few months and then hit a wall: features breaking other features, a codebase nobody understands, a rewrite costing more than the original build. Reading through those post-mortems, the thing that struck me is that it isn't mainly a code-quality problem. It's a reversibility problem. You don't hit a wall because the code is ugly. You hit it because too many changes went somewhere you can't cheaply back out of. Anything that lives in the repo, renders into `dist/` , and can be reverted with `git revert` plus a redeploy. Page copy, styles, the generator, build scripts, blog posts, most refactors. The agent works alone here. I describe what I want, it does it, CI checks it, I open the preview URL. If it's wrong it's wrong for about two and a half minutes (the length of a deploy) and the fix is one command. At that price, reading every line is a worse use of my attention than occasionally fixing something. This is the bulk of the work, and it's where all the speed comes from. Things that are technically in the repo but whose failure mode is silence. Cache headers, redirect maps, `robots.txt` , canonical URLs, structured data, the sitemap. Anything consumed by a crawler, a browser cache or a third party instead of by a person. Reverting isn't the issue. Nothing tells you. The site looks perfect, and it goes on looking perfect for three weeks, until you notice traffic is off or a cache never invalidated or a page was never indexed at all. My cache rules looked completely fine in the diff: ``` /assets/images/* Cache-Control: public, max-age=31536000, immutable /assets/* Cache-Control: public, max-age=86400 ``` Here's what came back over the wire: ``` cache-control: public, max-age=86400, public, max-age=31536000, immutable ``` Overlapping rules concatenate. Browsers take the first value, so the year-long immutable cache did precisely nothing. Nobody reading that diff would flag it, human or model, because the diff *is* fine. Only the response was wrong. So the rule in Zone 2 isn't "read more carefully." Reading was never going to find that. It's verify against reality: either the check goes into the build, which is [what I mostly do now](https://www.indiecore.net/blog/build-reviews-ai-code/), or I `curl` the deployed thing and read what actually came back. "The deploy succeeded" and "the new behaviour is live and correct" are two different claims and only one of them is checkable. Here I don't delegate, and it isn't about competence. It's that I need to be the person who typed it. `MX` and `TXT` are a category of their own.The common property isn't danger exactly. It's that `git revert` can't fix it. If the undo isn't in version control, I do it by hand, slowly, with the docs open in another window. An agent optimises for finishing the task you described, and it's genuinely good at that. What it can't weigh is what you'd lose if it's wrong, because that information isn't in the repository and mostly isn't written down anywhere. Nothing in my code says "these five routes are referenced from live Play Store listings that take days to update." They look like any other routes. When an agent renames one it isn't being reckless — it's being exactly as careful as the information it was handed. Which points at the fix. Write the constraint into the repo, where the work happens. Mine sits near the top of the README in plain language: It also hosts the privacy policy for every game. Those URLs are referenced from Google Play Console listings — they must not break. I wrote that sentence for a future human. It happens to work just as well on an agent, which turned out to be a much bigger deal than I expected and is [a whole post of its own](https://www.indiecore.net/blog/context-engineering-repo/). The real leverage isn't getting better at sorting. It's moving work *down* a zone until the sorting stops mattering. | Move | What it converts | |---|---| Never commit to `main` ; everything is a PR | production mistakes → preview-URL mistakes | | A preview deploy per branch | "looks right in the diff" → "I loaded it" | | Config in version control, not the dashboard | untracked drift → a reviewable diff | | Build-time checks for the silent stuff | Zone 2 → Zone 1 | | One deploy pipeline, not two | racing publishes → one gated publish | That last row bit me. Cloudflare offers to connect your Git repository directly, and if you're already deploying from GitHub Actions you quietly end up with two pipelines publishing the same site: yours, which runs checks, and theirs, which doesn't. Whichever finishes last wins. A build my pipeline had correctly refused to ship could get published anyway. Two paths to production means your gate is advisory, and an advisory gate is decoration. Every row there is dull infrastructure work. Together they're the reason it's reasonable to let an agent write most of the code — not because the code got more trustworthy, but because being wrong got cheap. Before handing something over I ask what it costs me if this ships broken and I find out in a week. Two minutes and a revert, and I let it run without reading every line. Wouldn't find out in a week, and I stop and build a check instead, because reading doesn't catch silent failures and never has. Undo isn't in git, and I do it myself; it's ten minutes, once, and it's the ten minutes that was actually worth my time. The useful property of that rule is that it has nothing to do with how good the model is. It's held up unchanged through three of them. Originally published at ** The blast radius rule for AI coding**.