Fable 5, Opus 4.8 e Sonnet 4.6: como comparar LLMs de forma honesta no seu próprio código

Quando uma nova modelo é lançada, o anúncio responde à pergunta «quão melhor ela é nos benchmarks» — e não responde à única pergunta que me interessa: o que ela vai mudar no meu trabalho. Fiz um experimento controlado: três modelos Claude — Fable 5, Opus 4.8 e Sonnet 4.6 — receberam uma tarefa literalmente idêntica de auditar a base de código deste blog, cada uma em uma cópia isolada do repositório, com uma rubrica de avaliação acordada de antemão. No artigo — a própria metodologia, que pode ser repetida em qualquer projeto, os resultados e, separadamente, como o experimento quebrou duas vezes e o que isso ensinou.

Por que os benchmarks não respondem à minha pergunta

Os benchmarks públicos têm dois problemas, e ambos são fundamentais. O primeiro é a contaminação de dados: os exemplos de teste vazam para os conjuntos de treinamento, e a modelo parcialmente «lembra» as respostas em vez de resolver a tarefa. Não é uma suspeita marginal, mas objeto de toda uma linha de pesquisa: a revisão de Xu e coautores (2024) sistematiza os estudos sobre contaminação de benchmarks, e a revisão da EMNLP 2025 registra a resposta da indústria — a transição de testes estáticos para testes gerados dinamicamente.

O segundo problema é mais simples: o benchmark não mede a minha tarefa. Não preciso de uma modelo que resolva melhor do que todas as tarefas de olimpíada. Preciso de uma modelo que encontre bugs reais no meu blog em Laravel, não invente inexistentes e prove que seu fix funciona.

Daí decorre uma ideia simples: o melhor banco de testes para comparar modelos é o próprio projeto. O código dele, nessa combinação, não está nos conjuntos de treinamento, as tarefas nele são exatamente aquelas pelas quais eu pago, e posso verificar os resultados à mão, porque conheço esse código.

Design do experimento: um prompt, três mundos isolados

A tarefa para as três modelos foi literalmente idêntica — só diferiam o nome da branch e a pasta de resultados. Quatro fases: auditoria do sistema bilíngue de artigos do blog com prova de cada achado na forma de файл:строка com citação de código; escolha de soluções para os três principais achados com descrição dos trade-offs; implementação de um fix com autoverificação; nota sobre os resultados em russo e inglês. Um ciclo completo de trabalho de engenharia, e não um «pergunta-resposta» isolado — abordagem que a própria Anthropic recomenda: avaliar agentes em tarefas de um produto real, por uma rubrica acordada antes da execução.

Três regras tornaram a comparação honesta:

Isolamento. Cada modelo trabalhou em um git worktree separado — cópia própria do diretório de trabalho com sua própria branch. As modelos fisicamente não podiam ver os resultados umas das outras nem interferir umas nas outras.

Proteção contra alucinações — no próprio prompt. A linha-chave da tarefa: «um achado inventado (código inexistente, linha errada) é pior do que a ausência de achado». Sem esse estímulo, a modelo a quem se pede para encontrar problemas tende a «encontrá-los» de qualquer forma. Com ele — cada achado é obrigado a passar pela verificação manual.

Exclusão das dicas da pontuação. No repositório há um CLAUDE.md que descreve as armadilhas conhecidas do projeto — por exemplo, caminhos relativos para assets que quebram em URLs com prefixo de idioma. As três modelos leem esse arquivo, então tais achados são «de graça»: contam para o cuidado, mas não para a profundidade.

Rubrica: avaliar apenas o que se pode verificar à mão

Antes da execução, fixei seis eixos de cinco pontos: precisão da auditoria (verificação manual de uma amostra de achados por файл:строка), profundidade (achados confirmados que não estão nas dicas), qualidade do raciocínio sobre trade-offs, código e realidade da autoverificação, qualidade do texto em russo e inglês, disciplina (zero perguntas ao humano, nenhuma violação de restrições). O princípio é o mesmo de uma boa revisão de código: quanto menos um eixo depende de gosto e mais de fato verificável, mais se pode confiar nele.

Como tudo quebrou na primeira vez

A primeira execução eu fiz errado — e isso acabou sendo a parte mais portável do experimento. Abri três sessões interativas em paralelo na mesma pasta do repositório. Em poucos minutos, na árvore de trabalho havia alterações não commitadas impossíveis de atribuir: um checkout compartilhado significa que, quando uma sessão faz git checkout -ba branch muda para as três, e suas alterações e commits se misturam. Uma das sessões, além disso, fez git stash e varreu para dentro dele tudo o que havia — incluindo meus próprios arquivos, que não tinham relação com o experimento.

“Agentes de IA em paralelo na mesma pasta não são um experimento paralelo. É um grande conflito com três autores.”

– a conclusão que me custou um reinício

Os resultados de duas sessões tiveram de ser considerados inutilizáveis: mesmo que tivessem sido concluídos até o fim, eu não poderia dizer honestamente de quem eram as edições que estava avaliando. A segunda execução — já em worktrees isolados — esbarrou nos limites do plano: dois agentes morreram na largada, e o terceiro travou, continuando a parecer "em execução" na interface. O diagnóstico veio do sistema de arquivos, não do indicador de status: em vinte minutos, nenhum arquivo apareceu em sua cópia de trabalho. Esta é a segunda lição portável: a vivacidade do agente é verificada pelas mudanças no disco. Após a reinicialização, os três modelos completaram o ciclo completo em condições iguais.

Resultados: onde os modelos são iguais e onde diferem

O resultado mais importante é o que não aconteceu: não há alucinações em nenhum dos modelos. Verifiquei manualmente três ou mais achados de cada um — todas as citações e números de linha estão exatos até o caractere. Para tarefas de auditoria, este é o principal limiar de confiança, e os três o superaram.

A partir daí começam as diferenças:

	Fable 5	Opus 4.8	Sonnet 4.6
Achados confirmados	11	5	9
Únicos não triviais	3	1	2
Autoverificação do fix	renderização de integração em BD temporária, xmllint, atribuição de teste alheio que falhou	linter + renderização; pegou o próprio bug	apenas linter e lista de rotas
Tokens / tempo	164k / 21 min	101k / 12 min	131k / 12 min
Total pela rubrica (de 30)	30	24	25,5

As diferenças qualitativas são mais informativas que as notas. Opus 4.8 foi o único que não notou o cabeçalho quebrado Content-Type no sitemap (os outros dois o encontraram) e o deixou em seu próprio fix; e em seu texto em russo vazou uma palavra em inglês — "и even путь к картинке". Sonnet 4.6 fez o fix correto, mas sua autoverificação foi declarativa: linter em vez de execução. Fable 5 destacou-se justamente na autoverificação: descobriu que php na minha máquina é um wrapper sobre um contêiner docker montado no diretório principal, reconstruiu todas as verificações por meio de contêineres descartáveis e rodou seu fix de forma integrada em uma base temporária. A diferença entre "eu fiz" e "eu provei que fiz" é justamente o eixo mais diferenciador para tarefas agênticas.

Outro sinal útil é a convergência: os três modelos nomearam independentemente o mesmo problema com o sitemap como principal achado. Quando auditores independentes convergem no achado principal, isso é um substituto barato da concordância entre especialistas: o problema é quase certamente real.

Juiz entre os participantes

A avaliação pela rubrica foi realizada por Fable 5 — o mesmo modelo que participou da comparação. Esta é uma falha metodológica, e é preciso falar dela diretamente: juízes LLM sistematicamente superestimam seus próprios textos, e a tendência é tanto mais forte quanto melhor o modelo reconhece seus próprios textos — isso é mostrado no trabalho de Panickssery e coautores na NeurIPS 2024. É possível mitigar o viés de duas maneiras, e usei ambas: primeiro, deslocar ao máximo a rubrica de eixos de gosto para fatos verificáveis — a exatidão das linhas, a completude do fix, a palavra estrangeira vazada não dependem das simpatias do juiz; segundo, declarar explicitamente o conflito e entregar os eixos controversos à verificação cruzada de outro modelo ou de um humano. Os eixos subjetivos do meu resultado — qualidade do texto, qualidade do raciocínio — devem ser lidos com essa ressalva.

Limitações de honestidade

Uma execução por modelo é n=1: diferenças de um ou dois pontos não significam nada, só vale confiar em lacunas qualitativas — um bug perdido, a profundidade da autoverificação. O experimento mede três modelos em uma tarefa em um domínio; "Fable 5 é melhor em geral" não decorre disso. E vale lembrar do custo: o modelo top gastou 1,6 vez mais tokens e quase o dobro do tempo que o participante mais econômico, e seu token pelo preço de tabela ainda é mais caro por si só — para tarefas regulares, isso é um argumento ponderável em favor de modelos mais simples.

O que eu levo comigo

A metodologia se resumiu a uma lista de verificação curta que funciona para qualquer projeto e quaisquer modelos:

• Tarefa-teste — ciclo completo de trabalho real no próprio código, não um probleminha sintético.
• Um prompt para todos, isolamento via worktrees separados, resultados em branches separadas.
• No prompt — o preço explícito da alucinação: um achado inventado é pior que a ausência de achado.
• Dicas disponíveis a todos (documentação, notas no repositório) são excluídas da contagem de profundidade.
• A rubrica é fixada antes da execução e se apoia em fatos verificáveis, não em impressão.
• Verificar à mão a amostra de achados; a coincidência dos achados principais entre modelos independentes é um sinal de sua realidade.
• Juiz-participante — conflito declarado: eixos controversos devem ser entregues à avaliação cruzada.
• Verificar a vivacidade do agente pelo disco, não pelo indicador na interface.

Bônus que não estava no plano: o experimento se pagou sozinho. Três auditorias independentes encontraram problemas reais no blog — de sitemap sem páginas em inglês a consultas mortas no controller — e dois fixes prontos já estão nas branches, aguardando a transferência para produção. Comparar modelos no próprio código, ao contrário de ler benchmarks, deixa para trás não apenas uma opinião.

Fontes e referências

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — sistematização do problema da contaminação de benchmarks; o principal argumento em favor de testes no próprio código.
• Benchmarking LLMs Under Data Contamination: From Static to Dynamic Evaluation (EMNLP 2025) — como a indústria está migrando de testes estáticos para dinâmicos; meu experimento é um caso particular de teste dinâmico.
• Demystifying evals for AI agents (Anthropic Engineering, 2026) — a prática de avaliação de agentes: tarefas de um produto real, rubricas verificáveis, distinção entre trajetória e resultado.
• LLM Evaluators Recognize and Favor Their Own Generations (NeurIPS 2024) — por que o modelo-juiz superestima as próprias avaliações e o que fazer a respeito.
• Run parallel sessions with worktrees (Claude Code Docs) — o mecanismo nativo de isolamento de sessões paralelas de agentes, sem o qual a primeira execução do experimento desmoronou.