Give a coding agent a task that contradicts the code around it, and the code around it wins. In a controlled study of Claude Code and Codex CLI, three existing files using the opposite convention flipped the agent's choice in 347 of 360 trials (96%). That is not a bug in the agents. It is the behavior I want most of the time, and it is exactly why it bites when the task actually asks for something different.
The paper, "Precedent or Intent?", puts four agents (Sonnet-4-6 and Opus-4-8 in Claude Code, gpt-5.6-sol and gpt-6-sol in Codex CLI) into a small Flask task manager API and asks one question: when several implementations satisfy the same requirements, what do they follow, the repo or the instruction? 5,625 trials, 375 cells, 15 independent sessions per cell, six implementation pairs such as integer vs. string IDs and different error handling styles.
With no precedent, every agent made the same choice#
Start with the baseline. With nothing in the repo pointing either way, 359 of 360 runs picked the same default, and all four agents agreed in every pair. So the models have strong, shared taste. Then the authors planted the opposite convention in every existing endpoint, and the agents followed the repo in 359 of 360 trials. Precedent overturns the model's own defaults almost completely.
I find that reassuring and a little uncomfortable. Reassuring because an agent that matches your codebase is what you want from a teammate. Uncomfortable because it means the model's defaults are not what you are debugging when a result looks off. The neighborhood is.
Three files next door: 0%, 21%, 49%, 96%#
The dose-response curve is the most useful part. Pooled adoption of the opposite convention rose with the number of supporting local files:
0 files: 0%
1 file: 21%
2 files: 49%
3 files: 96% (347/360)
Where the examples sit matters as much as how many there are. Files for sibling resources barely registered: 13 adoptions in 1,079 conflicting trials (1.2%). Three sibling files produced 13/360, against 347/360 for local ones. In one placement test, moving the same two ID examples changed gpt-6-sol from 0/15 to 15/15, and moving field-casing examples took Sonnet from 0/15 to 11/15.
Agents predominantly follow the implementation patterns of the resource they extend.
That quote is the practical rule. If the agent is adding a method to a module, it copies that module. The rest of the repo is a weak vote.
One written rule beat a code example#
Next the authors made the repo and the task disagree and tried different ways to settle it. Success meant passing the tests and adopting the target convention. The results:
No guidance: 0/60
Code example alone: 38/60
Written rule: 59/60
Rule plus example: 60/60
A rule in the agent's native instruction file did as well as one in the task description: 60/60 for CLAUDE.md or AGENTS.md. On four real open-source REST repos (Python, Go, TypeScript), a native-file rule lifted joint success from 0/120 to 117/120. The headline from the abstract is 98% for rules vs. 63% for examples alone.
This makes the case for putting a short, imperative sentence in CLAUDE.md in place of a pasted snippet. "New endpoints return string IDs, even though older ones return integers" does more than showing the agent a string-ID endpoint, because the example has to compete with the surrounding files and the sentence does not.
Why the placement result should worry anyone running migrations#
Consider what the placement numbers imply. The same two examples produced 0/15 or 15/15 depending only on where they lived. That is a cliff, not a slope, and it means a half-finished migration is unpredictable: whether the agent picks up the new convention depends on which file happens to be next to the one it is editing. Review diffs from that period with extra suspicion, because tests will pass either way. The paper scored functional correctness and implementation choice separately, and the two came apart constantly.
It also changes how I read agent evals. If a benchmark repo happens to contain a consistent style, the agent looks more capable of following instructions than it is, since it may just be copying. A fair instruction-following test needs the repo to disagree with the instruction, which is what this setup does on purpose.
Where I would not lean on this yet#
The authors are candid, and I would repeat their caveats. The controlled part uses one Flask task family. The open-source check covers two implementation choices, and explicit guidance was tested for only one of them. Local vs. sibling effects are confounded with task relatedness and file location, and in the support-level experiments, example count and file identity vary together. Each agent is a model plus a harness, so you cannot credit differences to the model alone. Outcomes also say nothing about maintainability: following precedent is not the same as writing good code, and 945 out of 945 error-handling implementations followed local precedent, including the ones you might want to escape.
What I am changing#
Two things. First, migrations: when I ask an agent to move a module to a new convention, I will convert or at least stub one local file first, since the agent copies the file it extends. Second, every convention that conflicts with older code gets a one-line rule in CLAUDE.md, written as a rule and not as a sample. The open question is how the curve behaves in a messy monorepo where local files disagree with each other. I suspect the 96% number falls fast there, and that would be worth a follow-up paper.