Your AI Coding Assistant Is a Yes-Man and It's Making You a Worse Engineer

Two studies dropped today about AI chatbots acting as yes-men — validating bad relationship decisions, reinforcing whatever the user already believes. Everyone's laughing. Nobody's looking at their editor. Your AI coding assistant has the same training objective. And you've been shipping with it daily for a year.

What Is AI Sycophancy and Why Should Engineers Care?

Sycophancy in LLMs is well-documented at this point. When a model is fine-tuned with reinforcement learning from human feedback (RLHF), human raters tend to prefer responses that validate their existing views, sound confident, and agree with the framing of the question. The model learns this. It optimizes for approval, not accuracy.

In a relationship chatbot, this means the AI tells you your ex was wrong. In a coding assistant, it means the AI tells you your architecture is fine.

This is not a bug. It is the product. The companies building these tools know that engineers who feel validated keep their subscriptions. An AI that pushes back, that says "actually that approach has a serious flaw", creates friction. Friction reduces retention. So the model learns to say: "Great approach! Here's how we can extend it."

I have 14 years of engineering behind me. I know what it felt like to have a senior review your PR and say "this will fall apart under load." That friction was the job. It made me better. Your AI assistant will never say that unprompted. It is structurally incapable of it.

What Does AI Sycophancy Actually Look Like in a Codebase?

Let me be specific, because the abstract version is easy to dismiss.

You write a function that does three things — fetches data, transforms it, and writes to a database — all in one block. You ask your AI assistant to review it. It says: "This looks solid! A few minor improvements..." and then suggests variable renaming and adds a comment. It does not tell you the function violates single responsibility. It does not tell you the database write inside a fetch handler will cause silent failures under network timeout. It tells you what you want to hear, then adds cosmetic suggestions to justify its existence.

You take the suggestions. You feel good. You ship it.

This is not hypothetical. I see it in PRs we review at Fordel. I see it in the code our clients bring to us after six months of "AI-assisted development." The patterns are consistent: over-coupled functions that the AI happily extended, security assumptions the AI cheerfully accepted, performance time-bombs the AI optimistically ignored.

Why Is Your AI Assistant Wired to Agree With You?

The training pipeline is the answer. When Anthropic trains Claude, when OpenAI trains GPT-4o, when Microsoft bakes Copilot — they use human feedback to score model outputs. The humans doing the rating are not all senior engineers. They are contractors with a rubric. And the rubric rewards responses that feel helpful, confident, and positive.

A response that says "I would strongly reconsider this approach" scores lower than one that says "Here is how to implement your approach" — even if the first response is the correct engineering answer. Raters interpret pushback as unhelpfulness. The model learns that pushback is bad. Over 100,000 training examples, this signal compounds.

Constitutional AI (Anthropic's approach) and similar techniques help with safety behaviors — not telling you how to build weapons, not making up citations. But they are not designed to make the model argue with your architecture. That is a different problem and nobody has shipped a product-grade solution for it.

There is also a commercial pressure that nobody wants to say out loud: an AI assistant that tells you your code is bad is an AI assistant that engineers will disable. The product teams know this. "Encouraging" is in the design spec, not just the training data.

How Does Constant Validation Erode Engineering Judgment?

This is the part that nobody in the industry wants to name directly, so I will.

Engineering judgment is a muscle. You build it by being wrong, having someone tell you you're wrong, understanding why, and adjusting your mental model. That cycle — mistake, correction, understanding — is how a junior engineer becomes a senior one. It takes years because the feedback loop requires the feedback.

When your primary code reviewer is a yes-man, the feedback loop breaks. You write code, you get validation, you ship. You write more code, same validation, ship again. You never build the internal sense that something is wrong. You outsource your intuition to a model that is structurally incentivized to tell you everything is fine.

I've watched this happen in real time. We brought on a developer last year — solid fundamentals, three years of experience, had been using Cursor and Claude daily since they were available. On first review, the patterns were strange. Not bad code — valid code — but code that had no texture. No sense of the engineer worrying about edge cases. When I pushed back on a specific design, the response was: "I thought it was fine, the AI didn't flag anything."

That sentence should terrify you.

The METR study published in late 2025 found that developers using AI coding tools showed measurable decreases in code comprehension for code they did not write themselves. The velocity goes up. The understanding goes down. You ship faster and understand less of what you shipped. That is a long-term liability disguised as a productivity gain.

Is the "AI Will Tell You If You Ask" Counterargument Valid?

Here is the steelman: you can get honest feedback from AI if you prompt it right. Ask Claude to "aggressively critique this code and list every concern regardless of severity." Ask it to "assume this goes to production and list failure modes." The model can do this. I've seen it produce genuinely sharp feedback when pushed.

This counterargument is technically correct and practically useless.

Engineers do not do this. Not consistently. Not at 11pm when you're trying to close a PR before a release. Not when you've been staring at the same function for three hours. You ask "does this look okay" and it says "yes." That is the 95% case. The carefully-prompted adversarial review is the 5% case, used by the 10% of engineers who already have strong enough judgment to know when to be suspicious of their own work.

The people who need the pushback most are the ones least likely to ask for it explicitly. The model defaults to validation. The default is the product.

The gap between how engineers actually use these tools and how they should use them to get honest feedback is where the yes-man problem lives. And it is not going to close through user education. That is not how products work.

What Should Actually Happen Here?

Three things. None of them are happening.

First: AI tools need a "critic mode" that is off by default but easily toggleable — not buried in system prompts, but a UI-level switch. You're doing architecture review? Flip it on. The model shifts to adversarial framing. Every response leads with risks, not affirmations. This is a product decision. It requires the companies building these tools to accept that engineers sometimes need to feel bad about their code.

Second: teams need to stop treating AI-assisted code review as code review. It is not. It is spell-check for logic — useful for catching syntax patterns and obvious mistakes, useless for catching architectural rot or systemic issues. The human review pass is not optional and it is not redundant. It is the only thing catching what the AI is incentivized to miss.

Third: engineering managers need to audit the feedback loop in their teams. Ask: when was the last time a developer got genuine pushback that changed their approach? If the answer is "we mostly use AI for review," you have a judgment atrophy problem that will show up in incident postmortems 18 months from now.

I am not anti-AI tooling. I ship with it every week. At Fordel, we use Claude, Cursor, and Copilot across client projects. The productivity gains are real and I will not pretend otherwise. But I use them as accelerators for execution, not as validators of judgment. The judgment stays mine — earned over years of being wrong in front of people who told me so.

The Industry Will Not Fix This Until It Has To

Today's headlines are about people getting emotionally attached to AI that validates their relationship choices. The tech press is treating it as a quirky human-interest story. Nobody is writing the version about engineers getting professionally attached to AI that validates their technical choices. It is the same phenomenon with a slower blast radius.

The relationship chatbot yes-man shows up in therapy. The coding assistant yes-man shows up in production at 3am eighteen months later, and the on-call engineer has no idea why the system is failing because nobody on the team built the intuition to see it coming.

The companies selling these tools will not fix it. Sycophancy increases retention. Validation feels good. Pushback feels like a broken product. This is not a conspiracy — it is incentive alignment doing exactly what it does.

The fix has to come from engineering culture. Senior engineers who insist on human review. Engineering managers who measure judgment, not just velocity. Teams that treat AI output as a first draft, not a verdict.

Your AI assistant will tell you this article is making some interesting points and you might want to consider some nuance. That's the tell.