{"slug": "the-blast-radius-rule-for-ai-coding", "title": "The blast radius rule for AI coding", "summary": "A developer outlines a 'blast radius' rule for delegating coding tasks to AI agents, prioritizing reversibility over difficulty. The rule categorizes tasks into zones based on the cost of undoing changes, with repository-only changes fully delegated and external-facing configurations requiring human verification. The approach addresses common AI coding failures by focusing on silent failure modes and the need to verify deployed behavior against reality.", "body_md": "*Originally published on indiecore.net.*\n\nMy domain carries email as well as the website. When I moved this site to Cloudflare I sat\n\nlooking at the DNS panel for a good ten minutes before touching anything, because deleting\n\nthe wrong record there wouldn't break something I could see. It would break mail delivery:\n\nquietly, days later, for messages that no longer existed to resend.\n\nI have never once felt that way about a stylesheet.\n\nThat gap is what I use now to decide how much of a task an agent does on its own. Not how\n\nhard the task is, and not how much I trust the model. Just one question — how expensive is\n\nthis to undo after it ships?\n\nMy instinct was to hand over the tedious work and keep the interesting work. Boilerplate,\n\nconfig, CSS, build scripts, redirect maps: all yours. The \"real\" logic: mine.\n\nThat's backwards, and it took me an embarrassingly long time to see why. The tedious stuff is\n\ntedious *because it's plumbing*, and plumbing is precisely the part that touches things\n\noutside your repository — DNS, caches, crawlers, store metadata, ad configuration. Difficulty\n\nand consequence aren't correlated at all. Some of the most trivial edits in this project are\n\nthe ones I'd least like to get wrong.\n\nThere's a well-documented pattern now of projects that moved fast with AI for a few months\n\nand then hit a wall: features breaking other features, a codebase nobody understands, a\n\nrewrite costing more than the original build. Reading through those post-mortems, the thing\n\nthat struck me is that it isn't mainly a code-quality problem. It's a reversibility problem.\n\nYou don't hit a wall because the code is ugly. You hit it because too many changes went\n\nsomewhere you can't cheaply back out of.\n\nAnything that lives in the repo, renders into `dist/`\n\n, and can be reverted with `git revert`\n\nplus a redeploy. Page copy, styles, the generator, build scripts, blog posts, most refactors.\n\nThe agent works alone here. I describe what I want, it does it, CI checks it, I open the\n\npreview URL. If it's wrong it's wrong for about two and a half minutes (the length of a\n\ndeploy) and the fix is one command. At that price, reading every line is a worse use of my\n\nattention than occasionally fixing something.\n\nThis is the bulk of the work, and it's where all the speed comes from.\n\nThings that are technically in the repo but whose failure mode is silence. Cache headers,\n\nredirect maps, `robots.txt`\n\n, canonical URLs, structured data, the sitemap. Anything consumed\n\nby a crawler, a browser cache or a third party instead of by a person.\n\nReverting isn't the issue. Nothing tells you. The site looks perfect, and it goes on looking\n\nperfect for three weeks, until you notice traffic is off or a cache never invalidated or a\n\npage was never indexed at all.\n\nMy cache rules looked completely fine in the diff:\n\n```\n/assets/images/*\n  Cache-Control: public, max-age=31536000, immutable\n\n/assets/*\n  Cache-Control: public, max-age=86400\n```\n\nHere's what came back over the wire:\n\n```\ncache-control: public, max-age=86400, public, max-age=31536000, immutable\n```\n\nOverlapping rules concatenate. Browsers take the first value, so the year-long immutable\n\ncache did precisely nothing. Nobody reading that diff would flag it, human or model, because\n\nthe diff *is* fine. Only the response was wrong.\n\nSo the rule in Zone 2 isn't \"read more carefully.\" Reading was never going to find that. It's\n\nverify against reality: either the check goes into the build, which is\n\n[what I mostly do now](https://www.indiecore.net/blog/build-reviews-ai-code/), or I `curl`\n\nthe deployed thing and read\n\nwhat actually came back. \"The deploy succeeded\" and \"the new behaviour is live and correct\"\n\nare two different claims and only one of them is checkable.\n\nHere I don't delegate, and it isn't about competence. It's that I need to be the person who\n\ntyped it.\n\n`MX`\n\nand `TXT`\n\nare a category of their own.The common property isn't danger exactly. It's that `git revert`\n\ncan't fix it. If the undo\n\nisn't in version control, I do it by hand, slowly, with the docs open in another window.\n\nAn agent optimises for finishing the task you described, and it's genuinely good at that.\n\nWhat it can't weigh is what you'd lose if it's wrong, because that information isn't in the\n\nrepository and mostly isn't written down anywhere.\n\nNothing in my code says \"these five routes are referenced from live Play Store listings that\n\ntake days to update.\" They look like any other routes. When an agent renames one it isn't\n\nbeing reckless — it's being exactly as careful as the information it was handed.\n\nWhich points at the fix. Write the constraint into the repo, where the work happens. Mine\n\nsits near the top of the README in plain language:\n\nIt also hosts the privacy policy for every game.\n\nThose URLs are referenced from Google\n\nPlay Console listings — they must not break.\n\nI wrote that sentence for a future human. It happens to work just as well on an agent, which\n\nturned out to be a much bigger deal than I expected and is\n\n[a whole post of its own](https://www.indiecore.net/blog/context-engineering-repo/).\n\nThe real leverage isn't getting better at sorting. It's moving work *down* a zone until the\n\nsorting stops mattering.\n\n| Move | What it converts |\n|---|---|\nNever commit to `main` ; everything is a PR |\nproduction mistakes → preview-URL mistakes |\n| A preview deploy per branch | \"looks right in the diff\" → \"I loaded it\" |\n| Config in version control, not the dashboard | untracked drift → a reviewable diff |\n| Build-time checks for the silent stuff | Zone 2 → Zone 1 |\n| One deploy pipeline, not two | racing publishes → one gated publish |\n\nThat last row bit me. Cloudflare offers to connect your Git repository directly, and if\n\nyou're already deploying from GitHub Actions you quietly end up with two pipelines publishing\n\nthe same site: yours, which runs checks, and theirs, which doesn't. Whichever finishes last\n\nwins. A build my pipeline had correctly refused to ship could get published anyway. Two paths\n\nto production means your gate is advisory, and an advisory gate is decoration.\n\nEvery row there is dull infrastructure work. Together they're the reason it's reasonable to\n\nlet an agent write most of the code — not because the code got more trustworthy, but because\n\nbeing wrong got cheap.\n\nBefore handing something over I ask what it costs me if this ships broken and I find out in a\n\nweek. Two minutes and a revert, and I let it run without reading every line. Wouldn't find\n\nout in a week, and I stop and build a check instead, because reading doesn't catch silent\n\nfailures and never has. Undo isn't in git, and I do it myself; it's ten minutes, once, and\n\nit's the ten minutes that was actually worth my time.\n\nThe useful property of that rule is that it has nothing to do with how good the model is.\n\nIt's held up unchanged through three of them.\n\nOriginally published at ** The blast radius rule for AI coding**.", "url": "https://wpnews.pro/news/the-blast-radius-rule-for-ai-coding", "canonical_source": "https://dev.to/indiecoredev/the-blast-radius-rule-for-ai-coding-4a57", "published_at": "2026-09-01 22:34:35+00:00", "updated_at": "2026-09-01 23:23:22.763405+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-products"], "entities": ["Cloudflare", "indiecore.net"], "alternates": {"html": "https://wpnews.pro/news/the-blast-radius-rule-for-ai-coding", "markdown": "https://wpnews.pro/news/the-blast-radius-rule-for-ai-coding.md", "text": "https://wpnews.pro/news/the-blast-radius-rule-for-ai-coding.txt", "jsonld": "https://wpnews.pro/news/the-blast-radius-rule-for-ai-coding.jsonld"}}