Loading today’s stories
Build1 distinct publisher3 min readPublished
One developer's cache-header diff read perfectly and still shipped a dead year-long cache, which is the argument for granting agents autonomy only where git revert plus a redeploy is the whole undo path.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
GitHub Pages cannot send a single security header, so every Pages site starts at zero1 distinct publisher
build
The git part is not the part doing the work: JSONL ledgers as an agent's state layer1 distinct publisher
build
Split Flutter CI from CD, or pay macOS rates on every pull request1 distinct publisher
build
The AI-training bans live on the big infrastructure blogs, not the small publications1 distinct publisher
Start with the header, because it is the part that generalises cleanly. Two cache rules: `/assets/images/*` at `max-age=31536000` with `immutable`, and `/assets/*` at `max-age=86400` [7]. What came back over the wire was both of them concatenated into one field, the day-long value first [8]. Browsers take the first value, so the year-long immutable cache did precisely nothing [9]. Say the arithmetic out loud: 31536000 divided by 86400 is 365, so every image asset was eligible for revalidation 365 times more often than intended [20].
No review catches that. The diff is correct, and the author's point is that neither a human nor a model reading it would flag anything, because only the response was wrong [10]. So his rule for that zone is not read more carefully, it is verify against reality: put the assertion in the build, or `curl` the deployed thing, on the grounds that "the deploy succeeded" and "the new behaviour is live and correct" are two different claims and only one of them is checkable [11].
Detection latency is what makes that zone expensive. He describes the silent window as three weeks of a site that looks perfect while traffic drifts or a page was never indexed [19]. Against a deploy that makes a bad change wrong for about two and a half minutes [5], that is roughly 12,000 times longer before anyone knows [21]. The code was identical in both cases; only the consumer of it changed.
Treat the zone map as a claim about his workload, not yours. It holds because the artifact is a static `dist/` that `git revert` plus a redeploy fully restores [4], and because the redeploy is 150 seconds [5]. For a service with a database, the same boundary needs an undo path that covers schema state, outbound mail, and anything a third party has already fetched, and `git revert` covers none of those. In my context that is enough to push migrations into his no-delegation zone even though they live in the repo.
The property he lands on for that zone is that `git revert` cannot fix it, not that it is inherently dangerous [15]. DNS is the clean case, with `MX` and `TXT` in a category of their own [12], because a wrong record breaks mail delivery quietly, days later, for messages that no longer exist to resend [16]. Play Console is the costly one: once a listing or data safety declaration is in production, a wrong answer is a policy problem rather than a bug, and the round trip is measured in days [13]. The privacy policy URL for each of his games sits inside a store listing he does not control, so it gets a 301 and a permanent build check [14]. Treating the word "delete" in a dashboard as a stop sign [12] is cruder than any permission model, and it probably has the better false-negative rate.
The reframing I would argue with least is his read of the post-mortems: projects that moved fast with AI and then hit a wall of features breaking features and rewrites costing more than the build failed on reversibility, not on code quality [17]. That is testable per change class. Name the command that undoes it, and name the signal that tells you it needs undoing. Where both exist, the agent can run to completion, and he is explicit that this is where the speed comes from [18]. Where the second is missing, reading the diff will not supply it.
Ranked by verification strength, evidence, and original report placement.
The author decides how much of a task an agent does on its own by asking how expensive the change is to undo after it ships, rather than how hard the task is or how much he trusts the model.
His instinct had been to hand the agent the tedious work (boilerplate, config, CSS, build scripts, redirect maps) and keep the 'real' logic himself; he now says that split is backwards.
The tedious work is plumbing, and plumbing is the part that touches things outside the repository: DNS, caches, crawlers, store metadata, ad configuration. Difficulty and consequence are not correlated.
Zone 1 is 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, CI checks it, and he opens the preview URL.
If a Zone 1 change is wrong, it is wrong for about two and a half minutes, the length of a deploy, and the fix is one command.
Zone 2 is work technically in the repo whose failure mode is silence: cache headers, redirect maps, robots.txt, canonical URLs, structured data, the sitemap, and anything consumed by a crawler, a browser cache or a third party rather than a person.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · September 1, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One first-person log, one quotable artifact
The centre of this story is checkable by anyone: the two cache rules and the concatenated header they produced are quoted character for character, and the arithmetic that turns a year-long cache into a one-day cache needs no trust. Everything surrounding it — the zones, the two-and-a-half-minute deploy, the days-long Play Console round trip — is one developer's recollection of his own project, and the 'well-documented pattern' of AI projects hitting a wall is invoked without a single named post-mortem.
One repo, one owner
The practice described is running in exactly one place: the author's static site and the handful of Play Store games it hosts privacy policies for. He reports having moved his Zone 2 checks into the build and having hand-typed the DNS migration, so this is lived practice rather than a proposal — but there is no second team, no tooling anyone else can adopt, and no count of changes shipped under the policy.
Restrained prose, over-precise numbers
The writing is unusually careful about its own limits — no claimed productivity gain, no vendor to sell, an explicit admission that the sorting scheme matters less than shrinking the need for it. The stretch is numerical: 365 times more revalidation is real arithmetic on quoted values, but the 12,000-fold gap between a three-week silence and a 150-second deploy dresses a rhetorical 'three weeks' as a measurement. A one-repo policy is also offered as a general rule for delegating to agents.
Own blog, own games, one teaser
The piece is republished from the author's own site, mentions his Play Store games in passing, and dangles a follow-up post about writing constraints into the README. That is the ordinary self-interest of an indie developer building an audience — no sponsor, no product being sold, and the story's least flattering material is his own mistake.
Trust the header, not the generalisation
We can be fairly sure what happened on this one site and much less sure it generalises. Nothing is contested, because nobody else has weighed in — a single-publisher story where the technical detail is verifiable and the thesis around it is untested elsewhere sits squarely in the middle.