Avaliações Contínuas: o Sistema Operacional dos Agentes de Codificação

A antiga barganha com assistentes de programação era simples: eles sugeriam uma linha, você apertava os olhos, e talvez ninguém saísse machucado. Agora, agentes de programação podem chamar ferramentas, modificar estados e tropeçar por um repositório como um estagiário muito confiante com acesso root. “Vibes” não são mais uma estratégia de QA. São uma vela perfumada dentro de um túnel de vento.

O enquadramento útil da LetsLearnGenAI é que as avaliações estão se tornando o sistema operacional da programação assistida por IA. Não a camada brilhante do aplicativo, nem o papel de parede do ranking, mas a superfície de controle que diz às equipes o que mudou, o que quebrou e se o agente deve continuar trabalhando ou receber uma caixinha de suco e ser escoltado para fora do pipeline de build.

A Anthropic Dá a Definição Entediante de Que Precisamos

A Anthropic define uma avaliação como um teste para um sistema de IA: fornecer uma entrada e, em seguida, aplicar uma lógica de correção à saída para medir o sucesso. Em sua publicação de engenharia de 09 de janeiro de 2026, a Anthropic afirma que boas avaliações ajudam equipes a lançar agentes com mais confiança, tornando falhas e mudanças de comportamento visíveis antes que cheguem aos usuários. A empresa também destaca por que agentes são mais difíceis de medir do que chatbots: eles operam ao longo de muitas interações, chamam ferramentas, modificam estados e se adaptam com base em resultados intermediários.

@title Estrutura de avaliação
@source Demystifying evals for AI agents

  Input
    │
    ▼
  AI system
    │
    ▼
  Output
    │
    ▼
  Grading logic
    │
    ▼
  Success measure

@caption A Anthropic descreve avaliações como entrada, saída, lógica de correção e medição de sucesso.

Essa definição soa quase ofensivamente simples, e é por isso que ela importa. Agentes de repositório não estão apenas prevendo o próximo token; eles estão realizando ações dentro de ambientes cheios de testes frágeis, dependências assustadoras e um arquivo chamado final_final_really.py. Se você não consegue repetir uma tarefa e avaliar o resultado de forma consistente, você não está adotando um agente. Você está invocando um.

O Tipo de Tarefa É a Variável Sorrateira

Um estudo estratificado por tipo de tarefa no arXiv comparou OpenAI Codex, GitHub Copilot, Devin, Cursor e Claude Code em 7.156 pull requests do conjunto de dados AIDev. O artigo descobriu que o tipo de tarefa teve um grande efeito: tarefas de documentação chegaram a 82,1% de aceitação, enquanto novos recursos chegaram a 66,1%, uma diferença de 16 pontos percentuais que superou a variação típica entre agentes na maioria das tarefas. Ele também relatou que Devin mostrou a única tendência positiva consistente na taxa de aceitação, de 0,77% por semana ao longo de 32 semanas, enquanto os outros agentes permaneceram em grande parte estáveis.

Essa é a parte que as equipes deveriam tatuar no lado de dentro do painel de CI. Escolher um agente de programação pela pontuação média em benchmarks é como escolher um restaurante pelo número de garfos na gaveta. Sua suíte local de avaliações deve separar as tarefas pelo trabalho que você realmente faz: documentação, correções de bugs, refatorações, migrações, testes e novos recursos. Caso contrário, o agente que parece brilhante em tarefas fáceis de manutenção pode silenciosamente devorar sua arquitetura como um guaxinim em uma sala de servidores.

Avaliações de Produção Precisam de Tarefas com Cara de Produção

O artigo REAP argumenta que a implantação em produção de agentes de programação de IA precisa de sinais de avaliação rápidos e reproduzíveis. Ele afirma que testes A/B online podem levar semanas e colocar a experiência do usuário em risco, que implantação em modo sombra não produz sinais reproduzíveis entre execuções, e que benchmarks públicos podem divergir das cargas de trabalho reais em distribuição de linguagens, estilo de prompt e estrutura da base de código. O REAP propõe selecionar automaticamente benchmarks derivados de produção a partir de sessões reais entre desenvolvedores e agentes, sem rotulagem manual.

Esta é a ponte entre avaliações de pesquisa e disciplina operacional. Uma avaliação útil para uma equipe não é um museu de problemas de quebra-cabeça; é uma suíte viva de regressão construída a partir da bagunça que sua base de código realmente produz. O artigo REAP também sinaliza minas terrestres práticas: prompts impossíveis de testar, testes desalinhados e testes instáveis podem comprometer a confiabilidade. Tradução: se sua avaliação não consegue diferenciar um agente ruim de um teste ruim, parabéns, você construiu uma máquina de neblina com YAML.

Benchmarks São Necessários, Não Suficientes

O ProjDevBench aponta para uma fraqueza diferente: desenvolvimento de projetos de ponta a ponta. Segundo seu resumo no arXiv, o benchmark entrega requisitos de projeto a agentes de programação e avalia os repositórios resultantes usando testes de Online Judge mais revisão de código assistida por LLM. Ele cobre 20 problemas de programação em 8 categorias, avalia seis agentes de programação e relata uma taxa geral de aceitação de 27,38%.

Essa baixa taxa de aceitação não é motivo para pânico; é motivo para definir escopo com responsabilidade. O artigo diz que agentes lidam com funcionalidades básicas e estruturas de dados, mas têm dificuldade com design de sistemas complexos, otimização de complexidade de tempo e gerenciamento de recursos. Para quem constrói, o movimento prático é óbvio: comece com tarefas estreitas e de alto sinal, nas quais a correção possa ser verificada, e só expanda quando suas avaliações mostrarem que o agente está melhorando. Autonomia sem medição é apenas autocomplete usando um sobretudo.

Mantenha o Humano no Loop, de Preferência Acordado

O artigo Agents That Teach acrescenta um modo de falha mais suave, mas importante: o aprendizado do desenvolvedor. Ele argumenta que, à medida que desenvolvedores delegam tarefas substanciais de programação a agentes autônomos, o aprendizado incidental pode ser interrompido, criando o que os autores chamam de Dívida de Conhecimento. O artigo propõe seis princípios de design e apresenta o SHIELD, um sistema multiagente destinado a revelar aprendizados contextuais e fora do fluxo principal a partir do próprio raciocínio do agente de programação.

Isso importa porque avaliações devem medir mais do que se os testes estão verdes. Equipes também precisam perguntar se os desenvolvedores conseguem explicar a mudança, mantê-la e perceber quando o agente inventa com confiança uma pequena catedral de bobagens. O próximo passo prático não é um império gigantesco de avaliações. Construa uma pequena suíte local, execute-a em tarefas reais, estratifique por tipo de tarefa, acompanhe regressões e continue adicionando casos a partir de falhas encontradas em produção.

Se o agente vai dirigir, as avaliações são o volante, não os dados felpudos no retrovisor.