How to Get Your AI Coding Assistant to Catch Its Own Mistakes Before You Do
A draft that reads as finished has only passed the test that matters least.
The path of least resistance is always the same: read it once, it sounds right, ship it. A separate Claude Code session with no memory of writing the thing — checking a specific written rubric instead of forming a general impression — is what actually tests whether a draft is correct instead of just re-confirming that it sounds correct. Run that against a piece that already looked done, and it will find things a second read-through by the author never will.
TL;DR
- Self-review has a structural blind spot, not a diligence problem: once a draft sounds right, re-reading it mostly re-confirms the impression that produced it in the first place. An AI checking its own output has the identical blind spot, for the identical reason — it has no internal way to distinguish "verified" from "sounds confident."
- The fix isn't asking the same AI to double-check itself in the same conversation. It's a fresh Claude Code session with zero memory of drafting the piece, given a specific written rubric to check against — not a vague "does this look good."
- I ran exactly this against a draft that already looked finished. It caught: an invented statistic that quietly contradicted a different line in the same piece, a claimed count of findings that only actually described one of the two things it said it found, and a framing choice that violated a standing rule I'd set for exactly this kind of piece.
- None of the three were subtle once something was checking for them specifically. All three were invisible to a general "does this seem right" pass — which is the actual lesson: a rubric beats a vibe, every time, and the AI that wrote the draft is the worst-positioned reviewer of it.
| Review type | What it's actually checking | What it tends to miss |
|---|---|---|
| Reading it again yourself | Whether it sounds right | Anything you already believe is settled |
| Asking the same AI to double-check itself | Whether it agrees with what it just wrote | Its own errors — it has no reason to doubt them |
| An independent pass with a written rubric | A specific, falsifiable claim ("is this number real," "does this violate rule X") | Almost nothing, because it isn't grading on vibes |
Only the third row is actually checking something. The first two are re-reading, dressed up as review.
Why the writer can't be the only reader
There's a reason professional software teams don't let the person who wrote the code be the only one who reviews it — Google's own engineering practices treat review by someone other than the author as the baseline, not an optional extra, for exactly this reason: the person who wrote something already knows what they meant by it, which means they read past ambiguity, missing context, and small inaccuracies, because the gap gets filled with intent instead of what's actually on the page. An AI assistant reviewing its own output has the identical failure mode for a more literal reason: within the same context, it has no way to distinguish "what I actually verified" from "what I'm confident sounds right." Both come out fluent. Only one of them is true.
Asking the same AI, in the same conversation, "does this look correct?" mostly reproduces the original confidence rather than testing it. It isn't lying — it genuinely doesn't have a mechanism to doubt itself from the inside. What changes the outcome is a second pass that starts cold, in an isolated context with no stake in having written the thing — the same reason Claude Code's own subagent design hands exploration and review work to a separate context rather than the one already carrying the task's history — checking a specific claim rather than forming a general impression.
What "independent" actually has to mean, or it's theater
The distinction that matters isn't "a different AI call" — it's a different, concrete question. "Does this look good?" produces the same kind of fluent, unfalsifiable answer whether one model asks it or three do. What actually catches something is checking a claim specific enough to be wrong:
- Not "is the tone okay?" but "does this sentence violate this specific rule, yes or no, quote the exact text."
- Not "does this seem accurate?" but "here is what actually happened — check every number and claim in this draft against it, and flag anything that doesn't match."
- Not "is this appropriate?" but "would a reader who knows nothing about this project be able to infer anything they shouldn't from this specific paragraph?"
Each of those has a real answer, and each one is checking something different. Run one vague pass and you get one vague "looks fine." Run three specific ones — voice against a written rule, facts against what actually happened, and exposure against a concrete checklist — and each one either turns up something or it doesn't, on its own terms.
Three things a rule check, a fact check, and a completeness check found — that a plain re-read wouldn't have
Running exactly this against a draft that had already been called finished, using Claude Code as the independent reviewer, turned up three distinct findings — not stylistic nitpicks.
The rule check caught a violation wearing different words than the ones it was watching for. There's a standing, non-negotiable rule about how a certain kind of story gets framed — not "never mention a setback," but a specific line about whose setback it's allowed to sound like. A few sentences in the draft technically obeyed the letter of that rule while violating its spirit: nothing stated a mistake outright, but the passive framing landed in the same place a direct statement would have. A keyword-based check would have missed this cleanly, because no banned phrase was present. What caught it was checking for the underlying pattern the rule actually protects, not a literal string match.
The fact check caught a statistic that was invented and quietly self-contradicting. One line stated a specific count concentrated in a single location; a different line later in the same piece stated the same count spread across two locations. Neither number traced back to anything verified — both were "a plausible-sounding amount" filling a sentence that needed one. Checked against what had actually happened, the real answer was vaguer and less satisfying to write than either invented figure — and the fix was to state the vaguer, accurate thing instead of a precise-sounding guess.
The completeness check caught a claim the draft never fully delivered on. A line stated that two distinct issues had been found and resolved, then only described one of them in any detail — the second was named in a summary sentence and then silently dropped from the explanation that followed. This is the hardest of the three to catch by re-reading for tone or accuracy, because the sentence that names "two things" isn't wrong on its own; it only surfaces as incomplete when something checks whether the draft actually delivers both of the things it claims.
The habit worth stealing, even solo
None of this requires a formal editorial process. The three things worth doing on anything that ships under your name, even as a single person working alone:
- Write the rubric down before you write the draft, or at least before you review it. "Sounds right" isn't a rubric. "Never let this specific thing look like a personal mistake," "every number must trace to something that actually happened," and "nothing here should let a stranger infer X" are rubrics — specific enough to fail.
- Run the check in a fresh context, not a follow-up message in the same conversation. The point is a read with no investment in the draft already being correct.
- Ground every fact-check against the actual event, not against how plausible the draft sounds. "More than a dozen, scattered across a few places" is less satisfying to write than a precise-sounding number — and it's the one that's actually true when the precise number was never verified in the first place.
Run this yourself: the four-question rubric that makes it repeatable
A rubric like this works as a prompt template for a fresh Claude Code session reviewing any draft — one you or an AI assistant just wrote — before it goes anywhere public:
Review this draft with no assumption that it's already correct.
1. Voice/framing check: [state your specific, non-negotiable rule here —
e.g. "never frame this person as having personally made the mistake
being described, even in passive voice"]. Quote any sentence that
violates this, even subtly.
2. Fact check: here is what actually happened — [paste the real,
verified sequence of events]. Check every specific number, count, or
claim in the draft against this. Flag anything invented, exaggerated,
or inconsistent with itself (e.g. stated differently in two places).
3. Exposure check: could a reader infer anything specific and sensitive
from this that isn't already public? List anything borderline.
4. Completeness check: for every claim that says "X things happened,"
confirm the draft actually describes all X of them, not just one.
Report findings as: quote the exact text, explain the specific problem,
propose a fix. Do not soften or skip anything to be polite.Treat every finding as real until you've checked it yourself — the value of this pass is that it's checking specific, falsifiable things, not that it's infallible.
FAQ
Isn't this just asking the AI to proofread itself?
No — the difference is the fresh context and the specific rubric. Proofreading in the same conversation inherits the same confidence that produced the draft. A fresh pass with a written checklist has no stake in the draft already being right, and it's answering a specific question ("is this number real," "does this violate rule X") instead of forming a general impression.
How do I know the review pass itself isn't wrong?
You don't, automatically — treat every finding as a claim to verify, not a verdict to trust blindly. In practice, specific findings ("this number contradicts that number three paragraphs later") are easy to check yourself in seconds; vague ones ("this feels off") are the kind worth pushing back on or ignoring.
Does this only matter for public content?
It matters most for anything that ships under your name to an audience that can't fact-check you in real time — a blog post, a report, client-facing copy. For low-stakes internal notes, the overhead usually isn't worth it. Match the rigor to what's actually at stake if it's wrong.
What if I don't have a formal style guide or rubric to check against?
Write down two or three non-negotiables before you need them — the specific things that would actually bother you if a piece of writing got them wrong. That short list, however informal, is enough to turn a vague "does this look good" into a checkable pass.
Bottom line
The same AI that wrote a draft is the worst-positioned reviewer of it, for the same reason a writer is a bad editor of their own work — both already believe they got it right. An independent pass with a specific, written rubric isn't extra ceremony; it's the only version of "review" that's actually checking something rather than re-confirming a first impression. Run one before anything goes out under your name, and expect it to find something real.
I use GrowthLayer to bring the same discipline to marketing decisions — checking a claim against what the data actually shows instead of what the copy wants to be true. Want a review process like this built into your own content or code pipeline? Book a call and we'll scope it.