Opus 5 lançado. Meu trabalho piorou.

"Apenas exclua suas instruções" não é um conselho que posso seguir

Claude Opus 5 é um modelo melhor que produz um trabalho pior no meu sistema. A solução consensual me pede para jogar fora aquilo que torna o sistema válido.

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 opero todo o meu negócio através do Claude Code. Dezenas de projetos em seis domínios, cerca de trinta habilidades personalizadas, um sistema de memória, agentes de manutenção programados, 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 entregaria.

Já li a maior parte do que foi escrito sobre isso, e a solução consensual é notavelmente uniforme: exclua sua estrutura de instruções. A Anthropic cortou 80% do prompt de sistema do Claude Code. O CEO da Every excluiu suas habilidades e relatou que as coisas "melhoraram drasticamente."

Acho que esse conselho não funciona para mim, e quero explicar o porquê com cuidado, porque acredito que muitas pessoas estão prestes a excluir algo que sentirão falta.

Três coisas que quebraram

Ele comete erros com confiança. Do próprio cartão de sistema da Anthropic:

"O modelo alucina afirmações factuais um pouco mais que o Opus 4.8, apesar de ser mais preciso no geral."

Leia isso duas vezes. Mais preciso no geral, alucinando mais. Esses não são contraditórios — juntos eles descrevem exatamente como o uso diário se sente. O mesmo documento observa que o modelo "afirmou com confiança uma resposta sobre a qual na verdade estava inseguro." Um modelo que está obviamente errado é barato. Um modelo que está errado enquanto parece certo é 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 deveria.

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 no qual 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 habilidades"

Eles cortaram cerca de 80% do prompt de sistema. Dan Shipper relatou que o Opus 5 "não se dava bem com nossas habilidades e plugins existentes," e que excluir essas habilidades o tornou "drasticamente melhor." João Queirós: "Prompts simples produziram resultados mais promissores do que fluxos de trabalho maduros e com muitas instruções."

Quatro fontes independentes mais o fornecedor, todas apontando para a mesma variável: quanto mais estrutura de instruções você acumulou, pior este modelo se comporta.

Isso também explica por que o discurso parece dividido em vez de unânime. Se o 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 exclua, 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 delegava de menos. "Resuma antes de continuar." Essas são estruturas no sentido literal: um arcabouço temporário em torno de uma lacuna na construção.

Compensações são seguras de excluir, e o Opus 5 genuinamente torna muitas delas obsoletas. Ele se autoverifica sem ser solicitado. Ele delega prontamente. Tudo bem. Pode excluir.

Constituição. Fatos e padrões que não existem em nenhum outro lugar. Que uma build verde já mentiu para mim 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 tem acesso restrito e qual não tem. 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 esses dois. Ele diz "exclua suas instruções," e as pessoas excluirão ambos, porque em um arquivo markdown eles parecem iguais.

Sei disso porque fiz isso. Seguindo o guia de migração, removi instruções de verificação do meu portão 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 na minha stack — e ilusões de verificação são, de longe, minha falha recorrente mais cara. Excluí a barreira construída especificamente contra meu próprio pior modo de falha porque uma recomendação geral me disse para enxugar.

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 — é 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 "exclua suas habilidades e funciona drasticamente melhor" — melhor em quê? Em fluência de codificação sem restrições, 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 excluído.

Estou cerca de 90% confiante de que o Opus 5 sem minha estrutura de instruções nunca alcançará a qualidade que obtenho com ela. Não porque o modelo é fraco, mas porque o ingrediente que falta 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

Estou de volta ao 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 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 te avisa. Suas instruções simplesmente deixam de significar o que costumavam significar.

Se você está enfrentando isso, a sequência que eu usaria agora:

1. 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 que qualquer heurística de corte.
2. Exclua compensações livremente. Especialmente qualquer coisa instruindo o modelo a verificar, delegar ou resumir. Esse conselho é sólido.
3. Defenda sua constituição. Fatos de domínio, definições de prova, padrões de marca, restrições de cliente. Se excluir uma linha faria um novo contratado competente produzir trabalho errado, ela fica.
4. Mude uma variável de cada vez. Modelo ou configuração, nunca ambos. Eu quebrei isso e perdi minha capacidade de atribuir qualquer coisa.
5. Torne reversível. Um commit, para que o rollback seja exato em vez de aproximado.
6. 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 exclua" assume silenciosamente que ninguém tem nada que valha a pena manter.

Fontes: Cartão de sistema e guia de migração do Claude Opus 5 (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.