Let's open the hood.
You've got a plan on screen, or a diff, and you're about to click approve. Before you did, you already asked the chat the question everyone asks: "is this right?" It said yes. You know that yes doesn't mean anything — you just don't have a name for why yet, or a habit that replaces it.
Here's the name: the thing you asked is the same thing that wrote the answer. That's not a gotcha about AI being untrustworthy. It's a structural fact about how a single model session works, and once you see it, you'll never phrase the question the same way again.
What just shipped, and why it's the tell
On 26 August 2026, VS Code 1.135 shipped a feature called Rubber Duck — an experimental, read-only critic that reviews the primary agent's plan, code, or tests using a different model from the one that produced them. Invoke it with '/rubber-duck' inside a Copilot agent session, and if your driving model is Claude, the reviewer that shows up is GPT-5.4. It doesn't edit files. It doesn't run commands. It reads what the other model did and reports back what it would have done differently.
Microsoft didn't invent the idea — GitHub Copilot CLI shipped the same mechanism back in April 2026 — but shipping it inside the editor most people already have open is the thing that makes it worth stopping on. It's not the tool that matters here. It's the design decision underneath it: the reviewer is never the author.
Notice where the primary agent is meant to hand work over to Rubber Duck: after it drafts a plan and before implementation starts, after a complex implementation, and after writing tests but before running them. That first checkpoint is the one worth sitting with. It's not reviewing finished code. It's reviewing the plan you're about to approve — the exact document you're staring at when you type "is this right?" into the same chat that wrote it.
Why a model can't catch its own blind spot
Picture a plumber who just capped a pipe. Ask him "did I do this right?" and he'll check the thing he was thinking about while he did it — is the joint tight, does it hold pressure. He's not going to notice that he capped the wrong pipe, because "which pipe" was already settled before the question got asked. The check happens inside the same decision that needs checking.
A model reviewing its own output has the identical problem, just faster. Whatever assumption shaped the code — this input is always a string, this list is never empty, this token only needs its signature checked — is still sitting in context when you ask "is this right?" The model isn't lying to you. It's answering honestly, from inside the frame that produced the bug in the first place. A second model, cold, with none of that context, has to form its own frame from scratch — and a different frame is exactly what catches an assumption the first one never examined.
A bug that would pass its own review
Here's a small, real example, the kind an agent writes without anyone asking for it. Say you're debugging a clock-skew issue on staging, so you tell it to relax the token expiry check temporarily. It does — cleanly, correctly, exactly as asked — and the change gets folded into the same commit as three unrelated fixes. Nobody remembers to flip it back.
import jwt
import datetime
SECRET = "dev-secret-do-not-use-in-prod"
def check_session(token):
# signature check only -- exp verification was turned off while debugging
# a clock-skew issue on staging, and the toggle never got flipped back.
return jwt.decode(token, SECRET, algorithms=["HS256"],
options={"verify_exp": False})
Run a token that expired an hour ago through it (PyJWT 2.7.0, Python 3.11):
expired = make_token(minutes_from_now=-60) result = check_session(expired) print("Session accepted for:", result["sub"])
Session accepted for: user-42
Ask the model that wrote 'check_session' whether it's correct, and it will tell you the truth as it understands the truth: yes, the signature is verified against the secret, yes, the algorithm is pinned, yes, that's a solid check. All true. None of it is the question that matters, which is whether an hour-old session should still be live. The model isn't wrong about what it checked. It's silent about what it stopped checking, because that decision happened off-screen, three prompts ago, and "is this right?" doesn't reach back for it.
The fix is one word — delete the options dict, or set 'verify_exp' back to its default of True — and PyJWT rejects the same token with 'jwt.ExpiredSignatureError'. I ran both versions before writing this; that's the whole demonstration.
The version that costs you nothing tonight
You don't need VS Code 1.135, and you don't need Copilot. Rubber Duck is one implementation of an idea you can run by hand in the next five minutes, in whatever two chat tabs you've already got open.
Take the code or the plan you were about to approve. Paste the exact same thing into a different model — if you've been working in ChatGPT, open Claude; if you've been in Claude, open ChatGPT or Gemini. It doesn't need to be a better model, only a different one, because "different" is the whole mechanism.
Then don't ask "is this right?" Ask this instead:
"A different AI wrote this. Assume it missed something specific and non-obvious — not a style nitpick. What would you flag?"
That phrasing does two things the first one doesn't. It removes the social pull toward agreement — there's no author in the room to be polite to, because you've told it the author is someone else. And it points the model at absence instead of presence: not "is what's here correct" but "what's supposed to be here and isn't." That second question is where the exp-check bug lives, and it's the question the first model structurally can't ask itself.
Works on a plan the same way it works on code, and honestly it matters more there — a plan is a set of decisions nobody's tested yet, which means there's no error message to eventually flag the miss for you. If the plan says "cache API responses by user ID" and never says for how long, a second model reading it cold is far more likely to ask "how long?" than the model that already has an answer in mind and didn't think to write it down.
Why this matters
This isn't really an AI-tools tip. It's the same reason a second pair of eyes catches a typo you've read past six times — your own eyes keep re-reading what you meant to type, not what's on the screen. A model has that exact failure mode, minus the fatigue, plus a much higher word-per-minute rate at producing confident-sounding code. Cross-model review doesn't fix that. It just makes sure the checking happens from outside the frame that made the mistake, instead of from inside it.
Our QC editor wouldn't let me put a vendor benchmark number in this piece, not even as a footnote, and she's right to hold that line — a percentage from the company selling you the fix isn't evidence, it's marketing with decimal places, and the mechanism doesn't need it to be true.
Next step
Tonight, before you approve the next plan or diff your agent hands you, copy it into a second model's chat and ask the exact sentence above — not "is this right," but "what would you flag that a different AI might have missed." Do it once on something you already trust, so you can see what a real miss looks like before you need one caught for real.