A while back I wrote about catching 3 bugs by making my AI review its own code as a skeptical stranger instead of trusting its own "done."
This time it happened again. Twice, in the same session, on two completely different kinds of work — and neither one was code.
First, a false alarm (so you know I don't cry wolf)
I was migrating my dev environment from one drive to another. Partway through, one folder was missing about 12,000 files. My assistant flagged it as a possible migration accident.
Turned out it wasn't. That folder was a virtual environment — a disposable toolbox rebuilt per project — and it was deliberately excluded from the move (it was sitting right there in .gitignore, with a note to rebuild it fresh at the new location). The files were missing because they were supposed to be missing; they were hardcoded to the old path and would've been dead weight anyway.
I checked before assuming the worst. Worth mentioning, because everything after this is the opposite: two cases where something looked fine, and wasn't.
Case 1: a security checklist with 3 holes I couldn't see
I'd just finished writing an audit checklist meant to apply across several of my apps — the rules an AI should follow when checking for security issues. I read it over, it looked solid, and I almost called it done.
Instead, I handed just the ruleset to a second AI and asked it to try to break it.
It came back with three holes:
- Every finding was treated as an automatic blocker. That sounds strict, but it actually creates an escape hatch: the more annoying a finding is, the more tempting it is to just redefine it as "out of scope" and wave it through. A rule with no nuance quietly invites self-approval.
- "Marked as resolved" didn't require evidence. Nothing stopped a check from being marked fixed just because it felt checked, with no actual proof attached.
- Permission settings were graded on whether they were "enabled," not on what they actually did. A permission can be technically on and still be configured so loosely it lets anything through. You have to actually test access, not just read a config flag.
None of these occurred to me while I was writing the checklist. All three were obvious once someone read it who hadn't written it.
Case 2: a style summary that quietly drifted from its source
The next day, separate task: I'd read a style guide on writing clearly and boiled it down into a short set of rules — sentence length, paragraph breaks, that kind of thing.
I asked the same second-opinion process to check my summary against the original source, line by line.
Two things came back:
- I'd written "around 20 characters per sentence." The source actually said "20 characters or fewer" — a soft suggestion turned into a hard limit I'd invented.
- I'd added a second number — a 50-character cap for a "unit of meaning" — that didn't exist anywhere in the source at all. It was something I must have half-remembered from somewhere else, and it had quietly merged into my notes as if the source had said it.
And this wasn't a vibes-based objection — it was backed by an actual line-by-line count of the source document. Average sentence length: 13 characters. Only 4 lines out of the whole document exceeded 20, and one of those was a line intentionally written as a bad example.
Why does this keep happening?
Neither of these was code. One was a rule I wrote, the other was a summary I wrote. Same result both times.
My best explanation: when you're the one who wrote something, you're reading it through the intent you had while writing it. You're checking "does this match what I meant?" — not "was what I meant actually correct?" A number you copied from memory feels like it came from the source, because in your head, it did.
A second reader has no such memory to protect them. They just read what's actually there.
The takeaway
This isn't a one-off. It's now just something I build into how I work: nothing gets marked "done" until it's been read once by someone (or something) that didn't write it and has no stake in it being right.
Twice in one session, on two unrelated kinds of work, that one extra step is what caught it. I don't think that's a coincidence anymore.
I write more about this kind of thing — solo dev + AI, the wins and the messes — on Threads. I also wrote up the original code-bug version of this story here.
Top comments (0)