Claude Fable 5.2 removes duplicate code more often when you put it in charge

You ask an AI to add a new payment method. The project already has an amount validation check, but the agent writes another, almost identical one. The task is technically complete, the tests pass, and now you have two versions of the same check to maintain. Anthropic suggests an intriguing way to influence this behavior in Claude Fable 5.2: explicitly tell the model that it is responsible for the codebase and will maintain it going forward.

This is a useful lead for anyone configuring coding agents. How you frame the role can change the scope of the edits. That means this kind of instruction should be evaluated alongside the quality of the result, the cost of the run, and the time spent on review.

What Anthropic found

In the original post, Simon Willison quotes Anthropic's documentation: a sentence assigning ownership of the project to the model increased the frequency of duplicate-code removal from less than 10% to around 50%. However, checking the primary source revealed a discrepancy: it now gives a differently worded instruction and a result of around 75%, against a baseline of less than 10%. These figures cannot be treated as a single, unchanged experiment.

The current recommendation essentially reads: “You are the owner and long-term maintainer of this codebase, and you make the decisions about its structure.” The company describes tests on small programming tasks. These results do not establish how much better the agent will perform on your large repository. Source: Anthropic documentation.

For developers, what is interesting here is the question being tested. We usually describe the feature we want in detail, but may leave the agent's relationship to the existing architecture undefined. Should it carefully fit in another handler? Can it propose a shared function? Where does completing the task end and independently reworking the project begin? These decisions should be spelled out before the run.

What this looks like in an everyday task

Imagine an online store with two discount handlers. Both check the promo code's expiration date and the minimum order amount. You need to add a third handler for a partner promotion.

One acceptable solution is to copy the checks into the new handler. Another is to extract the shared logic into a function and call it in all three places. The second option may make future changes easier: when the minimum-order rule changes, only one place will need updating. But first, you need to make sure the checks really mean the same thing.

For example, the partner promotion might include shipping in the order amount, while a regular promo code excludes it. In that case, superficially similar code fragments should not be merged without careful consideration. During review, it is important to ask whether the differences between the rules have been preserved. Reducing the number of repeated lines does not, by itself, prove that the solution is good.

For your own experiment, take several previously completed tasks where these kinds of differences are known. Run the same assignments with a standard instruction and with the maintainer role. Check that behavior is preserved, the changes are understandable, and the review effort is reasonable. Decide in advance which changes you will consider useful, so an attractive diff does not become a substitute for results.

The cost of autonomy

There is a significant caveat to this approach. In its current documentation, Anthropic reports an increase in output tokens of around 70–80%, additional unrequested edits, and some changes to the behavior of existing functions. The company also warns that the final summary of the work could omit small changes. That is a reason to read the diff itself. Source: Anthropic.

The practical takeaway depends on the task. If you want to rethink a module's structure, the long-term maintainer role is worth experimenting with. If you are fixing a single bug before a release, it is better to explicitly describe the required change, the acceptance criteria, and the permitted scope of work.

A product manager or founder choosing agent settings for a team should evaluate the entire path to an accepted change. How much time did the developer spend reviewing it? Did unnecessary edits have to be reverted? Did the next task become easier? The answers will show whether the new instruction helps your particular workflow.