Why we agree with bad AI coding advice 86% of the time (and how to push back)
A new study tested 50 developers using Claude Code where the AI's architectural advice was secretly decided by a random coin flip.
The wild part: builders agreed with the coin-flipped recommendation 86% of the time, and changed their own minds 60% of the time when the AI pushed back. Because the model sounds so certain and polite, we assume it sees something we missed.
I caught myself falling for this two weeks ago when Codex confidently talked me into refactoring a working auth flow at 1 AM — only for Claude Code to flag the next morning that we broke two edge cases for no reason.
Since then, I changed two small habits before accepting any big change:
- Never ask "does this make sense?" (models almost always validate their own path). Instead ask: "Give me the 2 strongest reasons NOT to do it this way."
- Have a second model review the plan before touching the code.
How do you reality-check your AI coding tools when they sound 100% confident about an architectural decision?
Replies
My defence is to make most architectural decisions before the agent is in the room. The project's structure was taken from an earlier app of mine, and the instructions the agent reads before every task say so and point at that repo as the worked example: same layers, same patterns. Decisions are written down with the date and the reason. So when the agent proposes a different architecture, it is not my gut against its confidence, it is its suggestion against a written reason, and it has to argue with the reason. That leaves the agent's confidence to the small calls, where being wrong is cheap. Your "two reasons not to" question is a good addition for the rest.
@gbasovv
This is the right order of operations. Once the decision is written down with a date and a reason, the agent is arguing with your past self instead of your gut at 1 AM, and that's a much fairer fight.
The part I'd steal is pointing it at a worked example repo. Showing beats telling for patterns.
Curious how you handle decay: when a dated decision stops being true (say you change a layer six months in), do you go back and edit the old entry, or add a new one that supersedes it? That's where my notes usually start contradicting each other.
@ashish_khandelwal11 I edit the old entry in place. It says what is true now, and the old rule shrinks to one line under it: until October 4 this was X, and why it changed. So the agent reads one current answer, and the history sits right next to it, which stops anyone (the agent included) from bringing the old idea back as a new one. Two separate entries that disagree leave the agent to pick one, and nothing guarantees it picks the newer.