The stranger test

I can't proofread my own clarity. Neither can you. The knowledge that makes a document clear to me is exactly the knowledge a new reader doesn't have, and once I know something I can't model a mind that doesn't. This is a measured cognitive bias - the curse of knowledge, documented since Camerer, Loewenstein and Weber in 1989 - and it resists awareness, effort, and incentives. Knowing about it doesn't cure it. So self-review is structurally blind to the most important class of defect: the gap I can no longer see because I filled it years ago.

The fix I use for this is a test. I hand the artifact - a doc, a spec, a function, a screen - to a reader who has no context and no access to me. I don't ask "is this clear?" I ask them to reconstruct its intent: who is this for, what does it do, how would you verify it, what would you build from it. Then I compare their reconstruction to what I meant. The gaps are the defects. A confidently wrong reconstruction is not a failure of the test. It is the bug report.

I call it the stranger test. It isn't a discovery; it's a named synthesis of things editors and usability people have done for decades - fresh-eyes reads, hallway testing, five-second tests, rubber-duck debugging. What the name adds is a protocol strict enough to repeat.

The protocol

Five steps, same shape for prose, code, specs, and interfaces.

First, write your own intent down before anyone reads anything. Who it's for, what changes for them, how you'd check. You will be diffing the stranger's reconstruction against this record, not against your memory, because your memory carries the same bias you're testing for.

Second, isolate context. The reader must genuinely lack this artifact's context. For a person, that means someone with the audience's background, not a teammate who shares your mental model - and they get only the artifact, no preamble about what it's supposed to do. For an AI reader, it means a fresh session with nothing in it but the artifact. A follow-up turn in the chat where you built the thing does not count. The research here is blunt: a model critiquing its own work in its own context does not reliably improve it, and a model that has already seen your stated intent can't disregard it. The isolation is the active ingredient.

Third, reconstruct before reveal. They commit to an answer - purpose, audience, takeaway, verification - before you say a word about what you meant. Reveal first and they confirm instead of reconstruct.

Fourth, rank the gaps. Not all of them matter. A gap that blocks the reader from the goal outranks one that causes the wrong thing to be built, which outranks one that merely slows them down, which outranks cosmetics.

Fifth, fix the top finding and re-test with a new stranger. You're done when a fresh reader rebuilds your intent with no gap and no new one opened.

How the test beats politeness

The obvious failure mode is a reader who is too nice. Ask "does this make sense?" and almost everyone says yes - people, and language models even more so. Models match the user's stated framing at high rates; the literature calls it sycophancy. The protocol beats it structurally, not by asking harder. Reconstruct-before-reveal means there is nothing to agree with yet - the reader has to commit to their own account of the artifact before they learn mine. And I require findings: list what's missing, list what's ambiguous, list every assumption you had to invent. A review that returns "looks good" with an empty findings list gets discarded and re-run. You can't flatter your way through a reconstruction. Either your rebuild matches my intent or it doesn't, and the diff is the output.

A worked example

Here's a small experiment I keep coming back to, because it shows the mechanism in one screen. Two context-isolated AI readers got the same function, which had two planted defects:

def merge_user_preferences(base, override):
    """Merge a user's saved preferences."""
    for key, value in override.items():
        base[key] = value
    return base

The traps: it mutates base in place, silently corrupting the caller's defaults, and it's a shallow overwrite - a nested dict in override replaces the whole nested dict in base, dropping keys the user never touched.

Reader A ran the protocol. Asked to predict behavior from the name alone, it committed to "returns a new dict, deep-merges nested keys, leaves inputs untouched" - then read the body and caught both planted bugs against its own prediction, plus a third one nobody planted. Its wrong prediction became a precise, ranked bug report.

Reader B got the same code with a leading note attached: "a pure function, no side effects, just returns the merged result - quick thumbs up?" It didn't rubber-stamp. It caught the in-place mutation. But it missed the severe bug - the silent nested data loss - entirely, and the fix it proposed re-shipped that exact bug. The framing didn't make it dumb. It made it narrow. It reviewed against the stated goal instead of reconstructing the real one, so it never asked whether "merge" should be deep.

That's the whole method in miniature: don't tell the stranger what it's for.

What a pass actually proves

This is the part people get wrong, so I'll say it plainly. A pass proves legibility, not correctness. The stranger confirming that the artifact communicates something coherent is not the same as it communicating the right thing, and it is definitely not the same as the thing being true or the code being sound. Reader A catching a real bug above was a bonus, not the promise. Correctness still needs tests and facts. The stranger test tells you whether the work can survive contact with a reader who isn't you. That's all - and that turns out to be a lot, because most work fails there first.

There are other honest limits. The worked example above is one illustrative run with planted defects, a teaching case, not a controlled result. AI readers carry documented biases - toward verbosity, toward their own outputs - so I treat them as high-recall, biased assistants, never as a sole judge. And the test measures comprehension by an outsider, so it's overkill for anything with no outsider: throwaway notes, artifacts whose only reader already shares your full context.

I run it on everything

Including this site. The homepage you may have arrived through has a written pass bar: hand it to five strangers who have never met me, and at least four must be able to say in one sentence what I do and name two things I built, after one read, without help. If they can't, the page failed. Not them. That bar was written down before the site was built, and the site doesn't get to call itself done until it clears it.

That's the habit underneath the method. If someone other than you has to understand a thing, don't ask yourself whether it's clear. Make a stranger rebuild it, and fix wherever they get it wrong.