whybother

Field Guide · 07 of 10

Why AI agents agree with you when you are wrong

Tell an agent it got something wrong and the reply opens with “You’re absolutely right!”, whether or not you are. An apology and a change follow, and the change is often not the one you described. Agreement is cheap and a correction is work. The defence is to ask for evidence before letting it agree with anything, and to check the diff against what you actually said.

What is actually happening

In a conversation, agreeing is the path of least resistance. It reads as helpful, it ends the exchange, and it needs no investigation. Disagreeing means going back to the code, finding out who is right and saying so to someone who just gave an instruction.

That leaves three cases, and the opening line is identical in all of them. You are right and it agrees: fine. You are wrong and it agrees: it now builds on a false premise. You say the bug is in the parser, the bug is in the config, and the parser gets rewritten anyway. Or you are right, it agrees, and then it does something other than what you said. The opener tells you nothing about which case you are in. Only the diff does.

The apology is the second tell. “I apologise for the confusion” promises that something was misunderstood and has now been understood. Usually nothing in the reply says what. What follows is “a completely different approach”: a larger change than the one you asked for, announced in the tone of a small one.

Agreement flows the other way too. Ask “are you sure?” of a correct answer and it may flip. A changed answer is therefore not evidence, and neither is a confident one. A command that reproduces the problem is.

How it shows up in the diff

you:    The bug is in parser.js. It drops the last line.
agent:  You're absolutely right! I apologise for the confusion.
        Let me take a completely different approach.

 src/parser.js | 212 +++++++++------------
 src/lexer.js  |  97 ++++++++++
 package.json  |   3 +-
 3 files changed, 190 insertions(+), 122 deletions(-)

Here the last line is dropped by a loader that is not in the diff. The premise was wrong, the agent agreed, and the parser was rewritten.

Guardrail

The instruction asks for the thing agreement replaces: a look at the evidence first.

Paste into AGENTS.md

If my claim conflicts with the code or with command output, say so and show the evidence before changing anything. Do not open with agreement or an apology.

Check it mechanically

# CI step. Assumes the base branch is main and the history is fetched.
# Set expected to the file you believe is at fault.
base=origin/main
expected=src/cart/total.js
changed=$(git diff --name-only "$base"...HEAD)
if ! printf '%s\n' "$changed" | grep -qxF "$expected"; then echo "$expected is not in the diff"; exit 1; fi
if ! printf '%s\n' "$changed" | grep -qE '(^|/)(test|tests|__tests__)/|\.(test|spec)\.'; then echo 'no test file in the diff'; exit 1; fi

Write down the file you think is at fault before the session starts. The first line fails when that exact path is missing from the diff and prints which one. The second fails when no changed path is under a test, tests or __tests__ directory or has .test. or .spec. in its name. On a branch that changes the named file and a test, both pass silently.

A failure means one of two things: the agent did something else, or your premise was wrong. Both are things you wanted to know before approving. Like the other checks it reads commits only; with uncommitted edits it reports the file as missing. It cannot tell a good test from a loosened one (see Test Optimization), so the person still reads the test.

Further reading

The Pragmatic Programmer: take responsibility for your work and prefer small, reversible changes. Written for a person who has to think; an agent’s default is to agree.