Por que o Opus 5 parece pior de usar

Uma piora na interação, não necessariamente na capacidade

Na opinião do autor e de colegas com quem conversou, trabalhar com o Opus 5 parece um retrocesso em relação ao Opus 4.7, ao Opus 4.8 e ao Fable. Ele ressalva, porém, que não está afirmando uma queda de capacidade: o Opus 5 seria mais capaz que os modelos anteriores e chegaria a rivalizar com o Fable em benchmarks. O problema apontado está na forma como o modelo trabalha com o usuário.

Segundo o relato, os outros modelos tendem a parar e fazer perguntas quando a intenção não está clara, evitam fazer suposições sem verificar e não reinterpretam ou atualizam os planos do usuário sem pedir autorização. O Opus 5, por contraste, exigiria um acompanhamento mais cuidadoso, descrito pelo autor como uma necessidade de “babysitting”. Para quem usa um agente de programação, essa diferença de comportamento pode ser mais importante do que uma vantagem abstrata em capacidade ou desempenho de benchmark.

A hipótese sobre os incentivos de treinamento

O autor apresenta como “especulação sem base” uma possível explicação para esse comportamento. Ele suspeita que duas forças estejam se combinando na Anthropic e nos laboratórios de fronteira em geral. A primeira seria o objetivo de criar uma IA capaz de se aperfeiçoar e iniciar um processo recursivo de evolução rumo à AGI ou à ASI. A segunda seria a pressão para obter pontuações altas em benchmarks.

A crítica aos benchmarks é que muitas tarefas seriam mal definidas, injustas, exploráveis ou simplesmente defeituosas. Ainda assim, uma boa tarefa de benchmark costuma ser autocontida e solucionável: não deveria exigir dicas, a capacidade de adivinhar a intenção de quem a criou ou informações externas. Isso não significa que exista apenas uma resposta correta, mas que todas as respostas inequivocamente corretas deveriam receber a mesma avaliação.

Na interpretação proposta, selecionar modelos pelo desempenho nesses testes - inclusive treiná-los em tarefas de RLVR - favorece sistemas que fazem suposições ousadas e geralmente corretas diante de ambiguidades. Ao mesmo tempo, isso penalizaria modelos inclinados a interromper o trabalho para pedir esclarecimentos ou orientação. O comportamento que ajuda a resolver uma tarefa autocontida pode, portanto, ser menos adequado para situações abertas.

O conflito com o trabalho real

O autor afirma que essa tendência é especialmente problemática para agentes de programação. Por mais que o usuário tente, é quase impossível registrar e disponibilizar ao agente todo o contexto relevante, suas intenções, as implicações comerciais, as restrições orçamentárias e outros fatores. Sempre haverá ambiguidades e decisões a tomar.

Nesse cenário, seria desejável que o agente reconhecesse quando não tem informação suficiente e perguntasse antes de agir. A vida real não funciona como um benchmark: nem toda pergunta tem uma resposta garantidamente correta, e às vezes nem sequer existe um conjunto definido de respostas corretas. Como as decisões podem trazer consequências reais, o autor diz não querer que um agente simplesmente escolha o que considera seu melhor palpite. A conclusão é uma preferência por modelos que saibam interromper, verificar a intenção do usuário e preservar seus planos, mesmo que isso não maximize o desempenho em avaliações padronizadas.