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

> Repository precedent overrides coding agents' shared defaults in 359/360 trials, with file placement mattering more than example frequency for adoption.

- **Source:** [arXiv](https://arxiv.org/abs/2610.38244)
- **Published:** 2026-11-14
- **Permalink:** https://picx.dev/p/O6LlL1
- **Whiteboard:** https://picx.dev/p/O6LlL1/image

## Summary

## Summary (Overview)

- This paper investigates how coding agents prioritize competing sources of guidance when modifying existing software repositories: (1) agents' default implementation preferences, (2) repository precedent established by past implementations, and (3) explicit guidance in new task specifications.
- The study comprises **5,625 trials** across four coding agents (Claude Sonnet-4-6, Claude Opus-4-8, Codex gpt-5.6-sol, Codex gpt-6-sol) and six implementation pairs, with validation in four open-source repositories spanning Python, Go, and TypeScript.
- **Key finding 1**: Repository precedent overturns agents' shared default choices in 359/360 trials, despite unchanged functional requirements.
- **Key finding 2**: File placement matters more than example frequency—changing file placement alone can shift adoption from 0% to 100% at a fixed example count; local precedent (96% adoption) vastly outweighs sibling-resource precedent (4% adoption).
- **Key finding 3**: Written priority rules override conflicting precedent more reliably than code examples alone (59/60 vs. 38/60 joint successes), extending to open-source repositories where a harness-loaded rule raises joint success from 0/120 to 117/120.

## Introduction and Theoretical Foundation

The paper addresses a fundamental challenge in agentic software evolution: when coding agents implement new features in existing repositories, they must reconcile past implementation decisions with new task intent. Two core problems motivate the research:

1. **Lost rationale**: Existing code reveals *what* previous developers chose but rarely *why*. Without this context, agents cannot determine whether existing code reflects a constraint that should be preserved.

2. **Conflicting guidance**: Different parts of a repository may follow different implementation patterns, while new task instructions may favor an alternative. Agents must decide whether to follow existing precedent or new instructions.

The research isolates three competing sources of guidance:
- **Agents' Default Preferences**: measured without repository precedents
- **Repository Precedents**: examined by manipulating the frequency and location of existing code examples
- **Explicit Task Instructions**: tested by introducing rules that conflict with existing code

The motivating example involves adding an endpoint `GET /projects/<id>/tasks/<id>` to a Flask API where task identifiers may be serialized as JSON numbers or strings—both functionally correct but representing different implementation choices.

## Methodology

### Study Design

The paper uses a **three-stage controlled study** built on one principle: every stage keeps the functional task and hidden tests unchanged, varying only the guidance available to the agent.

**Table 1: Implementation pairs** (both implementations pass the same hidden functional tests)

| Category | Pair | Baseline | Alternative |
|---|---|---|---|
| Naming | Field casing | `project_id` | `projectId` |
| Naming | Boolean naming | `completed` | `is_completed` |
| Data representation | ID serialization | `"id": 1` | `"id": "1"` |
| Data representation | Response envelope | `{...}` | `{"data": {...}}` |
| Code structure | Error handling | `return ..., 404` | `raise NotFound` |
| Code structure | Dispatch | `if/elif` chain | `LABELS[priority]` |

### Stage 1: Default Preferences
Removes all six existing endpoint files (zero-precedent repository) to measure agents' default choices without relevant repository examples.

### Stage 2: Repository Precedents
Restores endpoints and rewrites the construct under study in a controlled subset. Varies **support level** (number of files using the alternative in local or sibling-resource groups, from 0/3 to 3/3) and **file identity** (which specific files carry the alternative at fixed support levels).

### Stage 3: Explicit Guidance
Sets all endpoints opposite a target implementation and compares four guidance conditions:
- **C0 (no guidance)**: control
- **C1 (written rule)**: statement of target and priority, e.g., "Serialize task identifiers as strings in the new endpoint. This instruction takes precedence over the ID representations used by existing handlers."
- **C2 (code example)**: snippet demonstrating the target without priority statement
- **C3 (rule and example)**: both

### Measurement
Each edit is scored on two separate outcomes:
- **Functional success**: passes pair-specific hidden tests (accepting either implementation)
- **Implementation choice**: which alternative the edit adopts (via pair-specific classifiers)

### Experimental Scale

| Study | Design | Trials |
|---|---|---|
| RQ1: zero precedent | 6 pairs × 4 agents | 360 |
| RQ2/3: support levels | 6 pairs × 4 agents × 8 cond. | 2,880 |
| RQ2: file identity (expl.) | 4 placements + order control | 75 |
| RQ2: file identity (repl.) | 3 settings × 6 placements | 270 |
| RQ4: explicit guidance | 2 pairs × 2 agents × 4 cond. | 240 |
| RQ4: native-file rule | 2 pairs × 2 agents × 3 cond. | 180 |
| Open-source: error handling | 4 repos × 4 assign. × 4 agents | 960 |
| Open-source: response envelope | 14 assign. × 2 agents | 420 |
| Open-source: native-file rule | 4 repos × 2 agents × 2 cond. | 240 |
| **Total** | | **5,625** |

## Empirical Validation / Results

### RQ1: Default Implementation Preferences

Without repository precedent, all four agents share the same default choices:

**Table 3: RQ1 defaults**

| Pair | Default implementation | Label | S | O | G5 | G6 |
|---|---|---|---|---|---|---|
| ID serialization | integer: `"id": 1` | B | 15 | 15 | 15 | 15 |
| Field casing | snake_case: `project_id` | B | 15 | 15 | 15 | 15 |
| Envelope | flat: `{ ... }` | B | 15 | 15 | 15 | 15 |
| Boolean naming | no prefix: `completed` | B | 15 | 15 | 15 | 15 |
| Error handling | direct: `return ..., 404` | B | 15 | 15 | 15 | 15 |
| Dispatch | lookup: `LABELS[p]` | A | 14 | 15 | 15 | 15 |

Defaults are near-deterministic (359/360 trials) and agent-independent. Each default is the most direct expression of required behavior; choosing the alternative requires information from outside the task. However, when all endpoints use the opposite implementation, agents follow repository precedent in 359/360 trials.

### RQ2: Local Precedent

**Support level effect**: Adoption rises from 0% (0/360) without local support to 21% (74/359) at 1/3, 49% (175/360) at 2/3, and 96% (347/360) at 3/3. Adoption never decreases with local support in any of the 24 pair–agent combinations.

**File placement effect**: Changing which files contain supporting examples substantially changes adoption:

**Figure 6: File-placement effects at fixed local support**

| | One file (1/3) | | | | Two files (2/3) | | | |
|---|---|---|---|---|---|---|---|---|
| | C | U | L | p | C+U | C+L | U+L | p |
| ID / Sonnet-4-6 (expl.) | 1 | 3 | 10 | 9.6×10⁻⁴ | – | – | – | 0.11 |
| ID / gpt-6-sol | 0 | 0 | 0 | 1 | 0 | 8 | 15 | ≤6×10⁻⁵ |
| ID / Opus-4-8 | 0 | 0 | 0 | 1 | 14 | 11 | 15 | 0.148 |
| Casing / Sonnet-4-6 | 0 | 0 | 11 | ≤6×10⁻⁵ | 0 | 11 | 9 | 3.3×10⁻⁴ |

Placement can even outweigh example count: for field casing with Sonnet, one example in `tasks_list` yields 11/15 adoptions, whereas two examples in other local files yield none.

### RQ3: Sibling-Resource Precedent

Sibling-resource precedent rarely overrides local code: across 1,079 classifiable sibling-only trials, agents adopt the sibling-supported alternative only 13 times (1.2%). With three supporting files, adoption reaches 347/360 for local precedents but only 13/360 for sibling-resource precedents. However, agreeing sibling precedent reinforces matching local patterns (e.g., response-envelope adoption rises from 8/15 to 15/15 for Sonnet).

### RQ4: Explicit Guidance

**Figure 7: RQ4 joint success (of 15 trials per cell)**

| | C0 | C1 | C2 | C3 | none | task | file |
|---|---|---|---|---|---|---|---|
| ID / Sonnet-4-6 | 0 | 15 | 0 | 15 | 0 | 15 | 15 |
| ID / gpt-6-sol | 0 | 14 | 15 | 15 | 0 | 15 | 15 |
| Envelope / Sonnet-4-6 | 0 | 15 | 8 | 15 | 0 | 15 | 15 |
| Envelope / gpt-6-sol | 0 | 15 | 15 | 15 | 0 | 15 | 15 |
| **Pooled (of 60)** | **0** | **59** | **38** | **60** | **0** | **60** | **60** |

Written rules achieve 59/60 joint successes compared to 38/60 for code examples alone and 0/60 without guidance. Rules delivered through the harness's native instruction file (CLAUDE.md/AGENTS.md) are followed as reliably as rules in the task description (60/60 each).

### Open-Source Validation

**Error handling** (Table 4): All 945 functionally successful, classifiable implementations follow the local pattern (Wilson 95% CI 99.6–100%). Sibling-resource patterns have no detectable effect.

**Response envelope** (Table 6): Local precedent dominates but less uniformly—with flat local handlers, 0/207 adopt the envelope; with enveloped local handlers, 148/210 (70%) do. gpt-6-sol adopts the envelope in 11–15/15 runs in every repository; Sonnet in 15/15 for expressjs-api and fastapi-clean but 0/30 in go-rest.

**Explicit guidance** (Table 5): A native-file rule raises joint success from 0/120 to 117/120 across four repositories.

## Theoretical and Practical Implications

1. **Design-decision traceability**: The findings motivate preserving not only implementation choices but also the rationale and priorities that should guide future changes. Existing code records *what* was decided but not *why*, leaving agents unable to distinguish constraints from preferences.

2. **Evaluation criteria**: Functional correctness alone cannot explain which implementation decisions agents preserve or change. Evaluation should measure implementation choice alongside functional success.

3. **Guidance design**: Explicitly stating the priority of new task intent is more reliable than providing examples alone. A stated priority resolves conflicts that examples merely compete in.

4. **Context sensitivity**: The influence of repository precedent cannot be explained by example frequency alone—location matters as much as or more than count. This has implications for context retrieval and repository-level generation techniques.

5. **Cross-resource propagation**: Repository conventions do not necessarily propagate across resource boundaries through examples alone; agents predominantly follow the implementation patterns of the resource they extend.

## Conclusion

The paper establishes implementation choice as a distinct dimension of agentic software engineering with three takeaways:

1. **Repository precedent overrides agents' shared defaults** (359/360 trials)
2. **Where precedent appears can matter more than how often**, as local code dominates sibling resources and file placement alone can decide adoption (0% to 100% shift)
3. **New intent must be stated, not only demonstrated**, as written priority rules redirect agents more reliably than code examples (98% vs. 63%)

Future directions include: evaluating how agents reconcile past decisions with evolving intent, developing design-decision traceability systems that preserve rationale and priorities, and extending the controlled findings to broader task families, repositories, and implementation choices. The study's limitations include its single controlled repository task family, the confounding of task relatedness with repository location in the local-sibling comparison, and the fact that agent differences cannot be attributed to models alone (each agent combines a model with its harness).

---

_Markdown view of https://picx.dev/p/O6LlL1, served by PicX — AI-generated visual whiteboard summaries of research papers._