Skip to content
AI-Native PM
Field Notes

Field Note

Why We Told the AI to Disagree With Us

The most useful instruction we gave the assistant building this site was not a task. It was a standing permission to disagree, because a collaborator who only ever says yes tells you nothing.

· 5 min read

The most useful instruction we gave the assistant building this site was not a task at all. It was a standing permission to disagree. Over and over, in different words, we gave the same direction: vet this thought and push back if it does not hold; give the right advice regardless of what I just said I wanted; if something is unclear or you see a better path, raise it before you act.

That instruction matters because a helpful assistant, by default, does the opposite. Left alone, it tends to take the request as given and produce a competent version of exactly what was asked, which is wonderful until the request itself is the weak part. When you are making real decisions, a collaborator who only ever agrees is not safe, because you learn nothing from its agreement. You cannot tell the difference between a good idea and a bad one if the response to both is yes.

Ask for the plan and the objections togetherA request on the left leads to the assistant, which returns two things: a proposed plan and a list of objections to that plan. Both lead to the person, who decides with the counterargument already in hand. Caption: we asked it to argue against the plan, not just produce one.THE INSTRUCTION: TELL ME WHEN I’M WRONGThe requestClaude, ascollaboratorThe planwhat it proposesThe objectionswhy it might be wrongYoudecideWe asked it to argue against the plan, not just produce one.

A useful AI collaborator is one you instruct to argue against the plan, because its default is to agree, and when it only says yes you never hear the objection you needed.

We saw the benefit in exactly the places where we had given that instruction. When we leaned toward deleting the References section of the site, the assistant did not just delete it; it wrote out the case for keeping the section, and we had to decide on the merits rather than on impulse. When we proposed a new term for the core framework, the assistant did not apply it right away; it checked the name against existing uses for collisions first, so we changed the term knowing what we were choosing. In both cases the objection was the useful part, not the compliance. If it had simply agreed, we would have felt better and learned nothing.

Setting this up is a matter of asking for the right output, not hoping for a mood. Ask for the counterargument by name: what is wrong with this plan, where does it break, what would a skeptic say. Ask for the objections alongside the proposal, so you see both at once instead of a clean recommendation with its doubts hidden. Tell it to ask a question when the request is ambiguous rather than guess and proceed. The instruction is to argue and to ask, and the result is that the decision stays yours, made against the strongest version of the other side rather than a polite silence.

Where this goes next

Keeping a person at the point of decision, with the machine arguing rather than deciding, is the supervision principle we build on in our essay The Human Factors, and we return to it throughout the human-factors part of The Builder's Stack. The same instinct, never trusting a single confident output, is the subject of How We Caught AI Mistakes With a Second Agent.

Sources