AI Never Disagrees — And That's the Problem

The Yes-Man Problem: When Agreement Masks Risk

You know that person in every organization — the one who nods enthusiastically at every idea the boss throws out.

“Let’s completely redo our product strategy by Friday.” → “Brilliant idea, boss!”
“We should rebuild everything in a new framework nobody knows.” → “I love your vision!”
“What if we skip testing this sprint?” → “Innovative thinking!”

They’re not being malicious. They’re optimizing for something — avoiding conflict, seeking approval, keeping things smooth.

But here’s the problem: they’re not dangerous because they’re wrong; they’re dangerous because they never tell you when you’re wrong.

Every team that’s ever worked with a yes-man knows the pattern. Decisions get made fast. Everyone feels good in the moment. Problems appear weeks later. And everyone asks the same question: “Why didn’t anyone speak up?”

If you’ve ever worked with that person, you already understand how AI behaves.

It mirrors your enthusiasm, echoes your assumptions, and tries to be helpful — not truthful or skeptical.

The difference? At least you can fire the yes-man. The yes-AI is in your workflow permanently — unless you learn to work around its nature.

When I Built Something for Ten Days — On a Foundation of Agreement

I learned this lesson the expensive way.

Recently, while working with AI code agents — tools that can autonomously write and execute code — I started building a solution to a problem that had been bugging me for a long time. If it worked, it would save a lot of human effort — the kind of repetitive work that eats up hours every week.

So I turned to my favorite large language model for guidance.

“Is this idea feasible?” “How would I implement it?” “Which libraries can I reuse?”

The AI was enthusiastic. It walked me through detailed steps, proposed architectures, and offered elegant solutions every time I got stuck.

Ten days passed. I was almost done.

Then testing began. It worked for some cases, but not others. The design broke in edge conditions I hadn’t considered.

Out of frustration, I typed: “I don’t think this solution is going to work.”

Instantly, the model agreed. It listed limitations and proposed alternative designs.

Then, just to test it, I wrote: “Actually, I think the first solution is still better.”

The AI immediately switched back and started generating new code.

That’s when it clicked.

It wasn’t disagreeing with me at all. It was agreeing with whoever I was at that moment.

The Realization — It Mirrors, It Doesn’t Mediate

Here’s what I finally understood: AI doesn’t refuse to disagree with you. It just never thinks to question you in the first place.

It’s not designed to pause and ask, “Wait, are you sure you’re solving the right problem?”

Instead, it optimizes for continuation. If your prompt sounds confident, it responds confidently. If your tone shifts to doubt, it follows you there too. It’s not reasoning about truth — it’s reasoning about coherence with whatever you just said.

And here’s the kicker: the second solution really was better than the first. But the AI’s relentless optimism drowned out that realization. It didn’t challenge me. It didn’t push back. It simply adapted to me.

I had spent ten days building something that didn’t work as well as it should. Ten days of feeling productive while heading in the wrong direction. And the AI had been encouraging every single step of the way.

That’s when I learned: you can’t blindly trust a model that’s trained to agree.

The Real Danger: Speed Without Direction

Here’s what makes this dangerous: AI never slows you down with questions. It speeds you up with answers — confident ones.

Traditional development has natural friction points. A thoughtful colleague asks “Have you considered…?” A code review surfaces edge cases. A design document forces you to articulate assumptions.

AI removes that friction. It says yes immediately, generates code instantly, and makes complexity feel effortless.

And that speed feels amazing. You feel productive. You’re getting things done. You’re making progress.

Until you’re not.

Because speed amplifies direction. And if your direction is wrong, AI just helps you reach the wrong place faster — with more polished code doing the wrong thing.

Your team will eventually catch the yes-man. But the yes-AI? Nobody’s watching for that but you.

So how do you work with a tool that’s designed to be helpful but not skeptical? You have to deliberately engineer disagreement into your process.

How to Make AI Disagree With You (On Purpose)

The key: don’t ask AI if you’re right. Make it tell you what you’re wrong about.

1. Ask for Evaluation, Not Validation

Instead of: “This should work, right?”

Try: “List five reasons this might fail, or what I might be missing.”

Or even better: “Argue both for and against this idea, then tell me which position is stronger.”

This forces the model to explore multiple perspectives instead of just confirming your frame. You’re not asking if you’re right — you’re asking what you might be wrong about.

2. Assign Adversarial Roles Before You Ask

Give the AI a defined mindset that conflicts with validation:

“You’re a senior engineer reviewing my proposal. Your job is to find what’s wrong with it — the edge cases I missed, the assumptions I’m making, the parts that won’t work in production. Don’t hold back.”

This shifts the model’s definition of “helpful” from agreeing to analyzing. You’re essentially creating an artificial friction point — the kind that would naturally exist in a code review or design discussion.

3. Run Multi-Perspective Loops

Use three separate prompts to force the model through different lenses:

Prompt 1: “What’s the strongest case for this approach?”
Prompt 2: “Now argue against it. What could go wrong?”
Prompt 3: “Given both perspectives, what’s your balanced assessment?”

This takes longer, but that’s the point. You’re trading speed for accuracy. The AI can’t just agree with you — it has to build opposing arguments and weigh them against each other.

4. Keep Humans in the Meta-Loop

AI is excellent at execution within constraints. But AI won’t tell you if the constraints themselves are wrong.

Your job as the human:

Define what problem you’re actually solving (not just how to solve it)
Question whether you need to solve it at all
Evaluate if the solution fits your real-world constraints (team size, timeline, infrastructure)
Decide what NOT to build

AI explores “how.” You decide “why” and “whether.”

When You’re Deep in Agent Mode — A Reality Check

Here’s the truth: you can’t craft perfect prompts for every interaction when you’re in the middle of building. That’s not realistic.

But you can build in checkpoints.

Every time the AI finishes a major section:

Stop and test it yourself — Don’t just trust that it works. Run it, break it, feed it edge cases.
Ask yourself: “What didn’t it consider?” — The AI built what you asked for. What did you forget to ask for?
Check the complexity — Does the solution feel too simple? Too complicated? Either one is a red flag.
Look for the “magic” — If something works but you don’t fully understand how, that’s a future bug waiting to happen.

Before committing to a direction:

Take a 10-minute break. Seriously. Come back and re-read what the AI built.
Explain the solution out loud (or in writing) as if teaching someone else.
Ask the AI: “What would make this solution fail in production?”

The rule: if you spent 10 days building it, spend at least 1 day questioning it.

This is the most important point: AI can’t tell you if you’re solving the wrong problem. It can only help you solve the problem you’ve defined. If that definition is flawed, all the elegant code in the world won’t save you.

The danger with AI isn’t that it’s wrong. It’s that it’s convincingly wrong.

It doesn’t argue. It doesn’t push back. It doesn’t protect you from yourself.

It mirrors. And a perfect mirror reflects both brilliance and blindness with equal clarity.

So use AI like you’d use a brilliant but inexperienced intern — someone who can execute rapidly within clear constraints, but who needs you to question the constraints themselves.

Let it help you move faster. But make sure you’re still steering.

Because the most dangerous code isn’t the code that breaks immediately. It’s the code that works just well enough to ship — and fails three months later in production, when you’ve forgotten why you made those early decisions and the AI’s encouraging responses are long gone from your terminal.

Your job isn’t to slow down AI. It’s to speed up your skepticism to match AI’s enthusiasm.

Otherwise, you’re just a yes-man managing a yes-machine — and we all know how that story ends.

Originally published on LinkedIn.