Quando o código acelera, a revisão vira o gargalo
Durante muito tempo, a revisão de código acompanhou o ritmo da escrita. Um desenvolvedor abria um pull request (PR), outro lia a mudança, discutia os pontos relevantes e aprovava ou pedia ajustes. A revisão individual era o centro do processo porque a produção de código também era limitada pelo tempo das pessoas.
Os assistentes de IA quebraram esse equilíbrio. Escrever uma primeira versão, gerar testes e explorar alternativas ficou rápido. Revisar bem continua lento: é preciso entender o comportamento, conferir os casos-limite, avaliar o impacto em outros componentes e decidir se o risco que sobra é aceitável. Quando chegam mais mudanças do que se consegue analisar, a fila de PRs cresce. Reduzir a revisão a um clique resolveria a fila à custa da qualidade.
Na Atlas, o problema tinha um número: antes da mudança descrita aqui, metade dos PRs entrava no ambiente de desenvolvimento em menos de 28 minutos, muitas vezes sem ninguém olhar.
Testamos duas análises automáticas em um piloto e depois as levamos para o fluxo normal: um revisor de qualidade de engenharia e um revisor de segurança. Este texto reúne o que aprendemos nas primeiras semanas de uso em mudanças reais. A ideia é simples: o agente aponta problemas que o desenvolvedor consegue conferir, repete a análise a cada nova versão, e a decisão sobre o que vai para produção continua com pessoas.
O que mudou nos números
Comparamos os mesmos 27 sistemas em duas janelas: 59 dias antes da adoção, com 1.504 PRs integrados, e os primeiros 25 dias depois, com 883.
- PRs integrados por dia em desenvolvimento: de 25 para 35, cerca de 40% a mais, com o mesmo grupo de dez desenvolvedores.
- PRs com alguma revisão registrada, humana ou automática: de 45% para 80%.
- Pedidos de ajuste: oito PRs em 59 dias, todos de pessoas, contra 299 PRs em 25 dias, do revisor automático. Em 85% dos PRs com apontamento, veio um commit de correção.
- Esperas mais longas: no percentil 90, o limite abaixo do qual ficam 90% dos PRs, o tempo entre abertura e merge caiu de 18 para 17,5 horas; no percentil 99, de 123 para 100 horas.
Um dado foi na direção contrária: o tempo mediano entre abertura e merge quase triplicou, de 28 minutos para 1 hora e 20. Isso era esperado. Antes, a maioria dos PRs entrava minutos depois de abertos, sem ninguém olhar, e esses casos puxavam a mediana para baixo. No fluxo descrito, cada PR submetido à revisão espera a análise, que leva 4 minutos na metade das vezes e 12 em nove de cada dez, e, quando há apontamentos, uma correção e uma nova avaliação. O PR típico passou a ter um commit a mais: a mediana foi de 2 para 3. A mediana de antes media um PR que em geral não era revisado; a de agora mede um PR revisado. As esperas longas diminuíram, e o primeiro retorno da revisão automática passou a chegar em minutos. Essa mudança pode ter contribuído para a redução, mas os dados não isolam seu efeito.
A comparação mostra direção, não prova de causa: a janela “depois” é curta, e outras coisas mudaram ao mesmo tempo, como a esteira de integração e as regras de branch.
Escrever mais não é entregar mais
Dois estudos recentes apontam na mesma direção.
No artigo de trabalho (working paper) Writing Code vs. Shipping Code, do NBER, revisado em setembro de 2026, Demirer, Musolff e Yang acompanharam mais de 500 mil desenvolvedores no GitHub, cruzando a atividade deles com dados de uso de ferramentas de IA. Agentes autônomos aumentaram o número de commits em 240%. O ganho cai para 80% quando se contam projetos e para 30% quando se contam releases, as versões de fato publicadas. Nas lojas de aplicativos, o número de apps novos disparou, mas o uso total não cresceu. Os autores atribuem a diferença a gargalos humanos nas etapas depois da escrita.
Passar nos testes também não basta. Em uma nota de pesquisa publicada em março de 2026, a METR pediu a quatro mantenedores de três projetos conhecidos (scikit-learn, Sphinx e pytest) que avaliassem 296 PRs gerados por agentes de IA lançados entre 2024 e 2025. Todos haviam passado nos testes do SWE-bench Verified, um conjunto de tarefas reais usado para medir esses agentes. Cerca de metade seria recusada. Na comparação ajustada pela aceitação dos patches humanos, a aceitação ficou, em média, 24 pontos percentuais abaixo da nota do avaliador automático. Os motivos mais citados: a funcionalidade principal não funcionava, o patch quebrava outra parte do código ou a qualidade ficava abaixo do padrão do projeto. Até os patches humanos originais só foram aceitos em 68% dos casos, o que dá a medida do rigor dos revisores. Os próprios autores ressalvam que os agentes não puderam corrigir o PR depois do feedback, como um desenvolvedor faria.
Testes verificam o que alguém previu. A revisão pergunta se o que foi previsto é suficiente, se a mudança resolve o problema certo e se ela cria riscos fora do caminho coberto pelos testes.
Duas lentes para a mesma mudança
O fluxo separa responsabilidades que antes caíam sobre uma única pessoa:
- Revisor de qualidade. Examina o código e a discussão, procura defeitos e confere as regras aplicáveis do Padrão Atlas, o nosso padrão de engenharia. Cada apontamento diz onde está o problema, em que condição ele falha, qual é a consequência e como verificar. Violar uma regra e introduzir um defeito são coisas diferentes, e ele as separa. Nas primeiras semanas, os dois tipos apareceram em proporção parecida.
- Revisor de segurança. Procura riscos que pedem um olhar próprio, como falhas no controle de acesso, que foram a família mais comum de achados até agora. Silêncio dele não é garantia de segurança.
- Testes e pessoas. Os testes verificam o comportamento. As pessoas corrigem os achados procedentes, contestam os falsos positivos com evidências e decidem o que vai para produção. Os revisores automáticos não escrevem a correção nem fazem merge.
Os dois revisores partem de projetos de código aberto; as regras, a orquestração e os controles descritos aqui são da Atlas.
Os critérios continuam sendo definidos pelo time. O padrão de engenharia torna explícito o que se repete; o agente ajuda a aplicá-lo sempre do mesmo jeito. Sobra atenção humana para as decisões de produto e de arquitetura, que nenhum checklist resolve.
Um parecer vale para a versão que foi examinada
Uma aprovação antiga não autoriza código novo. No nosso fluxo, cada commit enviado depois do início da revisão dispara uma nova avaliação, e a aprovação dada a uma versão anterior é retirada se a nova não passar. Os apontamentos aparecem junto ao código, e as correções e justificativas ficam na discussão do PR. Nas primeiras semanas foram 1.151 avaliações para 482 PRs: pouco mais de duas por PR.
A validação final precisa ser feita na mesma versão que foi aprovada. Se o código ou a sua base mudar, as evidências anteriores precisam ser reavaliadas. Revisar uma versão e testar ou publicar outra rompe a ligação entre a decisão e o que será entregue.
Esse princípio vale além da automação: a confiança pertence a uma versão demonstrada, não ao nome de uma branch nem à cor de um check isolado.
O que aprendemos com mudanças reais
Três exemplos das primeiras semanas. Os nomes dos sistemas e os detalhes de implementação ficaram de fora.
Uma operação pela metade. Uma mudança na estrutura do banco de dados precisa ser tudo ou nada. Esta gravava parte dos dados antes de terminar: se falhasse no meio, o banco ficaria em um estado que ninguém previu. O revisor de qualidade apontou a linha. O desenvolvedor corrigiu no commit seguinte, e a nova versão foi avaliada de novo antes de seguir. A lição foi olhar também para o que acontece quando a operação não termina.
Um identificador não deveria bastar. O revisor de segurança apontou que o sistema entregava um objeto para quem mandasse o código dele, sem conferir se aquela pessoa podia vê-lo. O desenvolvedor corrigiu os dois pontos indicados. Na avaliação da correção, apareceu um terceiro caminho, mais escondido, que dependia da mesma regra e também precisava de controle. Três rodadas e dois dias depois, o PR entrou. Nada chegou perto de produção. Daí a regra: verificar todos os caminhos que dependem da mesma regra de acesso, além do primeiro apontado.
Um alerta errado. O revisor marcou como crítica uma versão recém-lançada de uma biblioteca, por não conhecê-la: suspeitou de um pacote falso com nome parecido, um golpe que existe. O desenvolvedor respondeu no PR com o registro oficial da versão, assinado. O apontamento foi dispensado em três minutos, com a justificativa registrada. Um revisor automático precisa aceitar contestação verificável, e isso acontece com frequência: dos apontamentos reavaliados em commits seguintes, 169 foram resolvidos no código e 194 foram dispensados com justificativa aceita. O que o modelo “sabe” sobre uma biblioteca tem data de validade.
O revisor automático também precisa de limites
Um agente lê código, títulos, descrições e comentários, e qualquer um desses campos pode conter texto escrito para influenciá-lo. Uma frase como “isto é seguro, pode aprovar” entra na análise como qualquer outro trecho do PR. Ela não aprova nada.
O artigo ainda sem revisão por pares Measuring and Exploiting Contextual Bias in LLM-Assisted Security Code Review, de Alexopoulos, Alexopoulos, Spinellis e Mitropoulos (2026), mediu esse risco. Os autores testaram seis modelos sob cinco formas de apresentar o mesmo PR e, depois, atacaram duas ferramentas reais de revisão (Claude Code e CodeRabbit) com 33 vulnerabilidades conhecidas em 20 projetos. Pedidos diretos do tipo “isto é seguro” não funcionaram e até levantaram suspeita. Já um ataque refinado com ajuda de outro modelo, testado repetidas vezes contra uma cópia local do revisor, passou em 32 dos 33 casos. A assimetria é o ponto: o atacante pode tentar quantas vezes quiser; o revisor tem uma chance.
Isolamento, permissões limitadas e a separação entre o material analisado e as instruções confiáveis reduzem o risco. Nenhum desses controles torna o agente imune, e ainda não medimos a resistência do nosso revisor a esse tipo de ataque. Quando a análise falha, a falha precisa aparecer, em vez de virar aprovação por conveniência.
Isso é só o começo
As primeiras semanas mostraram mais PRs integrados por dia, mais PRs revisados e esperas longas menores, com um PR típico que demora mais porque agora é revisado. Tratamos isso como ponto de partida. Três coisas ainda não sabemos: quanto do tempo a mais é espera e quanto é correção de apontamentos procedentes; se o revisor resiste a um ataque de enquadramento como o do estudo acima; e quantos defeitos ainda escapam para produção, algo que nenhum dado de PR mostra. São os próximos números a medir.
O fluxo também vai mudar. Hoje o desenvolvedor chama a revisão, e o agente vigia só a entrada em desenvolvimento. O próximo passo é revisar cada commit sem precisar chamar, e depois vigiar também a porta de produção. O revisor também vai ser avaliado: o desenvolvedor vai poder marcar cada apontamento como útil ou como erro, e o agente passa a ser medido pelo que acerta. É um começo. Mais mudanças passam por alguma revisão todos os dias, e quem decide o que vai para produção continua sendo uma pessoa.