Claude Fable 5.2 elimina código duplicado com mais frequência quando assume a responsabilidade pelo projeto

Você pede a uma IA para adicionar uma nova forma de pagamento. O projeto já tem uma validação de valor, mas o agente escreve outra quase idêntica. Formalmente, a tarefa está concluída, os testes passam e agora é preciso manter duas versões da mesma validação. A Anthropic propõe uma maneira curiosa de influenciar esse comportamento no Claude Fable 5.2: dizer explicitamente ao modelo que ele é responsável pela base de código e continuará cuidando de sua manutenção.

É uma pista útil para quem configura agentes de desenvolvimento. A maneira de definir o papel pode mudar o alcance das alterações. Por isso, vale avaliar esse tipo de instrução junto com a qualidade do resultado, o custo da execução e o tempo de revisão.

O que a Anthropic descobriu

Na publicação original, Simon Willison cita a documentação da Anthropic: uma frase que atribuía ao modelo a propriedade do projeto aumentava a frequência de eliminação de código duplicado de menos de 10% para cerca de 50%. No entanto, a consulta à fonte original revelou uma divergência: agora ela apresenta uma instrução com outra redação e um resultado de aproximadamente 75%, diante de um patamar inicial inferior a 10%. Não se pode tratar esses números como um único experimento que permaneceu inalterado.

A recomendação atual equivale a dizer: “Você é o dono e mantenedor desta base de código a longo prazo, e cabe a você decidir como ela será estruturada”. A empresa descreve testes com pequenas tarefas de programação. Esses resultados não permitem concluir quanto melhor o agente vai se sair no seu repositório de grande porte. Fonte: documentação da Anthropic.

Para quem desenvolve, o interessante aqui é a própria questão que está sendo testada. Costumamos descrever em detalhes a funcionalidade desejada, mas podemos deixar indefinida a relação do agente com a arquitetura existente. Ele deve integrar cuidadosamente mais um handler? Pode propor uma função compartilhada? Onde termina a execução da tarefa e começa uma reformulação do projeto por iniciativa própria? Vale esclarecer essas decisões antes de iniciar a execução.

Como isso aparece em uma tarefa comum

Imagine uma loja virtual com dois handlers de descontos. Ambos verificam a validade do código promocional e o valor mínimo do pedido. É preciso adicionar um terceiro handler para uma promoção de um parceiro.

Uma solução aceitável é copiar as verificações para o novo handler. Outra é extrair a parte comum para uma função e usá-la nos três pontos. A segunda opção pode facilitar mudanças futuras: quando a regra de valor mínimo mudar, será preciso alterar apenas um lugar. Mas, antes, é necessário garantir que as verificações realmente tenham o mesmo significado.

Por exemplo, a promoção do parceiro pode incluir o frete no valor do pedido, enquanto um código promocional comum o exclui. Nesse caso, trechos aparentemente semelhantes não podem ser unificados sem cuidado. Na revisão, é importante verificar se as diferenças entre as regras foram preservadas. A simples redução de linhas repetidas não comprova a qualidade da solução.

Para fazer seu próprio experimento, selecione algumas tarefas já resolvidas nas quais esse tipo de diferença seja conhecido. Execute as mesmas tarefas com uma instrução comum e com o papel de mantenedor. Verifique se o comportamento foi preservado, se as alterações são compreensíveis e quanto custa revisá-las. Defina de antemão quais mudanças serão consideradas úteis, para que um diff bonito não substitua o resultado.

O preço da autonomia

Essa abordagem tem uma ressalva importante. Na documentação atual, a Anthropic relata um aumento de aproximadamente 70–80% nos tokens de saída, alterações adicionais não solicitadas e algumas mudanças no comportamento de funções existentes. A empresa também alerta que o resumo final do trabalho podia omitir pequenas alterações. Isso é motivo para ler o próprio diff. Fonte: Anthropic.

A conclusão prática depende da tarefa. Se você quer repensar a estrutura de um módulo, vale experimentar o papel de mantenedor a longo prazo. Se está corrigindo um único bug antes de um lançamento, é melhor descrever explicitamente a alteração necessária, os critérios de aceitação e os limites permitidos do trabalho.

Um gerente de produto ou fundador que escolhe as configurações do agente para a equipe deve avaliar todo o caminho até a aceitação da alteração. Quanto tempo o desenvolvedor gastou na revisão? Foi preciso reverter mudanças desnecessárias? A tarefa seguinte ficou mais simples? As respostas mostrarão se a nova instrução ajuda no seu processo específico.