Devin Review 2.0 reduz em 82% o custo da revisão de código: PR agora sai por $0,25–0,75

Imagine um desenvolvedor que, com a ajuda de um agente, montou uma dezena de pull requests (PR, o conjunto de alterações que espera revisão antes de entrar no código principal) em um dia, enquanto o revisor humano consegue ler com atenção dois ou três. Os demais ficam parados na fila ou passam por uma leitura "na diagonal". Os criadores do Devin acreditam que a primeira linha de revisão deve ficar com outro agente e lançaram o Devin Review 2.

0. O principal argumento da versão é o preço: desde agosto, a revisão de um PR ficou 82% mais barata (cerca de cinco vezes) e agora custa $0,25–0,75. Por esse valor, dá para rodar o bot em todo PR, como os testes automatizados no CI, em vez de escolher manualmente os "importantes".

Quanto custa e o que se ganha

Segundo a empresa, a economia vem de duas frentes: uma combinação de modelos mais bem ajustada para cada etapa da revisão e a otimização da estrutura que os envolve (harness). A qualidade não caiu: a média de bugs encontrados subiu de 1,22 para 1,32 por PR.

Há mais alguns números do blog. O tempo mediano de revisão caiu de 139 para 94 segundos, cerca de 1,5 vez mais rápido. Aproximadamente 80% dos PRs custam menos de um dólar, somando todos os pushes na branch. E o preço médio de um bug de fato corrigido, entre os clientes, é de cerca de $2,25. Isso não substitui uma pessoa, mas a comparação com uma hora de trabalho de um engenheiro favorece o bot.

Como não pagar duas vezes pela mesma coisa

A principal mudança técnica é a revisão incremental. Se alguém adiciona mais um commit ao PR, o Devin Review analisa apenas as partes alteradas, não o PR inteiro de novo. O recurso vem ativado por padrão. Há duas vantagens: a conta diminui, porque cada push é menor que o PR todo, e há menos ruído, porque os novos comentários se referem às alterações recentes, sem repetir os antigos.

A revisão pode ser disparada de várias formas:

• com o comentário /devin review no GitHub ou no GitLab;
• pela página do Devin Review no Devin Cloud ou no Devin Desktop;
• automaticamente, quando o PR fica pronto para revisão, ou a cada push.

O disparo automático é configurado por regras: é possível incluir rascunhos e filtrar por caminhos de arquivos, branches e labels. Os clientes usam isso para não gastar dinheiro com PRs de pouco valor. Também existe um limite de gasto por PR, então um PR que não para de crescer não infla a conta. Além disso, o bot monta um "tour" pelo PR: explica de forma resumida o que mudou e onde olhar, o que facilita a entrada da pessoa no contexto. O tour também pode ser atualizado a cada push.

Integração com o Devin e ajuste fino

O Devin Review consegue revisar PRs de qualquer origem, mas, segundo os criadores, funciona melhor em conjunto com o próprio Devin. Nessa combinação, o agente analisa cada comentário e decide: corrigir, rejeitar ou passar para uma pessoa. Quando o desenvolvedor volta à sessão, restam apenas os bugs reais e as decisões controversas.

Chegaram dois modos novos. O primeiro são os níveis de esforço. Por padrão, a revisão vem configurada para economizar, mas em código de cobrança ou de segurança um bug que passa despercebido custa muito mais que a revisão.

Para esses casos existe o Devin Review Ultra: uma revisão mais rigorosa e mais cara. O segundo são os Custom Reviewers, ainda em beta. São revisores próprios, com as suas instruções.

Dentro da empresa, eles são usados para checar práticas de segurança de backend, migrações seguras de banco de dados, consultas SQL de bom desempenho e componentes de UI acessíveis. Cada revisor pode ter suas próprias regras de disparo, seus achados entram no relatório geral e na correção automática do Devin, e os gastos ficam sujeitos aos mesmos limites.

O que fazer com isso

A conclusão prática: se a revisão custa menos de um dólar, compensa ativá-la em todos os PRs em vez de escolher manualmente. Uma boa ordem é começar com o disparo automático em PRs prontos, cortar o que é irrelevante com filtros por caminho e label e reservar o Ultra para pagamentos e autorização. Vale testar os Custom Reviewers nos comentários que a sua equipe repete na revisão o tempo todo.

Há ressalvas. Todos os números vêm do blog da própria empresa, e o "1,32 bug por PR" é uma média entre clientes, sem comparação com ferramentas independentes. A métrica de "bugs encontrados" não diz quantos deles são realmente importantes. Por isso, no seu repositório, convém observar por algumas semanas a proporção de comentários úteis e a conta real antes de tornar o bot uma etapa obrigatória do CI.