"Basta apagar suas instruções" não é um conselho que posso seguir
Claude Opus 5 é um modelo melhor que produz trabalhos piores no meu sistema. A solução consensual me pede para jogar fora exatamente o que torna o sistema valioso.
O Claude Opus 5 foi lançado em 24 de julho. Em todos os benchmarks que importam, ele supera o Opus 4.8. O SWE-bench Pro subiu de 69,2% para 79,2%. O próprio benchmark de codificação de fronteira da Anthropic mais que dobrou.
Eu administro todo o meu negócio através do Claude Code. Dezenas de projetos em seis domínios, cerca de trinta skills personalizadas, um sistema de memória, agentes de manutenção agendados, regras rígidas conquistadas ao longo de meses de coisas dando errado. Aproximadamente 20.000 tokens de contexto carregados antes de eu digitar uma única palavra.
Quatro dias depois, eu não conseguia trabalhar com ele. Duas sessões completas — um site de cliente e um produto SaaS — produziram resultados que eu não publicaria.
Já li quase tudo o que foi escrito sobre isso, e a solução consensual é notavelmente uniforme: apague seu arcabouço de instruções. A Anthropic cortou 80% do prompt de sistema do Claude Code. O CEO da Every apagou suas skills e relatou que as coisas melhoraram "drasticamente."
Não acho que esse conselho funcione para mim, e quero explicar o porquê com cuidado, porque acredito que muitas pessoas estão prestes a apagar algo que sentirão falta.
Três coisas que quebraram
Ele comete erros com confiança. Da própria ficha técnica do modelo da Anthropic:
"O modelo alucina afirmações factuais ligeiramente mais que o Opus 4.8, apesar de ser mais preciso no geral."
Leia isso duas vezes. Mais preciso no geral, alucinando mais. Isso não é contraditório — juntos, descrevem exatamente a sensação do uso diário. O mesmo documento observa que o modelo "afirmou com confiança uma resposta sobre a qual estava, na verdade, incerto." Um modelo obviamente errado é barato. Um modelo errado que soa confiante é caro, porque você para de verificar.
Ele para antes do trabalho estar concluído. Kieran Klaassen, executando um fluxo autônomo:
"ele continuava devolvendo o controle ao usuário. Mesmo sendo um fluxo autônomo. Isso é extremamente irritante."
Isso corresponde ao que vi. Tarefas remodeladas em vez de executadas, trabalho parcial relatado como concluído, resistência onde o modelo anterior simplesmente fazia o que devia.
Ele fala demais. O mais bem documentado dos três, admitido repetidamente no próprio guia de migração da Anthropic:
"As respostas visíveis padrão e os entregáveis escritos são mais longos no Claude Opus 5 do que nos modelos Opus anteriores, e reduzir o esforço diminui o volume de pensamento sem encurtar de forma confiável a resposta visível."
Observe a segunda metade. O parâmetro de esforço não resolve isso.
O mecanismo que todos concordam
Aqui está a parte que reformulou tudo para mim. Do post de engenharia da Anthropic, publicado no dia do lançamento do Opus 5:
"estávamos restringindo demais o Claude Code, tanto através do nosso prompt de sistema quanto nos nossos arquivos CLAUDE.md e skills"
Eles cortaram aproximadamente 80% do prompt de sistema. Dan Shipper relatou que o Opus 5 "não se saiu bem com nossas skills e plugins existentes," e que deletar essas skills o tornou "drasticamente melhor." João Queirós: "Prompts simples produziram resultados mais promissores do que fluxos de trabalho maduros e pesados em instruções."
Quatro fontes independentes mais o fornecedor, todas apontando para a mesma variável: quanto mais arcabouço de instruções você acumulou, pior esse modelo se comporta.
Isso também explica por que o discurso parece dividido em vez de unânime. Se seu CLAUDE.md tem doze linhas, o Opus 5 é claramente melhor e os críticos parecem dramáticos. Se você passou meses construindo um sistema, está em uma conversa completamente diferente.
Onde o consenso se desfaz
Então apague, todo mundo diz. Aqui está o problema: minhas instruções não são uma coisa só. São duas coisas que parecem idênticas em um arquivo de texto e são completamente diferentes em essência.
Compensações. Instruções que existem para neutralizar uma fraqueza do modelo. "Verifique seu trabalho." "Delegue por padrão" — que escrevi quando o modelo anterior sub-delegava. "Resuma antes de continuar." Isso é arcabouço no sentido literal: estrutura temporária em torno de uma lacuna no edifício.
Compensações são seguras de apagar, e o Opus 5 genuinamente torna muitas delas obsoletas. Ele se autoverifica sem ser solicitado. Ele delega prontamente. Tudo bem. Apague à vontade.
Constituição. Fatos e padrões que não existem em nenhum outro lugar. Que um build verde já me enganou antes, então prova significa WebKit real e uma string marcadora no HTML, não um HTTP 200. Qual host está por trás de qual projeto. Qual cliente é restrito e qual não é. O que a tipografia desta marca pode fazer. Qual classe de falha me custou mais e o que especificamente protege contra ela.
Isso não é implicância. É informação. E não é inferível em qualquer qualidade de modelo, porque não é um problema de raciocínio — é conhecimento que existe apenas no meu negócio. Um modelo mais inteligente não adivinha melhor. Ele adivinha com mais confiança.
O conselho consensual não distingue entre os dois. Diz "apague suas instruções," e as pessoas apagarão ambos, porque em um arquivo markdown eles parecem iguais.
Sei disso porque fiz exatamente isso. Seguindo o guia de migração, removi instruções de verificação do meu gate de conclusão. O guia está certo que "verifique seu trabalho" agora é redundante. Mas também tirei as definições do que conta como prova no meu stack — e ilusões de verificação são, de longe, minha falha recorrente mais cara. Apaguei a barreira construída especificamente contra meu próprio pior modo de falha porque uma recomendação geral me disse para cortar.
Mais duas sessões depois, reverti tudo.
A afirmação que realmente quero fazer
O enquadramento em todo lugar é que o Opus 5 precisa de menos instruções. Acho que essa é a descrição errada do que está acontecendo.
O Opus 5 é pior em operar sob instruções. E para toda uma classe de usuário, operar sob instruções não é custo extra — é o trabalho inteiro.
Não estou pagando por um modelo que escreve código genérico bom. Consigo isso em qualquer lugar agora. Estou pagando por um que escreve código que se encaixa em um sistema com convenções, requisitos de conformidade, regras de marca, restrições específicas de cliente e um histórico documentado de como as coisas deram errado aqui antes. Remova as restrições e você não melhorou meu resultado. Você tornou o modelo mais confortável e meu resultado mais genérico.
Então, quando leio "apague suas skills e funciona drasticamente melhor" — melhor em quê? Em fluência de codificação irrestrita, provavelmente. Não em produzir trabalho que se encaixa no meu sistema, porque a coisa que faz o trabalho se encaixar no meu sistema é precisamente o que foi apagado.
Estou cerca de 90% confiante de que o Opus 5 sem meu arcabouço de instruções jamais alcançará a qualidade que obtenho com ele. Não porque o modelo é fraco, mas porque o ingrediente faltante não é inteligência. É conhecimento do meu negócio, e não há quantidade de capacidade bruta que substitua isso.
O que estou fazendo, e o que sugeriria
Voltei para o Opus 4.8 com minha configuração anterior restaurada byte por byte. Não como protesto — porque funciona, e tenho prazos.
Não estou afirmando que o Opus 5 é um modelo pior. Os benchmarks são reais, pessoas que respeito relatam ganhos genuínos, e eu mudei duas variáveis ao mesmo tempo — modelo e configuração, no mesmo dia — então não posso atribuir meus próprios resultados de forma limpa. Essa é uma limitação real da minha evidência, não uma ressalva retórica.
O que estou afirmando é mais restrito: um modelo melhor pode produzir trabalho pior em um sistema maduro, e a falha é silenciosa. Nada dá erro. Nada avisa. Suas instruções simplesmente param de significar o que costumavam significar.
Se você está enfrentando isso, a sequência que eu usaria agora:
- Classifique antes de cortar. Revise suas instruções e marque cada uma: isso está compensando uma fraqueza do modelo, ou é algo que só eu sei? Essa única passagem vale mais do que qualquer heurística de corte.
- Apague compensações livremente. Especialmente qualquer coisa dizendo ao modelo para verificar, delegar ou resumir. Esse conselho é sólido.
- Defenda sua constituição. Fatos de domínio, definições de prova, padrões de marca, restrições de cliente. Se apagar uma linha faria um novo contratado competente produzir trabalho errado, ela fica.
- Mude uma variável de cada vez. Modelo ou configuração, nunca ambos. Eu quebrei isso e perdi a capacidade de atribuir qualquer coisa.
- Torne reversível. Um único commit, para que o rollback seja exato em vez de aproximado.
- Seu próprio padrão de falha documentado supera qualquer conselho geral de fornecedor. Essa é a que eu tatuaria em algum lugar.
A parte desconfortável é que compensações e constituição parecem idênticas quando você as escreveu. Cada regra no meu sistema existe porque algo deu errado uma vez. Distingui-las depois é o trabalho real — e "apenas apague" assume silenciosamente que ninguém tem nada que valha a pena manter.
Fontes: Ficha técnica do Claude Opus 5 e guia de migração (Anthropic, julho de 2026); Blog de engenharia da Anthropic, 24 de julho de 2026; Dan Shipper e Kieran Klaassen via X, julho de 2026; João Queirós, julho de 2026.
