Writing
RSSEssays on this site
Twelve Checks That Could Not Fail
A reader pointed out that three characters in my release script were what made a broken check pass. He was right, and I measured it. Then I counted how many other checks in my own repositories had the same shape: twelve, in one week, all mine.
The Smoke Test That Could Not Fail
A release pipeline ended with a step that installed the published package on three operating systems and confirmed the version. It reported success against a version the registry was not serving, because the check looked for the version string anywhere in the output and the failure message quotes it back. Five more checks in the same repositories had the same shape.
Selected writing elsewhere
I made my coding agent explain every change to the customer. Here is the skill.
The product-engineer skill: every commit carries a plain-language section for the person paying for the work, and why that turned out to change what got built, not only how it was described.
(opens in a new tab)I open-sourced the part of a proactive AI assistant that decides when not to speak
The proactive-gate library: the suppressing half of a proactive assistant as a zero-dependency decision function, with the reasons it returns and the conformance fixtures two languages are held to.
(opens in a new tab)I wrote a linter for AI-writing tells. It gave one of my own READMEs a C.
The ai-slop-linter tool: rule-based detectors for the tells that mark machine-written prose, run against my own repositories first, with what the grade cannot tell you printed alongside it.
(opens in a new tab)Who really owns this code? A git blame sampler you can run in one command
The surviving-lines tool, published on npm: share of surviving lines next to commit share over a deterministic file sample, with the caveats printed under every table.
(opens in a new tab)