When Daniel Miessler ships a new version of his AI workflow, every flaw a user finds gets turned into a permanent, automated check. His stated rule:

every finding must also become a deterministic catch, so the same class can never need an audit again

The idea is worth unpacking because it applies to anyone who relies on software, not just people who build it. A "deterministic catch" is a test that produces the same verdict every time — pass or fail, no judgment call, no human rereading the output. The contrast is with how most AI mistakes get handled today: someone spots a problem, the developer fixes that instance, and the fix quietly regresses in a later update because nothing is actually watching for it. Miessler's rule says the fix isn't complete until there's a machine-checkable gate that would catch the same class of problem if it ever reappeared.

"Class" is doing real work in that sentence. If an assistant mishandles dates in one report, the catch shouldn't only check that one report — it should check date handling generally, so the sibling bugs get caught too. Done properly, each release becomes strictly safer than the last, because the suite of gates only ever grows. The accumulated catches are, in effect, an institutional memory that outlives any individual review.

This is, to be plain about it, a developer's discipline. The reader it serves directly is someone building or maintaining AI-assisted workflows — the person writing the checks, wiring them into a release process, and deciding what counts as a "class" of bug. If you use AI tools but don't build them, there is no button here for you to press. What you can take from it is a standard to hold vendors to: when an AI product you use fixes a bug you reported, the fair question is whether they also added a permanent check for it, or whether you'll be reporting the same thing again in three months. Recurring bugs across updates are usually a sign that fixes are being made without gates behind them.

It is also a useful lens for your own habits if you check an assistant's output manually. Every time you catch the same kind of error twice — the same formatting slip, the same wrong assumption — that repetition is telling you the checking itself should be systematized, whether in a template, a checklist, or a prompt instruction, even if you can't write an automated test.

On the honesty point: this is a working practice Miessler describes as shipping, not a proposal on a whiteboard. But it comes with real limits he doesn't gloss over and shouldn't be read past. Building a deterministic catch takes effort every single time, which means the discipline only pays off if bug reports actually flow in — a workflow with few users finds few bugs, so the gates accumulate slowly. Some classes of failure resist deterministic checking entirely; "the summary missed the point" is much harder to turn into a pass/fail test than "the date was wrong." And a growing suite of checks is only as good as the decisions about what counts as the same class — draw the boundary too narrowly and near-identical bugs slip through wearing a slightly different hat.

None of that makes the rule wrong. It makes it a discipline with a price: every bug report costs you a test, forever, in exchange for never auditing that class of problem again. For people whose AI mistakes keep recurring across versions, that trade is the whole point.