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, 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
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**.