Should Coding Agents Follow Precedent or Task Intent?

When modifying existing projects, coding agents often face an implicit conflict: the implementation patterns already present in the repository versus the new requirements of the current task. Do they tend to imitate old code or follow new instructions? A study titled "Precedent or Intent? What Coding Agents Follow When Evolving Existing Code" answers this question through large-scale controlled experiments and provides conclusions with direct implications for engineering practice.

Experimental Design: Isolating Three Sources of Guidance

The researchers' approach was to build dedicated controlled experimental repositories that separate the factors that might influence agent decisions. They identified three competing sources of guidance: the agent's own default preferences, precedents from existing code in the repository, and explicit requirements in the task instructions.

The experiments were conducted in two directions: first, agents implemented features without interference from precedents to observe their default choices; then, different forms of precedents were planted in the repository to see whether and to what extent precedents override default behavior. The entire study covered four coding agents, six implementation pairs, and a total of 5,625 trials, followed by validation in four open-source repositories involving three programming languages.

The value of this bidirectional control design is that it not only observes the phenomenon that "agents follow precedents" but also quantifies the strength of precedents and isolates which dimension of precedent is actually at work.

Core Finding: Precedents Override Default Preferences, but Strength Varies Enormously

The first conclusion is quite clear: different agents exhibit highly consistent default implementation preferences when no precedent exists. However, when the repository contains precedents that conflict with default preferences, they almost invariably follow the precedent—359 out of 360 relevant trials chose the precedent.

But "following precedent" is not a homogeneous phenomenon. The researchers found that the influence of precedents is highly dependent on how they are presented.

Local Support Files Have Far Greater Influence Than Sibling Resource Files

Under equal conditions, three supporting local files led to a 96% adoption rate, while sibling-resource files achieved only 4%. This means that agents do not simply scan the repository for "similar code" but are highly sensitive to the proximity and contextual relevance of precedents to the current task.

Sibling-resource files refer to files located at the same directory level as the target file that may be functionally related but do not directly support the target—such as peer test files, configuration files, or similar modules. Their contextual relevance to the current task is weak, and agents may treat them as "background noise" rather than referenceable precedents during retrieval. In contrast, local support files are auxiliary files that directly serve the current goal, such as utility functions, type definitions, or explicit example snippets adjacent to the target file. Their high contextual relevance makes it easier for agents to recognize them as "imitable templates." This distinction reveals that agents' selection of precedents is not based on file count or syntactic similarity but on the semantic and structural proximity of files to the current task. Therefore, when organizing code in a repository, placing key conventions or examples near the target file can significantly increase the probability of agent adoption.

Placement Alone Can Flip the Outcome

More strikingly, with the number of examples fixed, merely changing the file placement could jump the adoption rate from 0% to 100%. This indicates that the "visibility" and "discoverability" of precedents almost determine whether they are adopted. For developers, this suggests an easily overlooked fact: the organizational structure of code is itself an implicit instruction.

When Task Intent Conflicts with Precedent: Written Rules Beat Code Examples

The second direction of the study addressed a more challenging scenario—where the new task intent explicitly requires a different approach from existing code. In this case, conveying new intent through code examples alone has limited effect: in joint tasks involving two agents and two implementation pairs, code examples achieved only a joint success rate of 38/60.

By contrast, written priority rules performed significantly better, achieving a joint success rate of 59/60. This advantage was also validated in real open-source repositories: rules loaded via a harness increased the joint success rate from 0/120 to 117/120.

The engineering implication of this contrast is clear: if you want an agent to deviate from repository conventions in a particular modification, simply providing a few examples of "correct code" is not enough—you need to explicitly state the priority: which should win when the new intent conflicts with the old precedent.

Joint success rate is the core evaluation metric used in this study, referring to the proportion of tasks where the agent simultaneously satisfies requirements across multiple task dimensions. For example, a joint task might require the agent to both follow the new implementation approach and maintain compatibility with existing code, with success counted only if both conditions are met. This metric is stricter than single-dimension success rates because it captures the agent's overall performance in conflicting scenarios. In the study, code examples achieved only a joint success rate of 38/60, while written priority rules achieved 59/60, indicating that merely providing examples of "correct code" is insufficient for agents to make correct trade-offs under multiple constraints, whereas explicitly writing priority rules can significantly reduce decision ambiguity during conflicts. The joint success rate directly reflects the effectiveness of guidance methods in complex tasks.

Implications for Engineering Practice

These findings point to a broader conclusion: the behavior of coding agents is highly malleable, and what shapes it is not only the task description itself but also the physical structure of the repository and whether you explicitly express priorities.

From a tool design perspective, the researchers propose supporting "design decision traceability"—recording not only implementation choices but also the rationale and priorities behind them, so that future modifications have a basis. This is a direction worth watching, because current code repositories typically preserve only "what was done" while losing "why it was done this way" and "under what circumstances it can be violated."

For teams using coding agents daily, there are three actionable takeaways: place key conventions where agents can easily find them; when deviation from convention is needed, express priorities through written rules rather than examples; and write the rationale for important design decisions into the repository, not just leave the code.

Design decision traceability refers to recording not only "what was done" in the code but also "why it was done this way" and "under what conditions it can be violated." In traditional repositories, this information is often scattered across commit messages, comments, or external documentation, making it difficult for agents to systematically access. The researchers suggest storing design rationale and priorities alongside code in a structured manner (such as rule files or decision logs) so that agents can retrieve explicit constraints when making modifications. This concept is similar to "Architecture Decision Records (ADRs)" in software engineering but emphasizes machine readability so that agents can directly reference it when generating code. Implementing traceability helps reduce agents' blind imitation of precedents and gives them a basis when deviation from convention is needed.

Conclusion

By combining controlled experiments with validation in real repositories, this study reveals the decision-making patterns of coding agents between "precedent" and "intent": they strongly tend to follow precedents, but the effectiveness of precedents depends on how they are presented; and when intent needs to override precedent, written priority rules are far more effective than code examples. These conclusions both explain why agents often "do things as usual" in legacy codebases and provide a basis for more precisely guiding them.