Claude Fable 5.2 ajusta o próprio código conforme o prompt define o dono

# Claude Fable 5.2 ajusta o próprio código conforme o prompt define o dono

Nota da redação: os números citados (unificação de duplicações abaixo de 10% sem framing de propriedade e cerca de 50% com ela) vêm da documentação da Anthropic apenas por meio da citação de Simon Willison; a redação não teve acesso direto ao documento original da Anthropic nem a detalhes de metodologia, tamanho de amostra ou linguagens testadas. Leve isso em conta ao avaliar o peso da evidência.

Documentação da Anthropic, divulgada em 10 de novembro de 2026, mostra que uma única frase sobre propriedade do código muda a taxa de unificação de duplicações de menos de 10% para cerca de 50% nos testes internos do modelo.

Documentação da Anthropic sobre prompts do Claude Fable 5.2, destacada por Simon Willison em 10 de novembro de 2026, mostra que uma única frase sobre propriedade do código muda a taxa de unificação de duplicações de menos de 10% para cerca de 50% nos testes internos do modelo.

A Anthropic publicou uma observação curiosa na documentação de prompts do Claude Fable 5.2, destacada pelo blog de Simon Willison em 10 de novembro de 2026: o modelo se comporta de forma diferente em tarefas de código dependendo de como o prompt descreve a posse daquele código. Não é sobre dar mais contexto técnico ou exemplos melhores. É sobre uma frase que diz, essencialmente, de quem é a responsabilidade pela base de código.

Segundo a documentação citada por Willison, quando o prompt não menciona nada sobre propriedade, ou pior, dá a entender que o código pertence a outra pessoa ou equipe, o Claude Fable 5.2 tende a adicionar código por cima do que já existe. Mesmo quando isso significa repetir lógica que já está ali. É um comportamento de convidado cauteloso: evita mexer no que não é seu.

O número que sustenta a observação

A Anthropic testou isso em tarefas pequenas de codificação e mediu quantas vezes o modelo optava por unificar código duplicado em vez de simplesmente empilhar mais uma versão dele. Sem qualquer indicação de propriedade no prompt, a unificação aconteceu em menos de 10% das tentativas. Com uma frase explícita de que o código pertencia ao próprio modelo, essa taxa saltou para cerca de 50%.

A frase usada no teste, segundo a documentação, foi direta:

Esta base de código é sua: para que ela serve e como é construída são decisões suas, e você vai continuar construindo em cima dela.

Documentação da Anthropic, "Prompting Claude Fable 5.2"This codebase is yours: what it's for and how it's built are your call, and you'll keep building on it.

Não é um prompt sofisticado. Não traz engenharia de contexto, não injeta exemplos de few-shot, não altera a temperatura nem o tamanho da janela. É uma única sentença sobre posse, e ela dobrou a taxa de refatoração espontânea nos testes da própria Anthropic.

Por que isso acontece

A explicação mais plausível, embora a Anthropic não detalhe o mecanismo interno, é que o ajuste fino por reforço desses modelos recompensa cautela quando o contexto sugere que o agente está mexendo em propriedade alheia. Faz sentido como comportamento de segurança padrão: um assistente que reescreve a casa do vizinho sem pedir é um assistente perigoso.

O problema é que esse mesmo instinto de deferência, pensado para evitar mudanças destrutivas em código de terceiros, também trava o modelo quando a tarefa pedida é justamente simplificar, consolidar ou melhorar a estrutura existente. Sem o sinal de que ali ele tem liberdade de dono, o Claude Fable 5.2 trata toda base de código como propriedade alheia por padrão, e opta pelo caminho mais conservador: somar em vez de reorganizar.

O que muda no prompt de quem usa agentes de código

Na prática, isso tem implicação direta para quem monta prompts de sistema para ferramentas como Claude Code ou qualquer wrapper que chame a API da Anthropic para tarefas agentic de codificação. Um template de sistema que hoje só descreve stack, convenções e regras de estilo provavelmente está deixando esse sinal de fora:

Nota da redação: o código desta seção não foi executado em ambiente real. Valide antes de usar em produção.

Você está trabalhando nesta base de código. Ela é sua: o que ela faz e
como ela é estruturada são decisões que você pode tomar, e você vai
continuar construindo em cima dela nas próximas interações.

Adicionar algo assim ao prompt de sistema de um agente de refatoração tende, pelos números da Anthropic, a aumentar a chance de o modelo consolidar duplicações em vez de ignorá-las. Isso vale tanto para sessões interativas quanto para pipelines automatizados que chamam o modelo repetidamente sobre o mesmo repositório.

Em resumo: a frase de propriedade funciona como uma chave que libera o modelo para tratar a estrutura do código como parte do escopo da tarefa, não apenas o trecho pedido.

Onde essa liberdade ajuda, e onde ela atrapalha

Essa descoberta não é um botão que só traz vantagem. Ativar a framing de propriedade muda o raio de ação do modelo, e isso tem efeitos colaterais que quem revisa pull requests precisa considerar.

• Tarefas de refatoração e limpeza: a framing de dono ajuda bastante, porque é exatamente aí que se quer que o modelo reorganize, não apenas adicione.
• Correções pontuais em código legado de outro time: aqui o comportamento padrão, sem a frase de propriedade, é o desejável. Ninguém quer que o agente reestruture um módulo crítico de outra equipe ao resolver um bug pequeno.
• Pull requests pequenos e cirúrgicos: dar a framing de dono pode fazer o modelo expandir o escopo do diff além do que o revisor esperava, o que aumenta o tempo de review em vez de reduzir.
• Pipelines automatizados sem revisão humana antes do merge: ativar a propriedade sem um portão de revisão aumenta o risco de mudanças estruturais passarem direto para produção.

A decisão de usar ou não essa frase vira, então, uma decisão de escopo deliberada por tarefa, não uma configuração fixa de prompt de sistema aplicada a tudo. Times que automatizam agentes de código em CI precisam decidir isso por tipo de job, não de forma genérica.

O que a documentação não responde

No trecho da documentação citado por Willison, não aparece o tamanho da amostra de tarefas testadas, nem quais linguagens ou tipos de repositório foram usados no experimento. Também não há, nesse excerto, indicação de que o comportamento tenha sido medido em tarefas grandes, de múltiplos arquivos, apenas em tarefas pequenas de codificação.

Isso significa que extrapolar o resultado para refatorações grandes de monorepo é, por enquanto, um salto de fé. O que dá para levar como aprendizado concreto é mais estreito, mas ainda assim útil: se o Claude Fable 5.2 (ou modelos com comportamento equivalente) está devolvendo código duplicado quando deveria consolidar, a primeira coisa a testar não é trocar de modelo, é testar essa frase no prompt.

Fonte

Simon Willison, "Prompting Claude Fable 5.2" (citando documentação da Anthropic), Simon Willison's Weblog, 10 de novembro de 2026. https://simonwillison.net/2026/Nov/10/prompting-claude-fable-52/.

Fonte: Simon Willison