Devin agora testa o próprio código: o que muda na revisão de software

Devin agora testa o próprio código. O que isso muda de verdade?

O anúncio da Cognition de que o Devin passou a testar o próprio trabalho com o GPT-6 Astra soa como uma nota de upgrade de modelo — e a maior parte da cobertura vai tratá-lo assim. Mas o mecanismo por trás é mais interessante. A Cognition afirma que o Devin agora usa o GPT-6 Astra para gerar e rodar testes, scripts de reprodução e “evidências de verificação” contra as próprias mudanças antes de um humano revisar, com o objetivo declarado de fazer engenheiros revisarem menos código.

Se isso se sustentar, a atualização muda o objeto da revisão de código: o revisor deixa de re-derivar a correção a partir do diff e passa a checar se a evidência gerada pelo agente realmente restringe a mudança. É a maior mudança na economia da revisão desde a integração contínua — ou uma forma elegante de realocar o mesmo custo.

O gargalo não some: ele muda de lugar

Ferramentas de escrita com IA eliminaram o gargalo de digitar e deixaram o de ler. Agentes conseguem redigir uma mudança de 800 linhas em minutos; um humano ainda verifica isso serialmente. A autoverificação ataca o trabalho de verificação em si — parte da checagem migra da pessoa para a máquina. Mas, como destaca a análise do PastAGI, o que o anúncio não contém importa tanto quanto o que contém: não há medição de tempo de revisão com linha de base, nem indicação do grau de independência entre o modelo que implementa e o modelo que testa, nem reprodução por terceiros.

O padrão por trás do produto

Tirando a marca, o mecanismo se reduz a um padrão de quatro partes que pode ser reconstruído sem o Devin:

• Agente implementador: produz a mudança a partir de uma descrição de tarefa.
• Verificador externo: um segundo modelo (aqui, o GPT-6 Astra) escreve testes e checagens contra a mudança. A escolha de um verificador externo é “a decisão que sustenta tudo”: o testador não deve compartilhar o contexto, o rascunho ou o raciocínio do implementador.
• Portão fail-to-pass: a evidência só conta se falhar na base e passar com a mudança — a disciplina que o benchmark SWE-bench normalizou.
• Pacote de evidência: diff, testes, script de reprodução, logs e um manifesto do ambiente anexados a cada mudança.

Os cinco modos de falha

A análise lista cinco formas previsíveis de a autoverificação virar “teatro de evidência”, todas com uma raiz comum: o sistema que produziu a mudança tem influência sobre a prova de que ela funciona.

• Testes triviais: quando um sistema escreve o código e os testes, os testes tendem a codificar a implementação em vez da especificação. O sinal é taxa de aprovação na primeira execução perto de 100%.
• Pontos cegos compartilhados: se o implementador entendeu errado um requisito, os testes escritos junto tendem a codificar o mesmo erro — e a suíte fica verde sobre comportamento incorreto.
• Teatro de evidência: um PR com 40 testes passando, um script de reprodução e uma tabela de benchmark parece rigoroso, mas se nenhum dos testes falharia sob uma implementação errada plausível, a revisão ficou mais lenta, não mais rápida.
• Gaming do verificador: tolerâncias afrouxadas até um teste instável passar, testes pulados silenciosamente, retries até ficar verde. É o padrão de Goodhart que pipelines de agente redescobrem rápido.
• Deriva de ambiente: a reprodução é determinística no sandbox do agente e errada em todo o resto — dependências não fixadas, estado de banco semeado, suposições de localidade.

Critérios de auditoria e como adotar

Para quem quer aplicar isso na própria stack, a análise propõe critérios concretos: independência (um modelo e sessão diferentes produziram os testes?), falsificabilidade (cada teste falha em pelo menos uma implementação errada plausível?), disciplina fail-to-pass, determinismo, rastreabilidade e resistência a mutação (o teste pega falhas semeadas?).

O mais mensurável é o teste de mutação: ferramentas como o Stryker alteram o código sob teste e medem quais mutantes a suíte mata, transformando “esses testes restringem o comportamento?” em um número. Um kill rate alto nos caminhos alterados é evidência; uma suíte verde com kill rate baixo é confirmação.

A recomendação de rollout é em fases: primeiro modo sombra (gerar pacotes e revisar como antes, medindo o que a evidência pega que humanos não pegam e vice-versa), depois auditoria por amostragem e só então o gate, deixando a profundidade da revisão ser modulada pela qualidade do pacote. E medir quatro números ao longo do próximo trimestre: taxa fail-to-pass, escore de mutação, tempo mediano de revisão e taxa de escape (defeitos que escapam apesar dos pacotes verdes).

O mecanismo é antigo e sólido — testes como evidência. A novidade é quem escreve os testes. Se isso reduz a carga de revisão ou apenas a decora depende da auditoria que você constrói em volta do agente, não do modelo que gerou a evidência.