Claude Fable 5.2 Merged Repeated Code More Often With Ownership Framing [1]

In Anthropic’s testing on small coding tasks, Claude Fable 5.2 merged repeated code in about half of the tries when prompted that the codebase was its own, and in under a tenth without that framing, according to Simon Willison’s Weblog ¹. The difference is worth testing in AI coding assistant prompts, but the reported result does not establish that the merges were better or that the pattern holds in other settings.

Willison published the finding on November 10, 2026, quoting Anthropic documentation ¹. The narrow question is whether ownership framing changes the model’s tendency to consolidate repeated code rather than add to the existing structure. The reported numbers address that behavior in the tested tasks; they do not show whether consolidation was the right choice ¹. For broader context on the model, see Fable 5.2 vs. Mythos 5.2: Anthropic's New Models Differ on Policy, Not Power.

What Anthropic tested with the code ownership prompt

The ownership prompt said: “This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.” ¹ The comparison described prompts that said nothing about ownership or presented the codebase as someone else’s ¹.

One interpretation is that ownership framing encourages the model to consider the codebase’s broader structure. That is an interpretation of the result, not a mechanism demonstrated by the reported testing.

Willison reports that, when a prompt said nothing about ownership or framed the codebase as someone else’s, the model tended to add to the existing structure, even when that repeated existing code ¹. The finding is therefore about one behavior (merging repeated code), not proof that ownership prompts produce better code.

How large is the reported gap in merged repeated code?

Prompt framing	Reported merge rate	Source
Codebase is the model’s own, with latitude and an expectation of continued work	About half of tries	1
No ownership framing	Under a tenth of tries	1
Codebase presented as someone else’s	Not separately quantified	1

Willison’s excerpt does not report how many tasks or tries were included, how tasks were selected, or how merging was judged ¹. It therefore does not provide enough detail to assess how reliably the result would apply to a different task mix or repository.

The result also does not establish whether a merge was preferable. That depends on context, such as whether repeated blocks are meant to vary and what conventions a team follows. The reported excerpt does not say whether reviewers approved the model’s changes ¹.

What the result does and does not measure

The reported outcome is whether the model merged repeated code under the described prompt conditions ¹. The excerpt does not report results for correctness, maintainability, review burden, compatibility with existing conventions, or developer approval ¹. It also describes testing on small coding tasks, not larger codebases or production workflows ¹.

Analysis: Treat the result as a reason to test role framing, not as a directive to merge duplication. Teams can evaluate the change against outcomes that matter in their own code and review process.

How to validate coding agent instructions before changing prompt standards

Treat ownership wording as a variable to test. Keep other instructions as consistent as possible and compare:

• No mention of ownership.
• The codebase is presented as someone else’s.
• The assistant is told the codebase is its own and that it will continue building on it.

These conditions reflect the prompt framings described in the source ¹. The evaluation steps below are recommendations, not a reproduction of Anthropic’s testing.

Use internal tasks involving repeated logic, existing abstractions, and requests to extend rather than redesign. Keep task wording and surrounding instructions consistent across variants; otherwise, it may be difficult to tell which instruction influenced the result. If you run the variants through an enterprise AI gateway, record which model and settings each run used, and check the model catalog so you compare like with like.

Track more than whether repeated code was merged. For each attempt, consider whether the assistant:

• Consolidated repeated logic when that was appropriate.
• Preserved existing conventions and abstractions.
• Changed code outside the requested scope.
• Produced work a reviewer would approve.

The source reports the merging behavior, not these additional outcomes ¹. Teams would need to define and assess them themselves.

An example code ownership prompt for AI code changes

Analysis: If a task depends on extending existing structure, teams could make the assistant’s role explicit and state change boundaries separately. For example:

Treat this as a codebase you are helping maintain and extend. Follow its existing conventions. Change only the relevant parts; refactor only where needed to meet the request, and explain any structural changes.

This is an illustrative prompt, not wording tested in the reported work. Reviewers can assess whether the changes stayed in scope and whether structural edits were justified.

Pilot shared instructions on your own repositories before standardizing them. The defensible lesson from the reported result is narrower: ownership framing coincided with more merging of repeated code in Anthropic’s small-task testing ¹. Whether to adopt similar wording is a decision to evaluate against your own workflow.

FAQ

What is a code-ownership prompt?
It is prompt language that frames the assistant as owning or continuing to build on a codebase. The reported test used wording that described the codebase as the model’s own and said it would keep building on it ¹.

Did Claude Fable 5.2 merge duplicated code more often with ownership wording?
Yes, in the reported small-task testing, it merged repeated code in about half of the tries with the ownership wording, compared with under one tenth without it ¹.

Does this prove ownership prompts improve AI-generated code?
No. The source reports a specific repeated-code behavior on small coding tasks and does not establish effects on correctness, maintainability, larger projects, production workflows, or other assistants ¹.

Should engineering teams add ownership language to every coding-assistant prompt?
Not on this evidence alone. Teams should compare prompt variants on representative internal tasks and define their own measures for structural quality, scope control, and review acceptance ¹.

What remains unknown about the Claude Fable 5.2 test?
The supplied source does not report the number or selection of tasks and tries, the assessment method, or variation across task types and codebases. It also leaves open whether the pattern holds in larger or production workflows ¹.

Source: ¹ “Quoting Prompting Claude Fable 5.2,” Simon Willison’s Weblog, November 10, 2026.