Há duas semanas, quando a Anthropic lançou o Claude Opus 5, divulgou um dado contraintuitivo: mais de 80% do system prompt do Claude Code foi deletado, e as avaliações internas de programação não mostraram nenhuma queda significativa.
Isso parece uma nota menor de otimização de produto. Não é. Boris Cherny, criador do Claude Code, contou a história completa em uma entrevista recente ao Y Combinator, e dados de monitoramento do membro da equipe do Claude Code Thariq Shihipar, além de engenheiros terceiros, confirmam o que isso revela: uma inversão fundamental na forma como produtos de IA devem ser construídos — relevante para qualquer pessoa que construa sobre agentes, independentemente de rodarem Claude, GPT ou modelos abertos.
O Que Estava Nos 80% Deletados?
Os cortes foram cirúrgicos. Quando a equipe revisou os registros internos de uso do Claude Code, encontrou a mesma requisição carregando requisitos conflitantes — o system prompt dizia “não adicione comentários”, uma Skill dizia “documente adequadamente”, e o usuário pedia no meio da tarefa para “explicar a lógica complexa”. O Claude sabia o que o usuário queria, mas primeiro precisava arbitrar instruções contraditórias, queimando tokens e tempo.
As deleções seguiram seis direções:
-
Deixe o modelo julgar. Prompts antigos fixavam comportamento em código: sem comentários por padrão, sem docstrings de múltiplas linhas, não criar documentos de planejamento sem pedido. A nova versão mantém uma linha: siga o estilo do código ao redor. Menos requisitos produziram melhor julgamento.
-
Desenhe interfaces, não forneça exemplos. Encher prompts com exemplos de chamadas de ferramenta era doutrina — até a Anthropic perceber que os modelos tratavam os exemplos como todo o espaço de respostas. Escreva menos exemplos, desenhe melhores interfaces: a ferramenta Todo apenas declara seus estados como pending / in_progress / completed, e o Claude infere o uso.
-
Carregue sob demanda. Instruções longas de revisão, verificação e ferramentas antes viviam permanentemente no system prompt, então até uma edição de uma palavra arrastava todo o contexto. Agora elas são entregues como Skills, e as definições de ferramentas carregam sob demanda através do ToolSearch.
-
Diga cada coisa uma única vez. Modelos antigos esqueciam, então a mesma regra aparecia no prompt, na descrição da ferramenta e nos exemplos. Modelos mais novos entendem contexto longo bem o suficiente para que a repetição crie conflitos em vez de reforço — cada regra tem exatamente um lar.
-
Deixe o modelo lembrar automaticamente. Notas de projeto e preferências do usuário antes se acumulavam no CLAUDE.md. A memória automática cuida disso agora; o CLAUDE.md mantém apenas uma introdução ao repositório e armadilhas genuinamente contraintuitivas.
-
Dê especificações simples. Modelos novos não precisam que humanos pré-digiram requisitos em forma “amigável à IA”. Protótipos em HTML, casos de teste, código existente e rubricas de avaliação funcionam todos como referências diretamente.
Em uma frase: o que a Anthropic deletou não era contexto — era julgamento que humanos haviam pré-executado em nome de modelos antigos e mais fracos.
A Reviravolta: O Prompt do Opus 5 É 72% Mais Longo Que o do Opus 4.8
Aqui vem o contraponto. Chen Cheng, engenheiro da Qoder, capturou as requisições que o Claude Code realmente envia: o system prompt do Opus 4.7 tinha cerca de 15.225 caracteres, o 4.8 cortou para 4.467 — e o Opus 5 cresceu de volta para 7.694, 72% mais que o 4.8.
Não é uma contradição. A razão é mais interessante do que parece. O gargalo dos modelos antigos era “consegue completar a tarefa”, então as regras sustentavam a capacidade. A capacidade aprimorada trouxe à tona novos problemas, e os 70% adicionais gerenciam exatamente dois:
Entrega do trabalho — O Opus 5 é tão autônomo que “corrija este erro” pode voltar com vizinhos refatorados, testes adicionados e documentação atualizada. Parece ótimo, até o usuário querer apenas a correção do bug. As novas regras: não expanda silenciosamente o escopo da tarefa porque você spotted um plano melhor; quando algo está bloqueado, termine o que é possível, depois declare claramente o que falta.
Correções — O Opus 5 gosta de narrar suas próprias correções (“eu errei antes, na verdade…”). Em tarefas longas, a maioria das correções não muda nada no resultado enquanto infla a saída. A nova regra: explique apenas erros que genuinamente afetam código, conclusões ou decisões; corrija silenciosamente os triviais; pare de avaliar seu próprio trabalho em público.
Uma seção impede o Claude de fazer demais; a outra o impede de dizer demais. Esse é o sinal real: a natureza do problema muda conforme a capacidade sobe. Regras que você cuidadosamente desenhou para um nível de capacidade tornam-se não apenas redundantes, mas prejudiciais no próximo.
Ablação: o Método Mais Subestimado no Desenvolvimento de Agentes
A ideia mais valiosa na entrevista de Cherny tem um nome: ablation (ablação). O procedimento é trivialmente simples — sempre que um novo modelo é lançado, delete o system prompt inteiro, adicione as linhas de volta uma a uma, e observe o que cada uma realmente faz.
Não adivinhe o que o modelo precisa. Rode, observe onde ele falha, e só então adicione a instrução para aquela falha. Nas palavras de Cherny:
Não comece adivinhando quais instruções o modelo precisa — seu palpite frequentemente estará errado. O que realmente funciona é simplesmente começar a usar o modelo, observar em quais tarefas ele se destaca e onde falha, e só quando ele continuar falhando no mesmo lugar considerar adicionar a instrução relevante de volta.
Ele até oferece um experimento executável:
# Run Claude Code with all system prompts removed
CLAUDE_CODE_SIMPLE=1 claude“Curiosamente, o modelo é na verdade ligeiramente mais inteligente sem esses prompts.” Isso corre na direção oposta de como a maioria das equipes constrói agentes: o modelo comete um erro, a equipe adiciona uma regra, e alguns meses depois o system prompt inflou para dezenas de milhares de caracteres. A prática da Anthropic é o inverso — a cada geração de modelo, zere tudo, e reconstrua sob demanda. E Cherny estende isso além de produtos de agentes: mesmo se você apenas usa o Claude Code, a cada seis meses delete seu CLAUDE.md, suas Skills, seus hooks, e veja o que muda. Um ciclo de ablação de seis meses — menos uma dica do que uma mudança de paradigma metodológico.
Excedente de Produto e Acorrentamento
Dois conceitos adicionais da entrevista merecem seus próprios títulos.
Excedente de produto: capacidade que os modelos atuais já possuem e que nenhum produto liberou ainda. O Claude Code é o caso didático — o Sonnet 3.5 já conseguia gerar funções completas, até arquivos inteiros, de uma só vez, mas os produtos ofereciam apenas completar uma linha e visualização de código somente leitura. O Claude Code removeu o andaime excedente, deu ao modelo o harness mais simples possível, e um agente de programação de classe mundial apareceu.
Acorrentamento: a falha oposta — produtos que não apenas falham em liberar a capacidade de um modelo, mas ativamente o acorrentam. Você acha que está “desenhando um produto”; na verdade, está colocando correntes no modelo. O teste de Cherny: dê ao modelo tarefas ligeiramente além do que você acredita que ele consegue fazer. Descreva o trabalho em um nível mais alto — o que você quer realizado, as restrições, o que conta como concluído — e solte.
Uma citação merece releitura por qualquer pessoa que construa produtos de agentes:
A forma de entender um modelo é mais próxima de entender um ser vivo — um sistema orgânico. Cada geração se comporta de forma diferente; tem até algo como uma personalidade diferente. Você precisa gastar tempo conhecendo-o, e então ajustar o harness para se adequar.
Não design de arquitetura. Pecuária.
A Lição Amarga, Reencenada em um System Prompt
Em 2019, o pioneiro do aprendizado por reforço Richard Sutton publicou “The Bitter Lesson” (A Lição Amarga). Sua tese central, provada ao longo de setenta anos de história da IA: humanos não conseguem resistir a despejar sua própria experiência na máquina — aberturas de xadrez, estruturas de fonemas, características visuais desenhadas à mão. As regras funcionam imediatamente e parecem artesanato. Então a computação escala, as regras desabam, e métodos que exploram busca e aprendizado vencem. A lição é amarga porque o que é descartado nunca é o trabalho preguiçoso — é o trabalho de que os pesquisadores estavam mais orgulhosos e no qual mais investiram.
Os prompts deletados do Claude Code são a lição em miniatura. Aqueles prompts fizeram do Claude Code o agente que ele era — e conforme o modelo evoluiu, eles começaram a arrastar o produto para baixo, porque cada regra era uma concessão a um defeito que não existe mais. O modelo corrigiu o defeito; a regra virou o fardo. Todo produto de agentes enfrenta isso: a competência central de hoje pode ser a dívida técnica de amanhã.
A solução não é parar de escrever regras — é tratar cada regra como um artefato experimental temporário, escrita com a expectativa de deleção. Seu system prompt, suas definições de ferramentas, suas Skills: o ciclo de vida delas pode ser exatamente de uma geração de modelo.
Quatro Ações para Construtores de Agentes
1. Coloque ablação na agenda
A cada lançamento de novo modelo — digamos, a cada 3–6 meses — rode uma ablação completa no seu system prompt. Delete tudo, adicione de volta linha por linha, registre o efeito de cada linha. O mesmo para ferramentas, Skills e hooks.
2. Propriedade única, repetição zero
Cada regra vive em exatamente um lugar. Se uma regra precisa ser repetida em três lugares para funcionar, o problema não é o modelo — é você domesticando um obsoleto. Limpe isso durante a ablação.
3. Separe bagagem legada de problemas atuais
A maioria das regras “impeça o modelo de fazer X” foi escrita contra versões de modelo que não existem mais. Para cada regra, pergunte: para qual versão isto foi escrito, e essa versão ainda roda em algum lugar?
4. Olhe além da engenharia de prompts
O ponto final de Cherny, repetido diversas vezes: o que importa não é “o prompt certo” mas atribuir ao modelo tarefas desafiadoras, dar a ele uma forma de verificar resultados, observar onde falha, e corrigir apenas esse ponto de falha. O único truque que supera tudo isso — o que todos estão procurando — não existe.
A verdadeira lição não é uma atualização de produto. É um espelho. A capacidade dos modelos cresce exponencialmente, e todo design inteligente que você construiu para a versão anterior pode ser redundante na próxima. O que sobrevive à troca de modelos não é um system prompt brilhantemente engenheirado — é um hábito de engenharia de zerar e reconstruir.
Delete as regras que você trabalhou tanto para escrever. Essa é a lição amarga, e é também a única solução.
