A Anthropic Apagou a Maior Parte dos Próprios Guardrails e Não Disse Quais Sustentavam

Thariq Shihipar, membro do corpo técnico da Anthropic, publicou em julho uma frase que todo time de plataforma que opera agentes deveria ler duas vezes: “Removemos mais de 80% do system prompt do Claude Code para modelos como Claude Opus 5 e Claude Fable 5 sem perda mensurável nas nossas avaliações de código.”

É a única afirmação quantitativa do artigo inteiro. Nenhum nome de avaliação. Nenhum delta de benchmark. Nenhuma contagem de tokens antes e depois. Um percentual, um resultado negativo e um conjunto de regras novas que revertem seis orientações publicadas pelo mesmo fornecedor um ano antes.

O argumento de engenharia é plausível e, em vários pontos, evidentemente correto. Falta a parte que um comprador regulado precisa: o critério pelo qual uma restrição foi julgada segura de apagar.

Seis Reversões, Ditas com Todas as Letras

Vale reconhecer o mérito da estrutura do texto. Ele não aposenta a orientação antiga em silêncio. Apresenta pares de Antes e Agora, e cada um inverte algo que os times foram instruídos a fazer:

• Regras explícitas viram julgamento.
• Exemplos viram design de interface.
• Contexto adiantado vira revelação progressiva.
• Repetição vira uma única descrição clara de ferramenta.
• Memória em CLAUDE.md mantida à mão vira memória automática.
• Especificações simples viram referências ricas.

A mais afiada é a reversão sobre exemplos. “Com nossos modelos mais recentes”, diz o artigo, “descobrimos que dar exemplos na verdade os restringe a um certo espaço de exploração.” Few-shot era, até pouco tempo atrás, a técnica ensinada com mais confiança na área. Agora aparece como teto.

O antes e depois sobre comentários torna a mudança concreta. O prompt antigo dizia: “Em código: por padrão, não escreva comentários. Nunca escreva docstrings de múltiplos parágrafos ou blocos de comentário de várias linhas, no máximo uma linha curta.” O novo diz: “Escreva código que se pareça com o código ao redor: acompanhe a densidade de comentários, a nomenclatura e o idioma dele.”

Quem já manteve um system prompt grande reconhece por que a primeira versão existia. Alguém recebeu uma parede de docstrings geradas, escreveu uma regra dura às onze da noite, e a regra ficou lá por um ano. A segunda versão é um design de instrução melhor. Ela delega um julgamento que o modelo hoje consegue fazer pelo contexto, em vez de codificar uma preferência de gosto como lei.

O Modo de Falha é Real

O artigo nomeia a dor com honestidade: “vemos várias mensagens conflitantes em uma única requisição, do tipo deixe a documentação conforme apropriado, ou NÃO adicione comentários, conforme nosso system prompt, skills e pedidos do usuário se chocam entre si.”

É o problema de acúmulo que já descrevemos. Restrições são adicionadas por pessoas diferentes, em momentos diferentes, para resolver incidentes diferentes, e nada as remove. Argumentamos que skills e contexto se acumulam sem coletor de lixo e que a maioria dos times não sabe dizer o que 60% da janela de contexto está fazendo. A Anthropic agora descreve essa mesma degradação dentro do próprio produto principal. Quando o fornecedor com mais incentivo para parecer organizado publica a contradição, o problema deixa de ser teórico.

Os remédios oferecidos são práticos. Manter o CLAUDE.md leve e “gastar a maior parte dos tokens com as pegadinhas dentro da base de código”. Evitar “afirmar as coisas óbvias que o Claude deveria saber olhando o sistema de arquivos”. O comando /doctor no Claude Code redimensiona skills e arquivos CLAUDE.md. É o tipo de orientação para a qual já empurramos clientes, e vem mais útil acompanhada de ferramenta.

O Critério Não Publicado

É aqui que o texto para antes do que governança exige.

Apagar uma restrição tem dois desfechos possíveis. Ou a restrição era redundante, porque o modelo já faz a coisa certa sozinho, ou a restrição sustentava algo, e a ausência dela produz um comportamento que ninguém mediu ainda. “Sem perda mensurável nas nossas avaliações de código” separa esses dois casos apenas na medida em que as avaliações cobrem os comportamentos que as regras apagadas protegiam.

Não sabemos quais avaliações rodaram. Não sabemos se densidade de comentários em um módulo Java legado, ou comportamento de recusa diante de um comando de shell destrutivo, ou verbosidade de saída sob orçamento de tokens, está dentro da cobertura. Um benchmark de código mede se tarefas foram concluídas. Muitos guardrails existem para comportamentos que uma tarefa concluída nunca toca.

Existe um segundo problema, mais silencioso e mais caro ao longo do tempo. Uma regra escrita carrega o raciocínio codificado. Quando um revisor humano lê “nunca escreva blocos de comentário de várias linhas”, ele consegue reconstruir que alguém se queimou com proliferação de docstrings geradas. Esse raciocínio é auditável. Pode ser contestado, datado, atribuído e aposentado de propósito. Substitua por julgamento delegado aos pesos do modelo e o raciocínio continua existindo em algum sentido, mas deixa de ser legível, deixa de ter autoria e deixa de ser testável por qualquer coisa que não seja outra rodada de avaliação.

Para uma ferramenta interna de programação, essa troca se defende. Para o agente de análise de crédito de um banco, “o modelo exerce bom julgamento aqui e nossas avaliações não regrediram” não é um controle que auditor aceita.

A Quem Isso Interessa

Seja justo com a posição do fornecedor, e seja claro sobre ela.

A tese por baixo do artigo é que o seu contexto está inchado e o modelo está bem. É exatamente a tese da qual um fornecedor de modelos se beneficia. Ela desloca o lugar da falha dos pesos, que o fornecedor controla, para o seu prompt, que você controla. E amplia a superfície sobre a qual o modelo decide sozinho, que é a direção para onde toda empresa de modelo quer empurrar a adoção.

Nada disso torna a tese falsa. Os seis pares de Antes e Agora são concretos e testáveis de forma independente na sua própria carga de trabalho, o que é mais do que a maioria da orientação de fornecedor oferece. O modo de falha descrito é reproduzível em uma tarde, bastando procurar contradições no seu próprio system prompt. Leia o texto e use.

Só não trate “sem perda mensurável” como algo medido. É um resultado interno não publicado, sobre avaliações sem nome, oferecido pela parte que se beneficia da conclusão. Trate como hipótese que vale testar na sua própria stack.

O Movimento de Governança que a Anthropic Entrega

O parágrafo mais valioso do artigo recebe a menor ênfase. Rubricas migram para referências, e agentes verificadores são instanciados para conferir o trabalho contra elas. A aplicação sai das regras ex-ante e vai para a verificação ex-post.

Isso é arquitetura de verdade, e é a resposta ao problema da exclusão. Merecia mais espaço do que recebeu. Se as restrições saem do system prompt, elas precisam aterrissar em algum lugar com nome, versão e dono. Uma rubrica consumida por um verificador é justamente isso. Dá para buscar com grep. Dá para diferenciar entre versões. Produz um registro de aprovado ou reprovado que você entrega a um revisor, coisa que a regra antiga embutida no prompt nunca fez.

O caminho de migração, portanto, tem uma regra só. Para cada restrição removida do prompt, ou você escreve por que ela ficou redundante, ou você a move para uma rubrica que um verificador aplica. Exclusões sem nenhuma das duas coisas são transferências silenciosas de risco.

Faça Isso Agora

Pegue o seu maior system prompt, CLAUDE.md ou arquivo de skill. Escolha as dez restrições mais antigas dele. Para cada uma, responda duas perguntas em uma linha de texto.

Primeira: qual incidente ou reclamação fez essa linha ser escrita? Se ninguém sabe, aquela restrição já perdeu o raciocínio codificado e você está mantendo uma superstição.

Segunda: se eu apagar, qual teste quebra? Se a resposta for “nenhum”, você encontrou ou uma exclusão segura ou um guardrail não testado, e não dá para saber qual até escrever o teste.

Restrições que sobrevivem às duas perguntas ficam. As que falham na primeira são candidatas a exclusão hoje. As que falham na segunda viram entrada de rubrica com verificador acoplado antes que qualquer coisa seja removida. Registre cada exclusão com data e motivo, porque daqui a onze meses alguém vai perguntar por que o agente se comporta assim, e “o fornecedor disse que o modelo melhorou” não é resposta.

A Anthropic fez a coisa certa ao publicar as reversões. O próximo artefato útil de qualquer fornecedor que faça o mesmo é o critério de exclusão em si.

---

Fontes

• Anthropic. “The new rules of context engineering for Claude 5 generation models.” Julho de 2026.

A Victorino ajuda organizações de engenharia a auditar quais restrições dos seus agentes de fato sustentam o sistema antes de apagá-las: contato@victorino.com.br | www.victorino.com.br