Your best reviewer is the one who has never heard your reasoning

A sibling post makes the case that review by reading catches everything on the screen and nothing behind it. This one is about a different blind spot, one that survives even when you are looking directly at the code: **you cannot see a line you already know the intention of.**

Not "you get careless." The opposite. You read the line, you recall what it was for, the recollection satisfies the check, and you move on — feeling attentive, because you were.

The bug that five releases walked past

`clikae resume` scans every account directory to find which one owns a session. On a machine with only one engine installed, one of those directories does not exist. The glob does not match. `stat` is handed a literal unexpanded pattern, exits non-zero, and under `set -eo pipefail` the whole command dies — **with no output at all.** You type a command, you get your prompt back, nothing happened, nothing was printed.

That shipped in v0.7.1 and lived through five releases.

Every reader of that line, including me, knew what the scan was for. Knowing that is exactly what let the eye pass over the case where the directory is not there. The knowledge was not a distraction from the review; it *was* the review, and it answered the wrong question — "does this do what it is meant to do?" rather than "what does this do when the world is not as I imagine it?"

It was found by pointing a reader at the diff who had never been told what any of it was for.

The mechanism, and how cheap it is

The tool I use for this is a throwaway session with its long-term memory pointed at an empty directory — an incognito run. No project history, no prior conversation, no accumulated model of what I was trying to build. Then: here is a diff, tell me what breaks.

That is the entire technique. It is not a smarter model, a longer prompt, or a review checklist. It is the *removal* of context, which is the opposite of how everyone reaches for these tools.

It has caught, on this codebase alone:

• the silent death above, five releases old;
• a multi-line prompt shattering into one argument per line, because every test prompt in the suite had been one line;
• an empty result counted as a success, because the wrapper's own `printf` wrote a newline and a newline is not zero bytes;
• two claims in a release's documentation that overshot what the code actually did — a cold reader has no reason to grant you the benefit of the doubt on a sentence, because they have not watched you earn it.

Every one of those was invisible to me for the same reason: I knew why the code looked reasonable.

Cross-family, when the stakes are higher

For the release that took the interface to nine languages, the new translation tables were read cold by a model from a *different vendor family* — not just a fresh session of the same one.

It caught a real inversion: a German line that promised the reader the disk space they **had** rather than the space they would **reclaim**. That is a sentence a native speaker could skim past, because it is fluent and it is about the right subject.

It also produced a pile of confident nonsense that did not survive checking.

Both halves matter. A cold reader has no stake in your reasoning, which is why it can see the inversion — and no stake in being right, which is why perhaps a third of what it hands you is invented. **The output of a cold read is a list of suspects, not a list of findings.** If you skip the step where you check them yourself, you have swapped one kind of blindness for a noisier one.

The technique has its own footgun, and it bit us

There are two ways to give a session a blank memory here. One points it at a throwaway for that run only. The other flips the account's memory off from now on.

An agent reached for the second one to spawn a cold reader — on an account that had a live session running. The memory slot is re-projected when a session launches, and a session already running never launches again. So a conversation in another window lost its long-term memory mid-flight, and the status command went on reporting everything was fine, because membership said shared while the disk said nothing.

The rule that came out of it is one line, and it now lives in the file an agent actually reads on startup:

**Ephemeral changes this once. Isolate changes from now on.**

I am including this because a post that only lists a technique's wins is advertising. The technique is good. It also has a way to hurt you, and the way it hurts you is that "give this reviewer no memory" and "take this account's memory away" look like the same sentence in English and are not the same operation.

What I would tell you to try

1. **Before you ship a diff, hand it to a reader with no history of the project** and ask only what breaks. Not "review this." Not "is this good." What breaks.
2. **Do it on a different vendor's model** when the change is in a domain you cannot personally audit — another language, another platform, a spec you have only read once.
3. **Treat the result as suspects.** Verify each one against the code before you touch anything. A confident finding that dissolves under checking is the normal case, not a scandal.
4. **Give it no memory for this run — do not take memory away from the account.** They are different verbs.

The general shape, if you want one sentence to carry out of here: *expertise is compression, and the thing compression discards first is the case you have never seen.* A reader with no expertise in your project has not discarded it yet.

The boring footnote

The incognito flag is `--ephemeral`, in clikae — plain bash, MIT, no daemon, no telemetry. It exists so that a session can be thrown away cleanly, which turned out to be more useful for reviewing my own work than for anything I originally built it for.