Seu agente de IA resolve a issue de verdade, ou só parece resolver?

A confiança na IA não começa no modelo, começa no processo.

Esta é a sétima parte de uma série sobre a metodologia que uso para continuar sendo, de fato, o responsável pelo que um agente de IA produz: o caso aplicado do artigo anterior, sobre auditoria e verificação.

Se eu te pedisse para provar, agora, que o agente de IA que você usa todos os dias realmente resolve as tarefas que recebe, não “parece resolver”, não “geralmente funciona na minha experiência”, mas resolve, de forma verificável, contra um conjunto de casos reais, você teria como responder?

Disclaimer: este texto reflete minha visão prática sobre o tema, construída em projetos pessoais e profissionais. Não representa, necessariamente, a posição oficial de nenhuma organização à qual eu esteja afiliado.

A maioria das pessoas que trabalha com agentes de IA no dia a dia não tem essa resposta pronta, porque a confiança que constroem na ferramenta é anedótica: acumula-se tarefa após tarefa, sem nenhum momento formal de “vamos medir isso de verdade”.

Funciona até não funcionar, até o dia em que um overclaiming passa despercebido, ou uma correção que “parecia certa” nunca chega a se conectar ao caminho real de execução: exatamente os problemas que descrevi no início desta série.

O benchmark que a indústria construiu para não depender de sensação

A comunidade de pesquisa que constrói e avalia agentes de IA para tarefas de engenharia de software enfrentou essa mesma pergunta em escala, e a resposta que encontrou tem nome: SWE-bench. É um benchmark que testa agentes contra issues reais, não problemas sintéticos desenhados para serem fáceis de avaliar, mas bugs e pedidos de funcionalidade genuínos, extraídos de pull requests e issues de repositórios open source de verdade.

A versão original reúne 2.294 tarefas coletadas de doze repositórios GitHub, majoritariamente em Python. A versão Verified é um subconjunto de 500 tarefas, criado pela própria OpenAI e curado por anotadores humanos especificamente para garantir que cada tarefa esteja bem especificada e possa ser avaliada de forma confiável, sem ambiguidade sobre o que conta como “resolvido”.

Por um bom tempo, essa foi a régua de referência da indústria. Os modelos de fronteira foram subindo de pontuação, ano após ano, contra esse mesmo conjunto de 500 tarefas. E é aí que a história deste artigo dá uma volta que o benchmark em si não previu.

Quando o próprio benchmark parou de provar o que dizia provar

Em fevereiro de 2026, a equipe de avaliação da própria OpenAI publicou um resultado desconfortável: testou se GPT-5.2, Claude Opus 4.5 e Gemini 3 Flash Preview conseguiam reproduzir, de memória, a correção exata de tarefas do SWE-bench Verified, incluindo nomes de variáveis e comentários inline que não aparecem em lugar nenhum do enunciado do problema. Os três conseguiram. Isso é a marca registrada de contaminação: o modelo não está resolvendo o problema, está reconhecendo que já viu esse problema, com a resposta certa, nos próprios dados de treinamento.

Não parou aí. Auditando 138 tarefas em que um dos modelos falhava de forma consistente, a equipe encontrou que 59,4% delas tinham problemas estruturais no próprio teste: 35,5% exigindo um nome de função específico que o enunciado nunca mencionava, 18,8% checando funcionalidades que o problema original nunca pedia.

A OpenAI parou de reportar o SWE-bench Verified como métrica de capacidade de fronteira por causa disso, e passou a recomendar o SWE-bench Pro: um benchmark mais novo, com bases de código privadas, estruturalmente mais resistente a contaminação porque essas bases nunca poderiam ter vazado para dados de treinamento de terceiros.

O número que mais expõe o tamanho do problema: modelos que passavam de 70% no antigo Verified pontuam cerca de 23% na parte pública do SWE-bench Pro, e menos ainda nas tarefas privadas. Uma queda de quase 50 pontos, nos mesmos modelos, só por trocar o instrumento de medição.

O paralelo com o protocolo vermelho-então-verde não é coincidência, e ficou mais forte, não mais fraco

SWE-bench, na essência, tentou aplicar em escala industrial exatamente o mesmo princípio que descrevi como uma das três práticas sempre-ativas desta metodologia: nada conta como corrigido até existir prova reproduzível, não uma impressão de que parece certo.

O que a história da contaminação revela é que o próprio instrumento de prova pode se corromper silenciosamente com o tempo, e que ninguém percebe isso até alguém, deliberadamente, desconfiar do próprio benchmark e auditá-lo como se fosse código de produção. É o mesmo princípio de “nunca aceite o relatório de uma auditoria como fato sem checar contra o registro bruto”, só que aplicado à ferramenta de avaliação em si, não ao trabalho que ela avalia.

Isso não invalida a ideia por trás do SWE-bench. Reforça exatamente o ponto central desta série: qualquer prova, mesmo uma boa, tem prazo de validade, porque o mundo (e os dados de treinamento do próximo modelo) muda ao redor dela. Um teste que provava algo real ano passado pode ter parado de provar qualquer coisa, silenciosamente, sem que ninguém tenha mudado uma linha de código.

Aplicando a mesma lógica em escala de projeto, não de indústria

Você não precisa construir um SWE-bench inteiro para se beneficiar do mesmo princípio, nem sofrer o mesmo problema de contaminação, se tomar um cuidado específico: seus próprios casos de teste, ao contrário de um benchmark público, não vazam para o próximo modelo de fronteira treinado por terceiros.

A prática concreta que eu recomendaria é simples de descrever, ainda que exija disciplina para manter: guarde um pequeno conjunto de issues reais já resolvidas no seu próprio projeto (bugs de complexidade variada, com a correção real e os testes que a comprovam já conhecidos) e, periodicamente, rode esse mesmo conjunto contra a configuração atual do seu agente, do mesmo jeito que rodaria uma suíte de regressão.

Não é para avaliar o modelo em abstrato: isso já é feito, com os problemas que acabei de descrever, por benchmarks públicos em escala que nenhum projeto individual replica. É para avaliar a sua configuração específica: os guardrails que você escreveu, o contexto que você fornece, os limites de escopo que você define.

Um agente de fronteira mal configurado pode performar pior, no seu projeto específico, do que um mais simples bem guiado. Isso só aparece quando alguém mede, não quando alguém assume.

À luz do que aconteceu com o SWE-bench: se o seu próprio conjunto de casos de teste um dia acabar publicado, discutido publicamente, ou incorporado a algum material de treinamento (documentação pública, um post de blog, um repositório aberto), ele corre o mesmo risco de contaminação que o benchmark da indústria correu. Vale tratar esse conjunto como um ativo a proteger, não só a construir.

Na prática

Pare de avaliar um agente pela sensação acumulada de “ele geralmente acerta”. Sensação acumulada é exatamente o tipo de evidência fraca que o protocolo vermelho-então-verde existe para substituir por prova reproduzível. A régua não devia ser diferente aqui.

Construa seu próprio conjunto pequeno de casos verificados, específico do seu projeto, e mantenha-o fora de circulação pública. Não precisa ser grande. Precisa ser real, com o resultado esperado já conhecido de forma independente, e protegido de vazar para o próximo modelo treinado por qualquer fornecedor.

Meça a taxa de sucesso real periodicamente, não só quando algo dá visivelmente errado. Se a primeira vez que você mede desempenho é depois de um incidente, você não está medindo, está reagindo, e reagir sempre chega tarde demais para prevenir o próximo caso parecido.

Desconfie de qualquer benchmark, inclusive o seu, que nunca foi auditado quanto à possibilidade de estar medindo a coisa errada. O SWE-bench Verified foi o padrão-ouro da indústria até alguém perguntar, de propósito, se ele ainda media o que dizia medir. Nenhum instrumento de prova é permanente só porque já provou algo uma vez.

Conclusão

A pergunta que abriu este texto continua sendo desconfortável de responder para a maioria de quem usa IA no dia a dia:

você sabe, de verdade, com que frequência seu agente resolve o que promete resolver?

A própria indústria que construiu o benchmark mais citado para essa pergunta teve que admitir, publicamente, que o instrumento parou de responder o que dizia responder. Só descobriu isso porque alguém decidiu auditar a régua, não só o que a régua media.

Você não precisa da escala do SWE-bench para aplicar o mesmo princípio no seu próprio projeto. Precisa da mesma disciplina que já uso para qualquer correção de bug: nada conta como resolvido até existir prova, não impressão. Essa prova, uma vez construída, também precisa ser reauditada de tempos em tempos, porque nenhuma prova permanece válida para sempre.

No próximo artigo desta série, volto aos ADRs, mas na forma que eles assumem quando não há tempo de registrá-los em tempo real: consolidados em lote, com uma regra específica para o tipo de decisão que mais precisa ficar visível.

Tenham um excelente dia!

Eu sou Fernando Cerqueira e entrego estratégias digitais para os desafios do presente, com propostas de inovação para um futuro sustentável. Como arquiteto sênior, aproveito meus mais de 30 anos de experiência em arquitetura e desenvolvimento de software para projetar e implementar soluções baseadas em nuvem que ajudam os clientes a transformar seus negócios com tecnologia.

Este texto foi escrito com apoio do Claude Code, a partir da minha experiência, minhas decisões e revisão: o próprio processo que a série descreve.

Nesta série

1. Metodologia de Desenvolvimento Assistido por IA Centrada na Decisão Humana
2. Disciplina em rajada: por que o rigor não nasce junto com o código
3. O código duplicado que a IA cria enquanto parece produtiva
4. As três práticas que nunca esperam gatilho
5. Quem autorizou essa atualização de dependência? Pode ter sido sua IA
6. Os quatro eventos de risco e a auditoria multi-frente
7. Seu agente de IA resolve a issue de verdade, ou só parece resolver? (este artigo)
8. ADRs em lote, e a regra da visibilidade
9. IA no time não reduz o bus factor do seu projeto — pode aumentar
10. Calibrando a intensidade ao risco real
11. O alinhamento entre produto e engenharia começa onde a decisão fica registrada
12. Segurança psicológica também vale para o time formado por você e sua IA
13. Releitura: o papel do humano, os sinais que funcionam, e onde a metodologia ainda é fraca

Referências citadas

• Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, Karthik Narasimhan, “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” (ICLR, 2024): https://arxiv.org/abs/2310.06770
• OpenAI, “Why SWE-bench Verified no longer measures frontier coding capabilities” (fevereiro de 2026), via reportagem da Decrypt, “OpenAI Says Benchmark Used to Measure AI Coding Skill Is ‘Contaminated'”: https://decrypt.co/359012/openai-benchmark-measure-ai-coding-supremacy-contaminated
• Scale AI, SWE-bench Pro: https://scale.com/research/swe-bench-pro — benchmark de bases de código privadas, resistente a contaminação por construção.