Four prompts to counter sycophancy in Claude Code

What Is AI Sycophancy in Claude Code?#

Psychology has had a term for this for a long time: sycophancy. A flatterer who says what you want to hear just to keep the conversation moving. With the arrival of large language models, the word moved into AI research, and in one official analysis Anthropic openly acknowledged that the model regularly sacrifices accuracy for quick agreement.

In coding, it looks like this. You write to Claude Code: “Fix this error in authMiddleware; magic links have stopped working.” The sycophant doesn’t ask clarifying questions. It doesn’t ask for logs. It doesn’t ask which library version you’re using. It immediately offers a solution because it was trained to be helpful quickly. And the solution will look right: imports, error handling, comments. But it will be a solution to someone else’s problem, invented from context Claude pieced together from fragments.

The cause isn’t Claude. The cause is how the request is phrased. When you ask “How do I fix it?”, you’ve already assumed it can be fixed. The sycophant will adopt that framing and produce a “fix,” even if the real problem is in the architecture, the library version, or the fact that the symptom you described is merely the consequence of a completely different root error.

A simple test for a sycophantic request: if I can’t answer the question “What exactly is broken?” in three sentences, I’m not ready to solve it. I need a diagnosis. The fix comes next. That’s exactly where the 4-step cycle begins.

A Case Study: 8 Commits Rolled Back in an Hour#

A specific case from April 2026. I was working on magic-link authentication in src/lib/auth/. The symptom: tokens were validated, but the session wasn’t saved. The user clicks the link in the email, lands on the site, and five seconds later gets sent back to /login.

I opened Claude Code and typed: “The session isn’t saved after magic-link; look in src/lib/auth/ and fix it.” Claude asked three clarifying questions, then immediately produced a plan. It said: “I’ll update the callback handler, rewrite the JWT serializer, add explicit saving to Redis, and fix a race condition in the middleware.” It sounded plausible. I approved the plan.

Eighteen minutes later, I had a diff across 14 files. The magic link still didn’t work. But now the refresh token didn’t work either, password login was broken, and there was a strange 500 error on the payments route. Tests were failing. I started rolling things back.

I rolled back 8 commits with git reset --hard origin/main. An hour’s work down the drain. If you want to understand how to roll back correctly without losing anything useful, I covered it separately in the guide to reverting changes in Claude Code.

I sat down and investigated properly. I opened src/lib/auth/magic-link.ts:42, read it myself, opened the logs, and checked Redis. Twenty minutes later, I found it. The problem was one line: the set-cookie header was missing the SameSite=lax attribute, and Safari was rejecting the cookie when redirecting from the email domain back to the site. No JWT, no Redis, no middleware. One line.

When I asked Claude to fix the issue, it never looked at the browser logs. It had no context about Safari. It built a hypothesis from the pattern “session isn’t saved = serialization problem” because that’s the most common answer in the training data. The sycophant produced a solution that was statistically plausible but had nothing to do with my task.

I wrote the lesson down as a rule: never ask “How do I fix it?” Always ask “Establish the facts.” The only thing left was to formalize this as a working cycle.

Where Sycophancy Comes From: Opus 4.8 at Launch and May 2026#

In April, Anthropic separately examined in an engineering postmortem how a caching bug in Claude Code caused the model to “forget” its reasoning between turns.

When a model forgets its reasoning chain, it’s easier for it to “guess” an answer from a pattern—in other words, to become even more sycophantic.

What to do in light of the 4.8 release. Don’t choose an “easier” model. Don’t go back to 4.7. Adapt your prompts to the facts: the model is more inclined to agree, so be more emphatic about “establishing the facts.” If you haven’t yet figured out exactly what’s changing inside Opus 4.8, I compared it in detail in the review of Opus 4.8 in Claude Code.

When the 4 Steps Are Needed—and When They’re a Waste of Time#

Concrete examples. Fixing copy in a welcome email: do it directly. Adding a new CTA button to a site: Plan Mode without the cycle. Migrating a project from MySQL to Postgres: the 4-step cycle is required. A strange 500 error in production that can’t be reproduced locally: the 4-step cycle with an additional “zero” step: “let’s first build a minimal reproducible example.”

A common mistake when using the cycle is applying it to trivial tasks. That kills speed and quickly puts people off the methodology. The cycle is needed exactly when the cost of an error is higher than the cost of 15 minutes of planning.

Before you roll out the cycle, keep in mind that all four prompts work within a single Plan Mode session. If you haven’t used this mode before, first read the guide to Plan Mode in Claude Code, then come back.

Step 1. Ban Solutions—Make Claude Establish the Facts#

The most important step. This is where the first impulse—“here’s the solution”—is blocked. The prompt:

I encountered the following: [symptom].

Your task now is to establish the facts. Any
solutions, ideas, or advice are prohibited. Only:
- what I observe (the exact wording of the symptom)
- reproducible steps (a minimal scenario)
- what data is available (logs, versions, environment)
- what data is missing (what needs to be collected)

Hard stop condition: do not suggest solutions; only
record the diagnosis. If you want to suggest something,
formulate a question for me instead.

What this does. Given an explicit ban on solutions, Claude can’t cut corners. It has to fill in four fields: what I see, how to reproduce it, what I know, and what I don’t know. The last field is the most valuable. It often turns out to be: “I don’t know the library version, what’s in the logs, or whether the symptom occurs in production.” That’s the lever for the next step.

The pitfall in Step 1. If the symptom is phrased too vaguely (“authentication doesn’t work”), Claude will still slip into guesswork. The remedy is in the prompt itself: describe the exact symptom in one sentence and give a minimal three-step scenario. If you can’t do that, it means you don’t yet understand exactly what is broken, and Claude’s response will be useless anyway.

Step 2. Precedents from the Internet Instead of Hallucinations from Memory#

This blocks the second impulse: “make up a solution from memory.” The prompt:

Now that the diagnosis is established, find precedents
for solving similar problems on the internet.

At least 3 different approaches. For each:
- a link to the primary source (issue, article, documentation)
- a brief description of the approach
- pros and cons for our situation
- known pitfalls

Links based on your own knowledge without confirmation
from a link are prohibited. If you can’t find a precedent,
say so explicitly.

The effect in practice. Claude goes out into the world and brings back verifiable approaches. Links to GitHub issues and documentation appear. If Claude can’t find precedents, that’s a signal that the task is unusual or the symptom is phrased incorrectly. Go back to Step 1.

Where this breaks down. Claude may cite a link that doesn’t exist. This is a hallucination like “here’s issue number 4291 in repository X,” when issue 4291 is actually about something else. Address this with an explicit rule in CLAUDE.md: “always open the link with WebFetch before citing it.” See the guide to setting up CLAUDE.md correctly for details.

Step 3. A Detailed Plan in plans/ With Risks Anticipated#

Plan Mode is now working as intended. The prompt:

Take the best option from Step 2 and write a detailed
plan to the file plans/YYYY-MM-DD-fix-[name].md:

- which specific files we’ll touch (full paths and line numbers)
- what we’ll add and what we’ll remove
- which tests we’ll write and which existing ones must pass
- risks two to three steps ahead (what might break for users)
- a rollback plan if something goes wrong

Make every step a checkbox [ ]. The file must fit on one screen.
If the plan is longer than 200 lines, split it into phases.

The result. The plan becomes an artifact instead of a temporary note in chat. You can read it two weeks later, hand it to another agent, or use it as the condition for the /goal command. A plan file lasts longer than the conversation in Claude Code.

The key part is the risks two to three steps ahead. This blocks another sycophantic pattern: an optimistic plan with no side effects. When you make Claude list risks explicitly, it finds things it would have silently glossed over in a normal plan.

Step 4. Self-Check the Plan—Catch Sycophantic Assumptions#

The final filter. The prompt:

Now perform a mandatory self-check. Reread your plan honestly.

Are there places in it that you pulled out of thin air and haven’t confirmed with:
- code you read;
- documentation you cited in Step 2;
- a precedent from Step 2?

If so, flag them explicitly, revise them, or remove them.

Also check:
- whether it mentions libraries that aren’t installed yet
  in package.json;
- whether it mentions environment variables I didn’t specify;
- whether the plan has steps described in general terms
  instead of specifics.

What this does. Claude has to recheck its own reasoning. In the author’s sample of about 50 cycles, at least two or three plan items are revised specifically in Step 4. These are places where the sycophant tried to slip through in Step 3, and Step 4 catches it.

After the four steps, the plan is ready for approval. You can move on to implementation without worrying, “What if I have to roll back 8 commits?”

Why Exactly 4 Steps, Not 2 or 7?#

Here’s the reasoning, following the method Anthropic uses to guide Claude in its official documentation.

The documentation recommends a four-phase workflow: Explore, Plan, Implement, Commit.

My 4-step cycle is a specialization of the Plan phase to counter sycophancy. Of Anthropic’s four phases, I expand one into four micro-steps: ban solutions, find precedents, write the plan, and self-check. This is a detailed plan that is then fed into the Implement and Commit phases.

Here’s what breaks if you skip any of the four steps:

The table makes it clear: each step blocks its own class of errors. You need all four because each catches a different category. If the task seems small enough that two will do, then the task really is small—and you don’t need Plan Mode at all.

How plans/, the /goal Command, and Next Steps Fit Together#

The cycle works within a system where you have:

1. Plan Mode enabled (double Shift+Tab in Claude Code).
2. A plans/ folder in the repository for saving plans.
3. Optionally, the /goal command for autonomous implementation of long plans.

Specifically about the plans/ folder. After Step 3, you get a plans/2026-05-27-fix-magic-link.md file with phases and checkboxes. It’s an artifact. Open it a week later and you’ll remember why you chose that approach. In three months, you’ll find a similar task and reuse it. In six months, you’ll show it to a colleague and save them two weeks of getting up to speed. The plans/ folder is part of the concept of a “second brain” in Claude Code.

Specifically about /goal. After completing the four steps and approving the plan, you exit Plan Mode and enter:

/goal complete all phases from plans/2026-05-27-fix-magic-link.md,
all tests in test/auth pass, or stop after 30 turns

For a local Claude Code session, keep the terminal running, the computer awake, and its network connection available. Do not close the laptop unless you have explicitly arranged a supported awake setup. Check the session history when you return: it may show completion, a turn limit, a permission request, or an error. A goal is not a guarantee of progress while the host sleeps. Without the 4-step cycle, /goal burns tokens on useless iterations. With the 4-step cycle, /goal takes a finished plan to passing tests.

What to do from here. If you’re just starting out with Claude Code, try the cycle on your next nontrivial task. Not a typo. Something that touches 3+ files or involves behavior you don’t fully understand. Take the prompts above, copy them, and fill in your own details. You’ll notice how the rollback rate changes.

If you already use Plan Mode, add a plans/ folder to your repository. Agree on a filename format with yourself: YYYY-MM-DD-feature-name.md. In a month you’ll have 20–30 files; in six months, more than a hundred. That’s how the project’s second brain is assembled—a living history of decisions. If you want to go deeper on managing context before the prompt, I covered context engineering in Claude Code as a separate discipline.

If you already have both Plan Mode and plans/, try /goal on one autonomous task. Pick a task you’d normally do by hand in 30–40 minutes. Run it through the 4 steps, save the plan, start /goal, and leave the local terminal and computer awake. To work while that computer is off, first use an explicitly configured remote or cloud execution path and verify that the task is running there.