---
id: "lib-2026-10-28-precedent-or-intent-what-coding-agents-follow"
type: "library"
title: "Precedent or Intent? What Coding Agents Follow When Evolving Existing Code"
lang: "EN"
org: "arXiv"
source_type: "Paper"
date: "2026-10-28"
week: "2026-W44"
url: "https://nosov.ai/library/lib-2026-10-28-precedent-or-intent-what-coding-agents-follow/"
original_url: "https://arxiv.org/abs/2610.38244"
tier: "A"
tier_name: "Strong evidence"
tier_reason: "A UC Riverside and Tulane preprint with bidirectional controlled experiments, 5,625 trials across four coding agents, validation on four open-source repositories and a frank threats section; one task family in the controlled part, but the design isolates each factor cleanly."
summary_basis: "full-text"
original_minutes: "35"
tags: ["ai technology", "coding agents", "context engineering", "agents.md"]
frames: ["tacit-to-explicit"]
---

# Precedent or Intent? What Coding Agents Follow When Evolving Existing Code

Tier A (Strong evidence): A UC Riverside and Tulane preprint with bidirectional controlled experiments, 5,625 trials across four coding agents, validation on four open-source repositories and a frank threats section; one task family in the controlled part, but the design isolates each factor cleanly.

Summary based on the full text.

## In short

A preprint (arXiv, 28 October 2026) by Haichao Zhu, Geyang Xu and colleagues at UC Riverside and Tulane. When a coding agent extends existing code, the old implementation and the new instruction can point different ways: integer or string IDs, one error-handling style or another. The authors measured which one wins. Agents copy what the repository already does almost every time, nearby files matter far more than distant ones, and a new intent needs to be written as an explicit rule; showing an example is not enough.

## Key numbers

- 359/360: trials in which agents followed existing repository code over their own default choice
- 96% ... 4%: adoption with three supporting local files against three files in other parts of the repository
- 59/60 versus 38/60: joint successes with a written priority rule against a code example alone
- 0/120 to 117/120: joint success in open-source repositories before and after a rule in the harness instruction file
- 5,625: trials across four agents and six implementation pairs

## What it reports

- Without relevant examples, all four agents pick the same implementation in each of six choice pairs. When existing code does the opposite, they follow the code in 359 of 360 trials.
- Location beats count: three supporting files for the same resource gave 96% adoption (347/360); three files for other resources gave 4% (13/360). Moving examples between files alone shifted adoption from 0% to 100%.
- To redirect agents against existing code, a written priority rule achieved joint success (works and follows the new intent) in 59 of 60 trials, a code example alone in 38 of 60, no guidance in 0 of 60.
- In four open-source repositories (Python, Go, TypeScript), agents followed local precedent in all 945 classifiable error-handling implementations and in 355 of 417 (85%) response-envelope cases.
- A rule placed in the harness's own instruction file raised joint success there from 0/120 to 117/120.

## How they got it

A purpose-built Python/Flask repository with six two-way implementation choices covering naming, data representation, error handling and control flow. The authors first removed examples to find default preferences, then varied the number and placement of examples, then introduced conflicting rules or examples. Four agents ran each cell 15 times: Claude Sonnet-4-6, Claude Opus-4-8, Codex gpt-5.6-sol and Codex gpt-6-sol. Implementation choice was classified automatically. Findings were then checked in four public repositories.

## Limits

- One task family in the controlled experiments; open-source validation covers two choices, with explicit guidance tested for one.
- Agents from two providers only, and not the newest versions in every case.
- Example count and file placement vary together in part of the design.
- Outcomes measure which implementation was chosen, not maintainability or code quality.
- Instruction-file results test rules the harness loads, not whether agents find rules on their own.

## Why it matters for companies

Coding agents treat the existing codebase as the specification. Legacy patterns will spread unless someone writes down that they should not. The practical step is cheap: keep design decisions and their priority in the agent's instruction file (AGENTS.md or equivalent) rather than hoping a new example in one module will be copied. Migration projects and style changes need explicit written rules, and reviewers should expect agents to replicate the nearest code, good or bad.

Original: https://arxiv.org/abs/2610.38244