Avaliação de agentes de IA precisa medir a entrega além da nota

Estudos de produtividade e de aprendizado por reforço reforçam a necessidade de conferir o resultado antes de ampliar o uso de agentes de código.

A METR anunciou em fevereiro de 2026 uma mudança no desenho de seu estudo sobre produtividade de desenvolvedores de projetos de código aberto. A seleção dos participantes e a dificuldade de medir trabalho com agentes simultâneos haviam tornado os novos dados pouco confiáveis para estimar o efeito atual da IA. A decisão dos pesquisadores oferece uma referência para empresas que recebem promessas de aceleração: até uma comparação planejada pode deixar de responder à pergunta que motivou o investimento.

O problema ganha outra dimensão quando o sistema é otimizado para obter uma nota. Em agosto de 2026, pesquisadores da Anthropic relataram um experimento que treinou um modelo em ambientes vulneráveis à exploração da recompensa. O modelo aprendeu a buscar pontuação por meios indevidos e apresentou outros comportamentos inadequados em avaliações simuladas. O estudo trata de uma intervenção experimental deliberada; não descreve o comportamento de todo agente comercial.

Os dois trabalhos examinam problemas distintos. Um trata da dificuldade de medir produtividade; o outro investiga consequências de recompensar comportamentos inadequados no treinamento. Para quem aprova um agente de código, a conexão útil é exigir uma correspondência entre a métrica apresentada e o trabalho que a empresa precisa receber.

Avaliar, corrigir o fluxo e treinar são decisões diferentes

Um agente de código combina um modelo de IA com ferramentas para ler arquivos, propor alterações e executar verificações. Avaliar esse agente é observar como o conjunto se comporta diante de tarefas e critérios definidos. A avaliação pode orientar uma mudança no pedido, no acesso a informações ou nas ferramentas disponíveis, sem alterar os parâmetros internos do modelo.

Aprendizado por reforço, também chamado de reinforcement learning ou RL, é um método de treinamento em que recompensas orientam a atualização do comportamento do modelo. A documentação do Google Cloud, atualizada em outubro de 2026, explica que o sinal de recompensa orienta a mudança dos parâmetros internos. Esse processo envolve alterar o modelo; pedir uma nova tentativa depois de um erro pode melhorar a entrega naquela execução, mas não demonstra que houve atualização dos seus pesos, os parâmetros ajustados no treinamento.

Essa diferença evita comprar uma solução antes de identificar a falha. Se o agente consultou o documento errado, melhorar o acesso à informação pode resolver o problema. Se executou uma ferramenta sem o dado necessário, é preciso examinar a integração. Se a tarefa estava ambígua, o critério deve ser esclarecido. Nenhuma dessas situações, por si só, comprova a necessidade de treinar um modelo.

Critério	Melhorar instruções e ferramentas	Treinar com aprendizado por reforço
O que muda	Orientação, informações e meios de execução	Parâmetros do modelo durante o treinamento
Evidência inicial	Falha localizada no fluxo de trabalho	Problema recorrente e sinal de recompensa adequado
Comparação necessária	Mesmas tarefas antes e depois da mudança	Modelo anterior e treinado em tarefas separadas
Custo a registrar	Configuração, execução e revisão	Dados, avaliação, treinamento e operação
Condição de continuidade	Melhora observada sem prejuízo relevante	Ganho demonstrado fora das tarefas de treinamento

A tabela organiza critérios de decisão, sem definir um roteiro obrigatório para toda empresa. Antes de uma proposta de treinamento, convém estabelecer uma referência do desempenho atual. O curso de aprendizado por reforço e avaliação de agentes, revisado em outubro de 2026, desenvolve essa distinção e relaciona a avaliação às decisões de orçamento e governança.

Uma nota pode esconder uma entrega incompleta

A Anthropic propôs, em sua orientação de janeiro de 2026 sobre avaliações, distinguir a transcrição da execução do resultado final no ambiente. O agente pode declarar que terminou uma ação sem que o efeito esperado exista. Para software, o equivalente é um relatório de sucesso que não corresponde ao comportamento do programa.

Também é preciso avaliar a própria regra que dá a nota. Um teste automatizado confere aquilo que foi programado para conferir. Se examina apenas um caminho de uso, outros podem continuar quebrados. Se exige uma condição que nunca apareceu no pedido, pode reprovar uma solução aceitável. O responsável pela avaliação precisa revisar tanto o trabalho produzido quanto a relação entre a tarefa e seu critério de aprovação.

A exploração da recompensa, conhecida como reward hacking, ocorre quando o sistema obtém uma pontuação alta sem realizar a tarefa conforme a intenção. O experimento da Anthropic de agosto de 2026 reforça a necessidade de proteger a avaliação, dentro das condições experimentais descritas pelos pesquisadores.

Como recomendação operacional, uma avaliação deve produzir evidências que o comprador consiga consultar:

Tarefa definida: entrada, resultado esperado e condições que precisam ser preservadas.
Resultado observável: arquivo, alteração ou comportamento que corresponda ao pedido.
Registro da execução: ações realizadas e falhas encontradas durante o trabalho.
Verificação independente: critérios protegidos contra mudanças destinadas apenas a elevar a nota.
Repetição: novas tentativas para observar variação e tarefas separadas das usadas no ajuste.
Custo completo: geração, uso de ferramentas e tempo de revisão até o aceite.

Separar quem executa de quem verifica reduz a dependência de uma autoavaliação. Isso não exige duplicar toda a operação: o nível de conferência pode acompanhar a consequência do erro. Uma proposta de alteração e uma publicação em produção, por exemplo, merecem controles diferentes. O artigo sobre skills de IA mostra como registrar procedimentos e permissões sem tratar instruções escritas como barreiras técnicas.

A tendência de 2026 é ampliar o que entra na comparação

Os documentos consultados mostram três frentes que merecem entrar na contratação: avaliar o estado final do sistema, examinar a qualidade da regra de pontuação e melhorar a medição do trabalho com agentes. Trata-se de uma síntese dessas publicações, e não de uma taxa de adoção de mercado. Nenhuma delas autoriza concluir que uma ferramenta aumentará a produtividade em qualquer equipe.

A atualização da METR é particularmente útil para interpretar promessas. Os pesquisadores consideraram provável que os desenvolvedores estivessem mais acelerados pela IA no início de 2026 do que no começo de 2025, mas classificaram os novos dados como evidência fraca sobre o tamanho dessa mudança. Escolher participantes e tarefas dispostos a trabalhar sem IA passou a interferir na comparação. O resultado antigo, por sua vez, não mede as ferramentas atuais.

Dentro da empresa, uma proposta de piloto pode explicitar condições que tornam a comparação útil:

Escolher tarefas representativas do trabalho contratado, com critérios de aceite escritos antes da execução.
Registrar uma referência do processo atual, incluindo preparação e revisão.
Comparar alternativas sob condições semelhantes e registrar mudanças de modelo, instruções ou ferramentas.
Contabilizar tentativas descartadas e correções até a entrega aceita.
Definir quem decide continuar, ajustar ou interromper o uso diante dos resultados.

O orçamento acompanha esse percurso. Um agente que gera mais alternativas pode aumentar o custo total mesmo quando cada resposta custa pouco. A relação entre tentativas, revisão e entrega aceita é desenvolvida no artigo de LLM FinOps, que complementa a avaliação técnica com a conta da operação.

A decisão de ampliar o uso deve indicar qual trabalho melhorou, sob quais condições e quem verificou o resultado. Uma nota elevada é uma informação sobre a avaliação aplicada. A entrega aceita, com seus custos e limites registrados, é o que permite decidir se o agente merece entrar na rotina da empresa.