Vozes
Hamel Husain: ensine o agente de código a se avaliar
Hamel Husain propõe dar ao agente de código as skills de avaliação. Veja por que a infraestrutura em volta do agente rende mais que trocar de modelo.
Enquanto boa parte do mercado discute qual modelo é o mais poderoso do mês, Hamel Husain está mirando outra coisa: a infraestrutura em volta do agente. Husain é um dos nomes mais respeitados em avaliação de IA, com passagem por Airbnb e GitHub e um histórico de ter ajudado mais de 50 empresas e ensinado mais de 4.000 pessoas a montar sistemas de eval. No começo de 2026, ele publicou um conjunto de skills para que o próprio agente de código rode as avaliações do trabalho que produz. A tese por trás é simples e desconfortável para quem só troca de modelo esperando milagre: o que separa IA que funciona de IA que impressiona na demo é o ciclo de avaliação, não o tamanho do modelo.
A tese: infraestrutura rende mais que modelo
O argumento de Husain se apoia num caso concreto que a OpenAI descreveu na sua engenharia de harness. A empresa construiu um produto inteiro com agentes de código, algo na ordem de 1 milhão de linhas de código, 1.500 pull requests, com três engenheiros, em cinco meses. A conclusão que Husain destaca é a que interessa: melhorar a infraestrutura ao redor do agente rendeu mais retorno do que melhorar o modelo. Os agentes consultavam traces distribuídos para verificar o próprio trabalho contra a evidência de execução. Não era o modelo ficando mais inteligente, era o sistema em volta ficando mais capaz de dizer se o resultado estava certo.
Daí vem a frase que resume a filosofia toda: documentação diz ao agente o que fazer, telemetria diz se funcionou, e eval aplica esse mesmo princípio à qualidade da saída de IA. É uma reformulação poderosa. A gente já aceita que software precisa de log e de teste. Husain está dizendo que a saída de um modelo precisa da mesma disciplina, e que essa disciplina pode ser instalada como uma capacidade que o agente executa, não como um projeto paralelo que ninguém tem tempo de tocar.
Por que o placar genérico de alucinação engana
O exemplo que ele usa é didático e vale para qualquer time. Imagine um bot de suporte. Num caso, ele diz ao cliente "seu plano inclui devolução grátis" quando não inclui. Noutro, ele diz "cancelei seu pedido" quando ninguém pediu. Os dois são alucinações, mas são falhas de natureza diferente: uma erra um fato, a outra inventa uma ação. Se você joga tudo num "score de alucinação" único, os dois problemas se misturam e o mais grave, inventar uma ação com efeito no mundo real, passa despercebido.
Essa é a crítica central à avaliação preguiçosa. Métrica agregada demais esconde exatamente o erro que você mais precisa pegar. O caminho que Husain propõe é o oposto: olhar as saídas reais, categorizar os tipos de falha, criar um vocabulário do que está quebrado e então escrever avaliadores específicos para cada tipo. É trabalho de análise de erro, não de dashboard bonito.
As skills, e o que elas dizem sobre o método
O pacote que ele abriu tem uma sequência clara. Para quem está começando, a skill de auditoria inspeciona o pipeline atual, roda diagnóstico em seis áreas, análise de erro, desenho de avaliador, validação de juiz, revisão humana, dado rotulado e higiene de pipeline, e devolve uma lista priorizada de problemas. Para quem já tem prática, há skills soltas: análise de erro para ler traces e categorizar falha, geração de dado sintético para quando falta exemplo real, escrita de prompt de juiz no formato binário passa ou não passa, validação do avaliador calibrando o juiz automático contra rótulo humano com taxa de acerto e correção de viés, avaliação de RAG separando recuperação de geração, e construção de interface de anotação para revisão humana.
O detalhe que importa: ele avisa que essas skills são um ponto de partida, não a resposta final. Elas cobrem só a parte que generaliza entre projetos. A avaliação que realmente performa é a que você escreve para o seu domínio, o seu stack e o seu dado. É a mesma lógica que aparece quando se discute que avaliar é o gargalo real da IA em produção: a ferramenta ajuda, mas o critério de qualidade é seu.
A nossa leitura para quem opera
Três pontos práticos para o time brasileiro.
Primeiro, pare de esperar o modelo perfeito. A busca pelo maior modelo do mês é uma forma de procrastinar a parte difícil. O trabalho que muda o resultado em produção é montar o ciclo de avaliação, e esse trabalho independe de qual laboratório está na frente no benchmark da semana. Enquanto o mercado discute custo por token e o teto do orçamento, quem monta eval descobre onde o gasto está sendo desperdiçado com saída ruim.
Segundo, use o agente para construir a própria avaliação, mas não terceirize o julgamento. O agente instrumenta, orquestra e gera interface. O que é uma resposta boa, isso continua sendo definido por gente que entende o negócio. A promessa não é "a IA se avalia sozinha", é "a IA faz o trabalho braçal da avaliação que você desenhou".
Terceiro, comece pela análise de erro, não pelo dashboard. Antes de montar métrica, olhe as saídas reais do seu sistema e escreva o que está quebrado. O vocabulário de falha que sai daí é o que transforma um "a IA às vezes erra" impreciso em um plano concreto de correção. Como a disciplina de descobrir o problema antes de construir, a análise de erro é o trabalho pouco glamouroso que decide se o produto de IA melhora ou fica patinando.
No fundo, Husain está devolvendo o foco para onde ele deveria estar. A pergunta que importa não é "qual o melhor modelo", é "como eu sei se o meu sistema está funcionando". Quem responde essa segunda pergunta com método sai na frente, mesmo rodando um modelo mediano.
Se o seu time coloca IA em produção sem um ciclo de avaliação de verdade, chame a gente no WhatsApp para montar a análise de erro e os avaliadores do seu caso.
Fontes
Perguntas frequentes
O que é uma eval de produto e por que ela é diferente de um benchmark?
Benchmark de modelo, como os testes gerais de capacidade que aparecem nos anúncios de lançamento, mede se um modelo é bom em tarefas genéricas. Eval de produto mede se o seu pipeline funciona na sua tarefa, com o seu dado. São coisas diferentes. Um modelo pode ir muito bem num benchmark público e falhar feio no seu caso específico, porque o seu contexto, os seus prompts e os seus dados não são os do benchmark. Hamel Husain defende que a avaliação que importa para quem coloca IA em produção é a de produto: você olha as saídas reais do seu sistema, categoriza onde ele erra, escreve avaliadores para cada tipo de erro e valida esses avaliadores contra julgamento humano. É trabalho de operação, não de marketing de modelo, e é o que de fato reduz falha em produção.
Dá para o próprio agente de código cuidar da avaliação?
Em parte, e essa é a proposta de Husain. Os agentes de código de hoje já instrumentam aplicações, rodam experimentos, analisam dados e constroem interfaces. O trabalho tedioso de montar a infraestrutura de eval, instrumentar o app, orquestrar experimentos, gerar interface de anotação, cabe bem ao agente. O que o agente ainda não sabe sozinho é o que fazer com isso: qual erro procurar, como desenhar o avaliador, como calibrar um juiz automático contra rótulo humano. Por isso ele publicou skills que ensinam justamente essa parte. A leitura para o operador é que a avaliação deixa de ser um projeto separado e caro e vira uma capacidade que você instala no fluxo do agente, desde que alguém defina o critério de qualidade. O agente executa, mas o julgamento sobre o que é bom continua sendo humano.