O Opus 5 não é tão mau como a internet diz

O Opus 5 não é tão mau como a internet diz. Após mais de cinco semanas de uso diário, continuo a encontrar o texto difícil, a expansão do âmbito, as premissas erradas e as regressões descritas pelos utilizadores. Mas, com um plano bem estudado, tarefas delimitadas e verificações fora da própria mensagem final, é um excelente programador de software.

Porque mudou a minha opinião: deixei de pedir ao Opus que planeasse e implementasse ao mesmo tempo

A minha opinião melhorou porque deixei de pedir ao Opus que descobrisse a arquitetura e implementasse uma funcionalidade grande no mesmo contexto. Na minha avaliação da semana de lançamento, descrevi-o como um excelente modelo de implementação, mas difícil de supervisionar. Cinco semanas de uso repetido tornaram essa diferença mais clara e aumentaram a minha confiança no Opus como implementador.

Ler centenas de relatos negativos influenciou o meu julgamento mais do que esperava. Esses relatos ensinaram-me a reconhecer os problemas, mas também fizeram com que cada frase estranha ou alteração desnecessária parecesse confirmar uma conclusão já tomada. A diferença tornou-se mais clara quando comecei a separar tarefas mal delimitadas de tarefas planeadas. O Opus tinha mais dificuldades quando eu pedia à mesma conversa que compreendesse uma funcionalidade grande, decidisse a arquitetura, preservasse todas as restrições, implementasse tudo e ainda explicasse o resultado com clareza. São vários trabalhos escondidos num só prompt.

Quando entreguei ao Opus apenas a implementação, depois de definir a arquitetura e os limites, o trabalho passou a ser muito melhor. O modelo percorreu o código relevante em todo o repositório, tratou de alterações difíceis e reparou em efeitos que um modelo menos atento poderia não ver. Numa tarefa delimitada, essa atenção ajudou em vez de atrapalhar, porque o Opus encontrou os ficheiros, os testes e os casos extremos ligados ao comportamento pedido.

A mudança na minha opinião não apaga as falhas do Opus 5. Mostra-me qual é a função em que consigo controlar melhor essas falhas.

Que problemas do Opus 5 são reais, e o que ajuda?

Os cinco grupos de queixas são credíveis, mas não os considero igualmente graves. O problema do texto continua evidente no uso normal. Os outros quatro causam muito menos estragos quando o Opus recebe um plano baseado em pesquisa, um âmbito de implementação restrito e uma etapa de verificação a sério.

Queixa	O que reduz o problema	O que permanece
Texto difícil de ler	Limites de resposta e regras de linguagem simples	No meu uso, o Opus continua menos claro do que o Fable
Expansão do âmbito	Limites claros sobre o que fica de fora e poucos ficheiros no âmbito	As instruções podem continuar a ser ignoradas
Premissas falsas	Pesquisa antes da edição e perguntas explícitas	Um revisor tem de confirmar a premissa
Regressões ou conclusão falsa	Critérios de aceitação, testes e revisão do diff	As verificações escolhidas podem continuar incompletas
Perda do plano	Plano guardado, tarefas menores e contexto mais limpo	Cada parte continua a precisar de revisão

Cada mudança pode reduzir o problema correspondente, mas nenhuma me permite dispensar uma revisão independente.

1. Texto difícil: os limites ajudam, mas o Fable continua mais claro

Esta é a queixa que reconheço mais depressa. O Opus consegue juntar palavras corretas numa frase que exige mais do que uma leitura, sobretudo em explicações, resumos e ficheiros Markdown mais longos. Os utilizadores do Reddit descreveram a mesma combinação de frases longas, estrutura fraca e texto que faz sentido em termos técnicos, mas é cansativo de interpretar. [5] [6]

O que ajuda: o guia da Anthropic sobre prompts para o Opus 5 diz que as respostas dirigidas ao utilizador e os relatórios escritos tendem a ser mais longos, e recomenda limites explícitos para ambos. [1] Pedir uma resposta mais curta e exigir linguagem simples ajuda, mas nenhuma das instruções dá ao Opus, de forma consistente, a clareza de conversa que obtenho com o Fable 5. Essa diferença importa numa conversa de planeamento. Importa muito menos quando o resultado que procuro é uma alteração de código testada.

2. Expansão do âmbito: limites claros mantêm a tarefa delimitada

O Opus está especialmente atento a problemas próximos, possíveis abstrações, validações em falta e formas de tornar uma pequena alteração mais completa. Essa atenção pode ser útil durante uma auditoria. Numa correção delimitada, pode transformar um pedido numa refatoração ou criar todo um processo em torno de uma verificação que devia exigir um único comando. A Anthropic avisa expressamente que o Opus 5 pode expandir o âmbito de uma tarefa, verificar o próprio trabalho em excesso e delegar com demasiada facilidade. [1]

O que ajuda: defino aquilo que fica de fora com a mesma clareza com que defino o objetivo. Os problemas não relacionados são comunicados, não corrigidos, e a arquitetura existente mantém-se, a menos que os critérios de aceitação exijam uma alteração. Um autor no Reddit relatou uma melhoria semelhante depois de substituir instruções antigas, que exigiam correções imediatas, por uma regra que manda apresentar os problemas não relacionados e deixar o utilizador decidir o âmbito. [7] O relato mostra que a configuração pode mudar o comportamento. Não transforma todas as falhas em culpa do utilizador.

3. Premissas falsas: a pesquisa expõe as suposições mais cedo

O relato mais claro do Reddit que incluí na recolha descreveu o Opus a inventar uma tarefa no Linear e depois a referi-la em comentários no código, testes e mensagens de commit. [8] Nunca encontrei exatamente essa falha, mas reconheço o risco subjacente: depois de adotar uma interpretação, o Opus consegue fazer muito trabalho tecnicamente competente antes de parar para questionar a premissa.

O que ajuda: uma fase de pesquisa separada torna as suposições visíveis antes de o código depender delas. O modelo continua a precisar de uma instrução clara para fazer perguntas quando um facto em falta altera o desenho da solução. Um revisor também tem de confirmar que a implementação responde ao pedido original, e não a outro pedido parecido.

4. Regressões: verifique o trabalho fora do Opus

Vários relatos descrevem uma correção que cria uma regressão, seguida de outra correção que volta a abrir o erro original. Um tópico no Reddit resumiu o padrão assim: o modelo corrige o erro A, volta a estragá-lo enquanto corrige o erro B e depois resolve A novamente. [9] São relatos isolados, sem repositórios que eu possa analisar, mas descrevem uma falha conhecida dos agentes: cada correção local parece útil enquanto o resultado se afasta cada vez mais do conjunto completo de critérios de aceitação.

O que ajuda: não aceito a afirmação do modelo de que a tarefa está concluída. A conclusão vem das verificações acordadas: os testes relevantes, o build, uma revisão focada do diff e qualquer comportamento manual exigido pela funcionalidade. O planeamento ajuda o Opus a escolher o trabalho. A verificação determina se o trabalho ficou concluído.

5. Perda do plano: separe a pesquisa da implementação

Uma funcionalidade grande junta pesquisa, arquitetura, implementação, depuração e revisão num contexto que não para de crescer. O Opus pode gastar a parte útil desse contexto durante a exploração e depois implementar com base numa memória comprimida ou incompleta da decisão. Um relato misto no Reddit é esclarecedor: o autor considerou o Opus frustrante num repositório grande e consolidado, mas disse que o modelo criou uma nova extensão para o Chrome numa só sessão, fez 17 commits e passou uma revisão do Codex. [10] O relato não identifica a causa, mas mostra o mesmo utilizador a obter resultados muito melhores num projeto novo, com menos contexto herdado.

O que ajuda: a documentação de boas práticas do Claude Code da Anthropic diz que o desempenho pode baixar à medida que a janela de contexto fica cheia, o que pode levar a instruções ignoradas e a mais erros. Para alterações incertas ou que abrangem vários ficheiros, recomenda separar a pesquisa e o planeamento da implementação. [2] Este conselho aplica-se a todos os modelos de programação que uso. O Opus apenas torna mais fácil ver o custo de o ignorar.

O que provam realmente 1.008 excertos negativos sobre o Opus 5?

A recolha mostra que cinco tipos de queixa apareceram repetidamente, pelo que é útil para decidir contra quais riscos me devo proteger. Serve para identificar falhas, não para medir a satisfação nem para classificar modelos.

Reuni 1.008 excertos com datas entre 23 de julho e 29 de agosto de 2026. Vieram de 229 publicações e 779 comentários em 294 tópicos distintos do Reddit. Um comentário e a publicação a que responde não são testes independentes, e vários tópicos com muita atividade contribuíram com muitas entradas. Um dos registos tem a data de 23 de julho, um dia antes do anúncio público da Anthropic a 24 de julho. Por isso, trato as datas como metadados do Reddit, e não como prova de acesso antecipado. [14]

excertos negativos

1.008

tópicos distintos

294

publicações

229

comentários

779

Uma comparação justa da popularidade exigiria amostras equivalentes para o Fable, o Sol, versões anteriores do Opus e outros modelos, ajustadas ao número de utilizadores e à atividade de cada subreddit. Não tenho essas amostras. O que tenho é um registo detalhado dos problemas que as pessoas descreveram repetidamente depois de uma má sessão com o Opus 5.

Agrupei os excertos pela falha descrita, em vez de contar cada etiqueta livre como um problema distinto. Foi assim que cheguei aos cinco grupos acima. As falhas no cumprimento de instruções e o consumo de tokens surgiam, em geral, como parte desses problemas, e não como resultados separados. O agrupamento deu-me a lista prática de riscos contra os quais queria proteger o meu processo.

O que podem realmente corrigir melhores instruções para o Opus 5?

Melhores instruções podem reduzir respostas demasiado longas, verificações desnecessárias, delegação e expansão do âmbito. Não garantem que o modelo siga o plano, declare corretamente que a tarefa está concluída, escreva bem ou raciocine corretamente. A mudança útil não está num prompt engenhoso. Está numa definição mais clara da tarefa, apoiada por um processo e por verificações.

Quatro detalhes fazem a maior diferença no meu trabalho. Defino o resultado pedido, digo o que não pode mudar, indico a arquitetura existente que deve ser seguida e especifico as provas necessárias para considerar a tarefa concluída. Numa funcionalidade ampla, estes detalhes resultam da pesquisa e de um plano de arquitetura, não de uma versão mais longa da minha primeira ideia.

As instruções persistentes ajudam a definir regras aplicáveis a todas as tarefas. O Claude Code carrega o CLAUDE.md como contexto do projeto, pelo que este ficheiro é um local adequado para dizer que os problemas não relacionados devem apenas ser comunicados, que os padrões existentes devem ser reutilizados e que a conclusão exige resultados reais dos testes ou do build. A Anthropic avisa que este ficheiro serve de contexto, não de configuração imposta, e que instruções breves e específicas funcionam melhor do que um conjunto longo de regras sobrepostas. [3]

Esta limitação importa porque mesmo os utilizadores cuidadosos continuam a relatar falhas. Um dos tópicos do Reddit que confirmei descreve um CLAUDE.md conciso que foi ignorado. [12] Melhores instruções aumentam as probabilidades de sucesso, mas não tornam o utilizador responsável por um erro do modelo.

É também por isso que não diria a um utilizador frustrado que se limitasse a aprender a escrever prompts. Os relatos positivos mais convincentes mudaram o processo em torno do Opus. Um utilizador no Reddit passou a definição dos requisitos e a revisão para o Fable e entregou depois ao Opus uma especificação completa. O comportamento indesejado praticamente desapareceu. [11] É também assim que agora separo as funções em alterações grandes.

Como uso o Opus 5 em funcionalidades grandes

Mantenho uma conversa principal responsável pelo resultado e pela arquitetura. Essa conversa analisa o repositório, pede a agentes as informações em falta, decide o desenho da solução e escreve um plano com os sistemas afetados, aquilo que fica de fora, os riscos e os critérios de aceitação. Só então a implementação passa para agentes Opus, dividida em partes delimitadas.

Os agentes não recebem uma instrução vaga como “crie a funcionalidade”. Cada um recebe a parte relevante do plano, os ficheiros ou sistemas incluídos no âmbito, o comportamento que deve preservar, as verificações que deve executar e um ponto onde deve parar. A documentação da Anthropic sobre subagentes diz que cada um trabalha no seu próprio contexto e devolve um resumo à conversa principal. Isto protege o contexto principal, mas também significa que a mensagem de delegação tem de incluir os factos que o agente não consegue deduzir. [4]

Prefiro o Fable 5 para a conversa principal porque comunica com mais clareza e mantém uma visão geral melhor da arquitetura nos meus projetos. Depois, o Opus trata de grande parte da implementação. Esta é a minha preferência, não uma classificação geral, e é possível, em parte, porque pago o plano Max 20x. A Anthropic indica um preço mensal de 200 dólares e uma capacidade por sessão 20 vezes superior à do plano Pro. [13] Um processo que usa um modelo premium no planeamento e vários agentes Opus na execução não está igualmente disponível para todos os subscritores.

A mesma separação continua a ajudar quando o Opus é o único modelo disponível. Nesse caso, separo as fases por conversa em vez de as separar por modelo.

Como deve usar o Opus 5 se não tiver outro modelo?

Se você só tiver o Opus, use-o em todo o processo, mas não lhe peça que execute tudo numa única operação sem interrupções. Separe o planeamento da edição, guarde o plano acordado, implemente uma parte de cada vez que possa ser revista e comece com um contexto mais limpo quando o tipo de trabalho mudar.

Perante uma funcionalidade incerta, comece no modo de planeamento e peça ao Opus para analisar o repositório sem o alterar. O plano deve indicar os ficheiros e sistemas afetados, explicar a abordagem escolhida, registar perguntas por resolver e definir como cada parte será verificada. Reveja esse documento antes da implementação. A Anthropic recomenda separar a pesquisa e o planeamento da implementação quando a abordagem não é clara ou a alteração abrange vários ficheiros, mas observa que uma correção pequena e óbvia pode não justificar a etapa adicional de planeamento. [2]

Depois, dê à conversa de implementação apenas a primeira parte coerente. Uma parte bem escolhida pode ser revista e testada sem esperar pela funcionalidade completa. Se uma funcionalidade exigir semanas de trabalho a um programador, divida-a em partes que possam ser testadas de forma independente. Faça a divisão de acordo com as dependências e os limites de verificação, não por um número arbitrário de prompts.

Mantenha o plano fora da conversa para que sobreviva a uma reposição do contexto. Use /clear entre tarefas não relacionadas e envie a pesquisa do repositório para subagentes apenas quando for suficientemente extensa para justificar um contexto isolado. O Opus 5 já tem tendência para delegar, por isso mais agentes não são automaticamente melhores. [1] O objetivo é manter o contexto principal focado, não criar o maior número possível de agentes.

Por fim, analise as provas em vez de confiar no tom confiante da mensagem final. Leia o diff, execute as verificações relevantes e compare o resultado com os critérios de aceitação guardados. Se uma parte estiver errada, corrija-a e verifique-a antes de acrescentar a seguinte. Assim, um erro local não se transforma numa reescrita de toda a funcionalidade.

O que o Opus 5 ainda faz mal

Alguns problemas do Opus 5 mantêm-se mesmo com um bom processo. No meu uso, o texto continua mais difícil de ler do que o do Fable, o modelo continua a exigir mais supervisão do que eu gostaria e os limites explícitos não garantem que se mantenha dentro deles.

O Opus 5 faz agora parte do meu processo habitual de implementação. Não é o modelo que prefiro para a conversa principal sobre arquitetura e continuo a não o escolher para escrever um artigo sem uma revisão exigente. Uma implementação apresentada com confiança pode continuar a assentar numa premissa errada, por isso mantenho o plano e a revisão final fora do contexto do agente que executa o trabalho.

As queixas no Reddit ajudaram-me a identificar as falhas, mas não decidiram se o Opus poderia funcionar para mim. O meu erro na semana de lançamento foi tratar a qualidade da supervisão e a qualidade da implementação como se fossem a mesma coisa. Continuo a não confiar no Opus para supervisionar uma alteração grande, mas, quando o Fable mantém o plano e faz a revisão, confio muitas vezes no Opus para escrever o código.