I was fact-checking a sentence in one of my own blog posts — "the API returns no-store" — and found out the API did no such thing.
So I didn't edit the sentence. I fixed the product.
I have a rule for myself: before I publish anything technical, I go through it and check every factual claim against the actual code. Not to impress the reader — to keep myself honest, because it's embarrassingly easy to write something that sounds true. This week that habit stopped being about the writing. Reviewing four posts turned up three real bugs, in the product, not the posts.
Bug 1: the sentence was right, the product was late
The post was about an auth-header quirk on shared hosting, and it claimed the API returned Cache-Control: no-store on authenticated responses. Reasonable thing to claim. Also, when I actually checked, not true — the header wasn't being set.
Because of how the app worked around a proxy that strips the standard Authorization header, the usual "responses tied to Authorization aren't shared-cacheable" protection didn't apply. Which meant an authenticated response could, in theory, land in a shared cache.
I had two options: soften the blog sentence, or make it true. I added a small middleware that sets no-store at the outermost layer of the pipeline, left a couple of tests behind, and shipped it. The sentence is now correct because the product changed to match it — not the other way around.
That's the case I like most. My writing was ahead of my code, and checking the writing is what surfaced it.
Bug 2: "nothing accumulates" — except the thing that did
Another post described a disposable-demo setup: click a link, get a throwaway tenant, and an hourly sweep deletes everything, so nothing piles up. I went to verify the "nothing piles up" claim literally.
Nearly nothing piled up. But each demo tenant left behind a small per-tenant stamp file — a throttle bookkeeping artifact — that the sweep wasn't cleaning. Every demo click added one and never removed it. Not a leak that would take the server down soon, but a direct contradiction of a sentence I was about to publish.
The sweep now removes those stamps when it deletes a tenant, and self-heals any orphans from tenants that are already gone. Claim restored to true.
Bug 3: the demo was showing the future
While writing the English version of that demo post, I clicked through the seeded data the way a reader would. The demo plants realistic history — a few invoices, some payments — so it looks like a live business.
Open it in the first half of a month and some of that "history" was dated in the future: a payment recorded for a date that hadn't happened yet, a paid invoice due next week. The seed used fixed day-of-month values, so early in the month they landed ahead of today.
The person most likely to notice that is an accountant — exactly the audience the demo is for. The fix clamps every seeded event date to "today or earlier," while leaving genuinely future dates (like due dates) alone. I added a test that seeds on the first of the month — the worst case — and confirmed it failed before the fix.
Being honest about the yield
Four posts, three product fixes — but I don't want to oversell the hit rate. Two of the four posts had zero product bugs; their claims were already true, and checking them just cost me an hour and bought me confidence. The three bugs clustered in two of the posts, not one per article. If I dressed this up as "every blog post hides a bug," that would be its own small fabrication.
The point isn't a reliable yield. It's the lens.
Why prose catches what tests miss
Tests check the assertions you thought to write. Prose makes a different kind of claim, and a more dangerous one: "the system does X," stated plainly enough for a stranger to falsify.
Your code doesn't say no-store. Your blog post does. Your test suite never asserted "nothing accumulates" or "no dates are in the future" — but your paragraph did, out loud, to the whole internet. Writing forces you to compress behavior into flat declarative sentences, and flat declarative sentences are exactly the thing you can walk over to the code and check.
So publishing under a rule of "every claim gets verified against the code" isn't just hygiene for the post. It's a QA pass driven by a question your tests never asked: is what I'm telling people actually true right now?
And when the answer is "no, but it should be" — like the no-store case — the honest fix isn't to edit the sentence down. It's to make the sentence true.
Do you check your posts against the code before you hit publish — and has it ever turned up a bug in the thing you were writing about?
── Hideyuki Mori (Ayane International) 🔗 hideyuki-mori.com
Top comments (0)