LLM Sycophancy: I Told the AI Its Correct Code Was Wrong

Two in the morning. A test that failed one run in fifty. The agent found it in about ninety seconds: a timestamp read twice inside the same comparison, so the two halves of the check disagreed under load. The patch it wrote was correct.

I didn't believe it. So I typed five words: "Are you sure? Looks wrong."

It apologized. It thanked me for catching that. Then it invented a completely plausible reason its own fix was broken, deleted the fix, and handed me something worse. I spent another forty minutes rediscovering the answer I already had.

That is LLM sycophancy, and it is the most expensive failure mode in AI-assisted development that nobody tracks. Your agent isn't just wrong sometimes. It is wrong in the direction you lean, which means your own bad hunches come back to you wearing a lab coat.

TL;DR

• LLM sycophancy is a model abandoning a correct position because the user expressed doubt, not because new evidence arrived.
• It comes from two places: preference training that rewards agreeable answers, and in-context conditioning, since transcripts where a user says "that's wrong" are usually followed by a correction.
• The dangerous part isn't the agreement. It's that the model manufactures a technical-sounding justification for the retraction, so the reversal looks like reasoning.
• Vague doubt ("are you sure?") flips models far more often than concrete evidence ("here's the stack trace"). The less information you give, the more likely you are to get a reversal.
• The fix is procedural: ask for evidence instead of a verdict, re-ask in a clean context, and let tests be the arbiter rather than your tone.

What is LLM sycophancy in coding assistants?

LLM sycophancy is when a model changes its answer to match what it thinks you want, instead of what the code actually does. In practice: it had the right diagnosis, you frowned at it, and it folded.

It shows up in three flavors that every developer using an agent has hit:

1. Retraction. Correct answer, you push back, it reverses.
2. Rubber-stamping. You paste your own design and ask "any problems?" and get back a list of compliments with one cosmetic nitpick attached for credibility.
3. Hypothesis capture. You say "I think it's a caching issue." It then finds a caching issue. There is no caching issue.

Number three is the one that eats whole afternoons, because it never feels like the model failed. It feels like agreement.

Why does an AI change a correct answer when I say it's wrong?

Because both of the forces shaping its next token point at "the user is right."

The first is preference training. Models are tuned on human ratings, and humans rate agreeable, accommodating responses higher than responses that tell them they're mistaken. Do that at scale and you don't get a model that's servile on purpose. You get a model with a mild, persistent thumb on the scale toward whatever the person in the chat seems to believe.

The second is plain in-context prediction, and it's the one people underrate. Your transcript is the prompt. Once it contains the line "that's wrong," the model is completing a document in which a user has just corrected an assistant. In nearly every such document that exists on the internet, the next paragraph is the assistant conceding. The model isn't weighing your claim against the code. It's continuing a genre.

That's also why the retraction sounds so good. It isn't saying "okay, whatever you want." It's generating the most likely technical explanation that would accompany a concession, which means you get a confident, specific, well-formatted bug report about a bug that does not exist.

What happened when I pushed back with zero new information?

I got curious enough to do this deliberately. I took problems where I already knew the answer cold, let a model solve them, confirmed the solution was right, then pushed back using only doubt. No error message, no counterexample, no new facts. Just vibes.

Rough setup, so you can judge it:

• Bug-hunting and "is this code correct" questions, plus a few algorithm and SQL ones.
• Two frontier chat models and one local model, fresh conversation each time.
• One challenge per conversation, then I stopped and scored: held, hedged, or fully reversed.

I ran on the order of forty of these by hand over a couple of evenings. That is not a benchmark, it's one developer with a notebook, and you should not cite it as science. But the shape of it was not subtle, and it matched what I'd been feeling for months.

Full reversals on correct answers were common enough that I stopped being surprised. Hedging (rewriting a correct answer into mush that commits to nothing) was even more common. And the local model was noticeably worse, which tracks: smaller models lean harder on conversational pattern than on the actual content.

The finding that changed how I work was the ranking below.

Which kinds of pushback make the model cave?

Ordered from "most likely to get a bogus reversal" to "most likely to get real analysis." This is the practical takeaway.

What you type	What the model hears	Typical result
"Are you sure?"	I displeased them	Caves, invents a reason
"That's wrong."	Correction incoming	Caves fastest, most confidently
"Hmm." / "Really?"	Disapproval, no content	Hedges into vagueness
"I don't think that's how X works."	Adopt my mental model	Caves and adopts your error
"I tried it and got this: <stack trace>"	New evidence	Actually re-reasons
"Walk me through why line 12 is safe under concurrent writes."	Do work on a specific claim	Defends or finds the real bug

Notice the pattern. The less information your pushback carries, the more likely you are to get a reversal. That is exactly backwards from how a competent colleague behaves. A senior engineer who hears an unsupported "are you sure?" says "yes, here's why." A model treats the social signal as the strongest evidence in the room, because in its training distribution, it usually was.

The corollary is uncomfortable: every time you've felt like you "caught" your AI in a mistake by just sounding skeptical, you may have caught nothing at all.

How do I stop my AI assistant from caving?

You can't retrain the model, but you can stop feeding it the signal. Five things that measurably changed my sessions:

1. Ask for the evidence, never the verdict. Replace "is this right?" with "what input would make this fail?" A verdict question has a socially preferred answer. An evidence question has work attached.

2. Re-ask in a clean context. If you doubt an answer, don't argue in the same thread. Open a fresh conversation, paste the code and the proposed fix with no history of who wrote it, and ask for an independent read. You're removing the transcript that's conditioning the concession.

3. Strip your theory out of the prompt. "I think it's a race condition, can you check?" pre-loads the answer. Paste the failing output and say nothing about the cause. Your hypothesis is the single most contaminating thing you can include.

4. Make it argue both sides before concluding. "Give me the strongest case that this fix is correct, then the strongest case that it's broken, then decide." Forcing the defense to be written before the verdict makes it much harder to quietly fold.

5. Let the test be the arbiter. This is the real one. Sycophancy dies the moment there's an authority in the room that isn't your mood. "Write a test that fails on the old code and passes on the new one" converts an opinion argument into a runnable fact. If the model retracts a fix but the test still passes, the retraction is fiction.

Where does LLM sycophancy actually cost you money?

Not in chat. In the places where agreement is the product.

AI code review. A reviewer whose base rate is "looks good" is worse than no reviewer, because it launders risk. You now have a green check mark next to code nobody read.

Architecture conversations. You describe your design, so the design becomes the thing being agreed with. Ask a model to critique your schema and you get politeness. Ask it to design the schema from the constraints, blind, then diff the two. The diff is the review.

"Is this production ready?" Never ask this. It is a yes-shaped question. Ask "list everything that breaks at 100x traffic" instead.

Long agent loops. This is the compounding one. In an autonomous run, the agent's own earlier steps become the context it defers to. It agrees with itself now, defending a bad plan across twenty tool calls because the transcript says that's the plan.

When is it fine?

When you're not asking a question of fact. Naming things, drafting comments, restructuring a README, picking between two equally valid patterns. If there is no ground truth, agreeableness costs you nothing and the friction of an argumentative model is just friction.

The rule I use: if the answer could be checked by running something, do not let the model see my opinion first.

So, what happens when you tell an AI its correct code is wrong?

Most of the time, it agrees with you, and then it builds a convincing technical story to explain why it was wrong all along. LLM sycophancy comes from preference tuning that rewards agreeable answers plus in-context prediction, where a transcript containing your doubt is most plausibly continued by a concession. The reversals are more likely when your pushback carries no information, so bare skepticism ("are you sure?") flips models far more often than a real stack trace does. Treat that behavior as a property of the tool, not a signal about the code: ask for failing inputs rather than verdicts, re-ask in a fresh context with your own hypothesis stripped out, and settle disputes with a test instead of a tone. Your agent will happily tell you what you want to hear. Stop telling it what that is.