Durante muito tempo, a pergunta mais comum sobre agentes de programação foi simples: eles conseguem corrigir o bug? Em benchmarks de engenharia de software, essa pergunta costuma virar outra, ainda mais objetiva: o patch gerado passa nos testes? Se a resposta for sim, ponto para o agente. Se for não, falha. O problema é que qualquer pessoa que já trabalhou em um repositório real sabe que desenvolvimento de software não termina no verde do teste automatizado.
Um novo paper, SWE-Gate: Passing Functional Tests Is Not Enough for Software Engineering Agents, ataca exatamente esse ponto. Os autores propõem um benchmark para avaliar agentes de programação não apenas pela correção funcional, mas também pela capacidade de obedecer restrições vindas de revisão de código. Em outras palavras: a IA não precisa apenas fazer o programa funcionar. Ela precisa fazer do jeito aceitável para aquele projeto.
Essa diferença parece pequena, mas muda bastante a conversa. Um patch pode passar todos os testes e ainda ser rejeitado por quebrar uma convenção arquitetural, ignorar uma exigência de segurança, duplicar lógica indevidamente, alterar uma API pública sem necessidade, esconder um problema em vez de resolvê-lo ou produzir uma solução difícil de manter. Em empresas, isso não é detalhe estético. É custo futuro.
O limite escondido dos benchmarks atuais
Benchmarks como SWE-bench ajudaram a transformar agentes de programação em algo mensurável. Em vez de perguntar genericamente se um modelo “sabe programar”, eles colocam a IA diante de issues reais, em repositórios reais, e verificam se a mudança gerada resolve o problema. Isso foi um avanço enorme, porque tirou a avaliação do campo da demonstração bonita e levou para um terreno mais próximo do trabalho cotidiano.
Mas existe uma simplificação importante nesse tipo de avaliação: a aceitação do patch é frequentemente reduzida ao resultado dos testes funcionais. Se os testes passam, o patch é considerado correto. Só que o processo real de desenvolvimento tem uma segunda porta de entrada: a revisão. Um pull request precisa resolver a issue, mas também precisa respeitar aquilo que mantenedores, líderes técnicos e revisores enxergam como qualidade aceitável.
É aí que entra o SWE-Gate. O nome é bem escolhido: ele sugere que existe um portão depois dos testes. A pergunta deixa de ser apenas “isso funciona?” e passa a incluir “isso deveria entrar no repositório?”. Essa segunda pergunta é mais difícil, porque envolve contexto, preferências de projeto, legibilidade, estilo, compatibilidade, limites de escopo e expectativas que nem sempre estão codificadas em testes automatizados.
O ponto central do paper é que agentes de software podem parecer mais prontos do que realmente são quando o instrumento de avaliação ignora essas restrições. O resultado funcional é necessário, mas insuficiente. Um agente que conserta o bug quebrando uma regra importante do projeto está mais perto de um estagiário apressado do que de um engenheiro confiável.
O que o SWE-Gate mede de diferente
O SWE-Gate foi construído para separar duas coisas que normalmente aparecem misturadas: resolver a tarefa e cumprir restrições de revisão. Para isso, o benchmark usa comentários reais de revisão em pull requests como fonte de restrições. A partir desses comentários, os autores sintetizam instâncias em nível de repositório nas quais é possível testar se um patch atende ao problema funcional e, separadamente, se respeita a condição apontada na revisão.
Essa separação é importante porque permite enxergar falhas que um placar único esconderia. Um agente pode passar nos testes funcionais e falhar nos testes de restrição. Pode também cumprir a restrição e ainda não resolver a issue. Ou pode conseguir as duas coisas. Essa decomposição aproxima a avaliação daquilo que acontece em times reais: uma mudança precisa ser correta e aceitável.
Imagine um bug de validação em uma função que processa entradas de usuário. Um patch pode resolver o caso testado adicionando uma condição diretamente no meio de uma função já inchada. O teste passa. Mas o revisor talvez tenha pedido que a validação fosse centralizada em um helper já existente, para evitar divergência entre caminhos do sistema. Se o agente ignora isso, ele resolveu o sintoma, mas não respeitou a estrutura do projeto.
Outro exemplo: uma correção pode trocar uma chamada interna por uma dependência nova. Funciona no teste, mas viola uma política do repositório sobre dependências externas. Ou altera uma mensagem de erro pública de um jeito que passa nos testes atuais, mas quebra usuários que dependem daquele contrato. Esses são casos em que qualidade de software aparece como restrição contextual, não como assert simples.
O SWE-Gate tenta trazer esse mundo para dentro da avaliação. Não é só um benchmark de “código que roda”. É um benchmark de “código que sobreviveria a uma revisão”.
Por que isso importa para agentes autônomos
A discussão fica ainda mais relevante porque agentes de programação estão deixando de ser ferramentas passivas de autocomplete. Eles já abrem arquivos, rodam testes, editam múltiplos módulos, investigam logs e propõem patches completos. Quanto mais autonomia eles ganham, maior o risco de uma métrica simplificada incentivar o comportamento errado.
Se um agente é treinado, ajustado ou ranqueado principalmente por passar testes, ele aprende a otimizar esse sinal. Isso pode gerar soluções estreitas: mudanças mínimas para satisfazer o caso visível, remendos que mascaram sintomas, adaptações frágeis ao conjunto de testes e pouca consideração por manutenção. Em humanos, chamamos isso de “programar para o teste”. Em agentes, pode virar uma estratégia sistemática.
O paper não precisa afirmar que agentes são mal-intencionados para apontar o problema. Basta reconhecer que modelos otimizam o que medimos. Se medimos apenas funcionalidade imediata, deixamos de recompensar boa engenharia. E se depois colocamos esses agentes em fluxos reais, a conta chega na revisão humana, na dívida técnica e na confiança do time.
Essa é uma virada importante na maturidade da área. O próximo salto dos agentes de programação talvez não venha apenas de modelos que escrevem mais código, ou resolvem mais issues, mas de agentes que entendem melhor o contrato social de um repositório. Eles precisam perceber que uma base de código tem história, donos, padrões, restrições e cicatrizes. O teste automatizado captura uma parte disso. A revisão captura outra.
Impacto para empresas brasileiras e para o ecossistema
No Brasil, muitas empresas estão entrando na fase prática da adoção de IA em desenvolvimento. A pergunta deixou de ser “dá para usar?” e virou “onde isso economiza tempo sem aumentar risco?”. Agentes de programação prometem acelerar correções, migrações, testes, documentação e manutenção. Mas a experiência de times reais costuma revelar um padrão: a IA ajuda muito, desde que alguém experiente revise o resultado.
O SWE-Gate dá uma linguagem mais precisa para esse incômodo. Não basta medir quantos tickets um agente fecha. É preciso medir quantos patches seriam aceitos sem retrabalho pesado. Para uma empresa, essa diferença é financeira. Um agente que produz cinco correções por hora, mas exige revisão intensa e refatoração manual, talvez não seja tão barato quanto parece. Já um agente mais conservador, que respeita padrões e reduz desgaste na revisão, pode gerar mais valor líquido.
Isso também afeta como empresas devem comprar ou avaliar ferramentas de IA para desenvolvimento. Demos costumam mostrar o agente resolvendo um bug isolado. O teste passa, a tela fica verde, todos respiram aliviados. Mas uma avaliação séria deveria incluir perguntas mais chatas: o patch seguiu as convenções internas? Tocou arquivos demais? Criou uma abstração desnecessária? Ignorou uma orientação do revisor? Manteve compatibilidade? Explicou bem a mudança?
Para startups brasileiras, o tema é especialmente sensível. Times pequenos têm pouca margem para acumular dívida técnica invisível. Uma IA que acelera hoje e complica o produto em três meses pode sair cara. Ao mesmo tempo, quem aprender a usar agentes com critérios de revisão claros pode ganhar velocidade real. O segredo não é abandonar agentes, mas colocá-los dentro de um funil de qualidade mais parecido com o processo humano.
Há também uma oportunidade para o ecossistema local. Empresas de consultoria, software houses e times internos podem transformar seus próprios padrões de revisão em conjuntos de avaliação. Em vez de depender apenas de benchmarks públicos, podem criar “SWE-Gates” internos: testes que verificam não só funcionamento, mas aderência a arquitetura, segurança, observabilidade, estilo e regras de negócio. Isso torna a IA menos genérica e mais alinhada ao modo como aquela organização constrói software.
O papel do revisor humano muda, não desaparece
Uma leitura apressada poderia concluir que o paper é uma crítica aos agentes de programação. Na verdade, ele é mais útil como crítica ao modo preguiçoso de medi-los. O problema não é a IA escrever código. O problema é fingir que passar nos testes equivale a estar pronto para produção.
Revisores humanos continuarão importantes, mas o trabalho deles pode mudar. Em vez de revisar cada linha gerada por IA como se estivesse começando do zero, eles podem definir restrições melhores, transformar padrões recorrentes em verificações automatizadas e ensinar o agente por meio de feedback mais estruturado. A revisão deixa de ser apenas inspeção e vira também desenho do ambiente em que a IA opera.
Isso exige disciplina. Comentários de revisão não podem ser apenas preferências soltas. Quando uma regra importa, ela precisa ser explicitada, documentada e, quando possível, testada. O SWE-Gate aponta para um futuro em que parte da cultura de engenharia de um time vira dado avaliável. Não no sentido burocrático de transformar tudo em checklist, mas no sentido prático de reduzir ambiguidades para humanos e máquinas.
Também há uma lição para desenvolvedores individuais. Usar IA bem não é aceitar o primeiro patch que compila. É pedir mudanças com contexto, exigir alternativas, rodar testes, comparar escopo, revisar diffs e observar se o modelo entendeu a arquitetura. A produtividade não vem de desligar o julgamento. Vem de aplicar julgamento no lugar certo.
O verde do teste é só o começo
O SWE-Gate chega em um momento oportuno porque a indústria está tentando decidir quanta confiança deve colocar em agentes de programação. A resposta honesta é: mais do que ontem, menos do que o marketing promete. Eles já são úteis. Mas utilidade não é o mesmo que autonomia irrestrita.
A grande contribuição do paper é lembrar que engenharia de software é uma prática social e técnica ao mesmo tempo. O código precisa executar, mas também precisa caber em um projeto, conversar com decisões anteriores e não transferir custo escondido para o futuro. Testes automatizados são uma das melhores invenções da área, mas nunca foram a definição completa de qualidade.
Se agentes de IA vão participar seriamente do desenvolvimento de software, os portões de avaliação precisam ficar mais parecidos com os portões reais. Funcionar é obrigatório. Ser revisável, sustentável e coerente com o repositório também. O futuro dos agentes de programação não será decidido apenas por quem passa mais testes. Será decidido por quem consegue entregar mudanças que engenheiros humanos aceitam sem sentir que estão limpando a casa depois.