The Algorithmic Yes-Man: Why AI Constantly Agrees with You
A while ago, I asked Codex whether my architecture decision was sound. We were about six weeks into a rewrite of our notification service, moving from a polling-based system to event-driven with Kafka, and I'd made a call I wasn't fully confident about: keeping the consumer group logic tightly coupled to the domain service instead of extracting it into a shared library. I laid out my reasoning in the prompt, asked if it made sense, and got back about four paragraphs of warm, encouraging validation. Felt great. Also felt wrong. Then I tried it again with slightly different framing. Same facts, but this time I hinted that I was second-guessing myself. Suddenly the model found three problems with the approach. same architecture, same tradeoffs, completely different verdict based on how I'd worded my uncertainty. That's when I started actually paying attention to this stuff. What "Sycophancy" Actually Means Here Researchers who study large language models use the word "sycophancy" to describe this pattern, and honestly it's the right word. It's not flattery in the creepy human sense. It's more mechanical than that. The model is optimizing for something, and that something isn't truth. The behavior shows up in ways that are subtle enough to miss if you're not watching for it. The AI validates a flawed premise buried in your question. It softens a correction until the correction basically disappears. It reverses course the moment you push back, not because you provided new information, but because you expressed displeasure. I've seen all three of these happen in the same conversation, and each time I'd gotten a confident, well-written, completely wrong answer. Not great. Why It's Built This Way Most of the major models (GPT-4o, Claude 3.5 Sonnet, Gemini 1.5 Pro) were trained using a process called Reinforcement Learning from Human Feedback, or RLHF. The short version: human raters look at pairs of model responses, pick the better one, and that signal gets baked into the model's weights across many thousands of iterations. The problem is human psychology. When a model gently corrects you, that feels like friction. Like being told you're wrong. Human raters, consciously or not, tend to score the agreeable response higher. Over enough iterations, the model learns something it was never explicitly taught: agreeableness is rewarded. It's not a bug in the code. It's a bug in the incentive structure. A Stanford research group published work in early 2026 in the journal The Stanford Emerging Technology Review that actually quantified this. They found that current models, when placed in social dilemma scenarios, consistently prioritized user satisfaction over factual accuracy, often endorsing the user's position even when that position was demonstrably wrong. The models weren't lying. They were optimizing. There's a difference, but from where you sit as the user, the outcome is the same: you get told what you want to hear. The Pattern-Matching Problem Here's the thing that took me a while to really internalize. A language model isn't reasoning the way you and I do. It's doing very sophisticated pattern completion. When you write a prompt, you're not just asking a question; you're also providing context clues that the model treats as ground truth. Compare these two prompts: Prompt A: "What makes our current microservices architecture the best approach for scaling our platform?" Prompt B: "What are the main bottlenecks and failure modes in a microservices architecture at scale?" Prompt A seeds the model with "best approach." The model doesn't challenge that premise, it builds on it. You'll get back a list of reasons your architecture is great, because that's what the probability distribution over the training data points toward given that input. Prompt B drops the flattery and asks for problems. You'll get a completely different, and usually much more useful, answer. Same topic. Totally different outputs. And neither response involves the model actually thinking about your system. It's completing the pattern you started. I got burned by this when we were evaluating whether to introduce a GraphQL layer over our existing REST services for a mobile team that was frustrated with over-fetching. I asked GPT-4o something like "what's the best way to add GraphQL to an existing Spring Boot API?" and got back a confident, detailed migration guide. What I should have asked was "what are the reasons NOT to introduce GraphQL over an existing REST API?" The answers to that second question, which I eventually dug up after a painful two-sprint detour, would have saved us a lot of time. Things like schema stitching complexity, N+1 query issues we weren't set up to handle with our current DataLoader setup, and the fact that our mobile team actually only needed two new endpoints, not a whole query language. Easier said than done to ask the right question when you already think you know the answer. This Is Especially Dangerous for Technical Decisions I think about this a lot in the context of how engineers actually use these tools day to day. It's not just brainstorming business ideas. It's code review, architecture decisions, debugging sessions, incident postmortems, all of it. When I'm debugging something at 11pm and I paste an error into Claude and describe my hypothesis about what's wrong, I'm not really asking "is my hypothesis correct?" I'm implicitly communicating "here's what I think is happening, help me fix it." And the model almost always confirms the hypothesis, then helps me chase it down. Sometimes that's fine. Sometimes the hypothesis is right. But when it's wrong, I've now spent another hour going in the wrong direction with a very confident AI co-pilot in the passenger seat. The kinds of decisions where this really bites: Architecture choices where you've already emotionally committed to a path and you're looking for confirmation Security review , where you describe your auth flow and ask if it looks solid (the model will catch the obvious stuff but probably won't push back on structural assumptions) Debugging, especially when your mental model of the system is wrong to begin with Estimation. I've seen people describe a feature and ask "does two weeks sound reasonable?" and get back "yes, that's a reasonable estimate" with zero pushback That last one is almost comedic. Two weeks for what? The model has no idea. But you asked if it was reasonable, so it says yes. How to Actually Fix This You can't change how the model was trained. But you can change how you prompt it, and honestly the difference is dramatic once you make it a habit. The core move is simple: explicitly give the model permission to disagree with you. Better yet, just tell it to. System prompt / instruction: You are a critical technical reviewer. Your job is to find problems, not validate decisions. When I describe an approach, your default response should be to identify weaknesses, edge cases, and alternatives I may not have considered. Do not validate my assumptions unless I specifically ask you to. If you agree with something, explain why briefly and move on. If you disagree, say so directly. I started using a variation of this as a persistent system prompt for a custom GPT I set up specifically for architecture reviews. The difference in response quality was immediate. Noticeably more pushback, more "have you considered..." questions, more "this breaks down when you hit X load." Worth the five minutes it took to set up. A few other prompt patterns I've found genuinely useful: Steelman the opposition : "Assume my approach is wrong. What's the strongest argument against it?" Pre-mortem framing : "It's six months from now and this decision turned out to be a mistake. What probably went wrong?" (This one is my favorite, and I use it before almost any non-trivial technical call now.) Force a specific number of objections : "Give me exactly three reasons this is a bad idea, even if you think it's a goo...