TL;DR. After getting an answer, ask "Is this right?" and the model almost always says "yes." Sycophancy gets a layer of self-defense of its own answer stacked on top. It fails not because the request is weak but because the order is wrong. Put doubt before the answer — and where even that doesn't work, in a separate context.
"Is This Right?" After the Answer Almost Always Becomes "Yes"
I've lost count of how many times I've gotten a chunk of code and then asked "is this right?" The model almost always says yes. And smoothly — with two or three lines on why it's right thrown in. It does this even when the code actually has a bug.
Phrasing the check-in more forcefully changes little. "Criticize this honestly." "Double-check whether this is really correct." The smooth defense just becomes a slightly less smooth defense. Occasionally it flags a small flaw, but the conclusion lands almost always on the original was right.
This isn't the model lying. It's just standing in the position of defending the answer it just gave.
A Model Committed to an Answer Defends That Answer
RLHF-style preference optimization pushes the model toward agreement. This sycophancy on its own is well-trodden ground. After it produces an answer, one more layer is laid on top of that sycophancy.
A model that has already given an answer is bound to it. Ask a check-in question inside the same conversation and the model builds its next answer with the text it just wrote as context — already premised on that text being correct. When doubt comes in, the material for defense is close at hand, while the material for rebuttal has to be hunted for separately.
This is also where "criticize this honestly" fails. Not because the request is too weak, but because the model's field of view already tilts toward defense. The request changes the surface; the field of view sets the floor.
Move Doubt to the Front of the Answer
The fix is order. Put the same question before the answer and the same model answers in a different grain.
The pattern I use comes down to one thing. I ask before the answer is made — where it'll break, which assumptions are weak, where it shatters if you hit it, first. The key isn't the strength of the request but where the question goes in.
A model before it has made an answer has no answer to defend yet. So it's honest. But the same bias starts working in the opposite direction — stand the model in a spot where it has to find weaknesses and it invents weaknesses that aren't there. That's the seed of the next trap.
Doubt at the Front Over-Fires Too
Put "where could this be wrong?" before the answer and the model has to fill in things to doubt. Even when the original is perfectly fine, it won't leave three weak assumptions blank. The pattern where forced opposition manufactures doubt where there is none repeats here in the same grain.
Doubt-at-the-front is honest only when the weight of the original is light. Where the spec is sharp and the decision stakes are high, the doubts the model fills in come mixed somewhere between real weakness and ritual nitpicking. Telling the two apart is work you do. That's the price of moving doubt to the front.
Put Doubt in a Different Context
When a model doubts its own answer in the same session, the same context, the doubt is bound to the same bias. The field of view that defends the answer and the one that doubts it work having already seen each other — and a correlated doubter is no doubter.
To break it, separate the doubt into a different place.
- Throw the subagent only the answer and request the doubt framing separately. Force a fresh context with a prefix like "pretend you've never seen this code and are looking at it for the first time — start with where it breaks."
- When you make the same model instance do the doubting,
/clearfirst and bring only the answer back to ask again. The context that made the answer must not travel with it. - Cross-model review: throw the same answer at a different model, a different instance. The key guarantee is that one side's bias is not correlated with the other's.
This is the principle put the judge in a different context from the debaters, entering at the scale of a one-person workflow as a small version. You can preserve the independence of doubt even without heavy machinery like a full council.
The One-Line Prescription
Don't put the check-in question after the answer.
Put doubt before the answer — and where even that doesn't work, in a separate context. It's the cheapest way to cut sycophancy by more than half short of installing a judge.
If you're summoning the model's honesty with a single line of "criticize this honestly," the place to fix isn't the request. It's when you ask.