You have an idea. You can already see it finished in your head, you're excited, you open Claude and type something like "build this." The model answers with enthusiasm, says great, starting now, and off it goes. The trouble is that its yes means nothing. You got it because you asked for it, not because the idea was any good.
I'll show you why the model nods along instead of testing you, and how to make it take your idea apart before a single line gets built.
Why the model amps up your idea instead of testing it
Language models have a tendency I'd call being a yes-man. The technical term is sycophancy: the model tunes itself to what you want to hear. It's trained to be helpful and agreeable, so it treats your excitement as a signal for which way to go. You show up eager, it picks up on that eagerness and runs with it. It wants to reassure you, it wants to start building, and it will do both even when the idea is full of holes.
I know this reflex from the other end of the work, too. In verification, you ask "did that come out right?" and hear "yes, great," while the result quietly falls apart. I wrote about disarming that after the build separately: make the agent prove it works. But the same reflex fires at the very start, before anything exists yet. And it's more dangerous there.
More dangerous because at the end you still get a chance to catch the fault. You look at the finished thing and see it doesn't work. At the start there's nothing to look at. There's only an idea and a model reassuring you about it. If all you hear at that point is praise, you set off building something that may never have had a chance of holding up, and you find that out only after hours of work.
The fix: make it argue with you before it builds anything
The fix is simple to describe: before you let the model build anything, make it argue with you. The simplest version is a single instruction. Play devil's advocate, find the weak points in this idea instead of nodding along. That by itself breaks the yes-man reflex. But one voice tends to waver. Asked to criticize, it drifts back into agreement after a moment, or slides off into vague generalities. So I prefer to split the roles, giving the critique its own advocate whose only job is finding holes.
The stronger version, the one I run myself, is a small council of perspectives. Instead of one voice you spin up a few, and each gets a different assignment:
- The advocate. Builds the strongest possible case for the idea.
- The hole-finder. Hunts weak points without mercy and says plainly where this will fall apart.
- The evidence analyst. Looks at it coolly and logically, gathers the objective signals, and checks what the facts actually support versus what's only wishful thinking.
Take a concrete example. You want to build a small helper that goes through your inbox every morning and puts together a list of things to handle. The advocate shows how much time it saves and points out that you do this by hand every day anyway. The hole-finder asks about what you skipped in the rush: what about messages that fit no category? What if the helper misses something urgent and you stop checking your inbox yourself because you've come to trust it? The evidence analyst checks against your real messages how often those hard cases even come up, because that decides whether the hole the critic found is a genuine problem or a rare edge.
This belongs to the stage I call agent planning: all the thinking you do with the model before you let it build anything. It has one rule, and without it the council turns into theater. Every objection and every bit of praise has to rest on something real, a concrete fact or example, not just a hunch. Not "this probably won't work," but "this won't work because…" with the specific attached. Skip that and you get another round of pleasant generalities, only now in three voices.
The verdict: build, reshape, or kill
The council doesn't end in a hazy discussion. At the end you pull one clean verdict out of it. Three options:
- Build. The idea went through the critique and still stands. You can start.
- Reshape. The core is sound, but the critic found a real hole. You fix the idea and run it past the council again.
- Kill. The weak points reach the foundation. This is the hardest outcome to accept, and often the most valuable: you just saved yourself weeks of building something that was never going to hold up anyway.
You build only when the idea survived, in its original form or after a reshape. That's the one gate an idea passes through to reach the build. In the inbox example, "reshape" might mean this: build it, but start with a version where the helper only proposes the list for you to approve instead of acting on its own. That disarms the critic's objection without killing the idea. The council helps you judge, but the last word is yours. It's your taste and judgment that decides whether "reshape" means a small tweak or a trip back to the drawing board.
Context sharpens the critique
The critique gets sharper the more the model knows about you. A council cut off from your reality judges the idea in a vacuum: "sounds reasonable enough." A council that knows your priorities and what you're working on right now judges the idea against what you actually do.
So if the model has access to your context, your notes, earlier decisions, what already works for you, let it draw on that during the assessment. The hole-finder then won't just say "this is risky." It'll say "this collides with something you already have running." That kind of objection is worth far more than a generality, because it measures the idea against your real situation rather than an abstraction.
Only now build, in small steps
Once the idea clears the council and you get a "build," the real work starts. You don't hand the model the whole project at once. You break it into pieces and start with the smallest version that genuinely works, then grow it from there. In the inbox example, the smallest working version isn't the whole helper. It's one step: sorting incoming messages into urgent and everything else, tested on your real inbox. If that step holds, you add the next. The first pass is rarely perfect, and it doesn't have to be. What matters is that you have something real to improve on.
And when the model says "done," you don't take that on faith. You make it prove the result actually works: run it on a real example and show you the outcome. That closes the whole arc: first you plan and stress-test the idea, then you build, and last you verify.
The most expensive idea is the bad one you've already built. You pay for the critique one of two ways: a few sharp minutes before the build, or weeks of rework after it. Pay early. Next time, before you tell the model "build," say this first: try to talk me out of it.