A Garage Eight eliminou aprovações externas em 69 MRs de um serviço interno com revisão por IA

A equipe acelerou a escrita de código com a ajuda de IA e depois esbarrou na revisão: o número de revisores não aumentou. Na Garage Eight, uma funcionalidade Android composta por 35 merge requests podia esperar uma semana por duas aprovações em cada um. A pergunta prática é simples: que alterações podem passar após a verificação pelo bot, para que as pessoas tenham tempo de analisar os erros realmente caros?

Segundo Anna Sabotovich, que lidera a implantação do revisor de IA, em outubro foram feitos merge de 69 MRs sem a aprovação de outra pessoa no serviço interno de analytics de desenvolvimento. No repositório do próprio revisor, apenas 6 dos 35 MRs tinham aprovação externa. É um caso útil para equipes com fila crescente de alterações, mas não é uma permissão universal para eliminar revisores.

O número de revisores depende do custo do erro

A Garage Eight divide os serviços em quatro níveis de risco. Para a revisão, importa o que acontece se o serviço produzir um resultado incorreto. A classificação é feita pelos arquitetos de domínio com base no pior cenário; um serviço sem classificação é considerado o mais arriscado.

Por exemplo, um erro em um experimento interno pode afetar apenas seus autores. Um erro no cálculo de um pagamento já envolve o dinheiro do cliente. Exigir o mesmo número de aprovações para essas alterações é conveniente do ponto de vista administrativo, mas a atenção da equipe é gasta sem considerar as consequências.

A empresa começou pelos repositórios internos, onde as consequências de um erro são mais fáceis de detectar e reverter. No esquema-alvo, para os dois níveis de risco mais baixos, o autor poderá fazer merge sozinho após a revisão por IA e verificações automáticas bem-sucedidas. Para funções secundárias voltadas ao cliente, planeja-se manter uma pessoa em MRs simples e comuns e duas nos complexos. A complexidade é definida por uma etapa separada do revisor: essa avaliação não é confiada ao autor.

No nível mais alto, onde há dinheiro e exigências do regulador, continuam duas pessoas. Até que exista o retorno automático da aprovação humana obrigatória, a empresa mantém pessoas nos dois níveis de risco superiores.

Um comentário fechado não significa um bug corrigido

A primeira métrica parecia convincente: 92% dos comentários do bot eram fechados. Mas, nos repositórios móveis, o GitLab bloqueia o merge enquanto houver uma discussão aberta. Entre os comentários analisados em MRs já integrados, todos os 647 de 647 estavam fechados. A métrica, na prática, mostrava o cumprimento da condição de merge.

Por isso, a equipe passou a observar se o código próximo à linha do comentário mudava antes do merge. Depois comparou o resultado com o ruído de fundo: com que frequência um ponto aleatório do mesmo arquivo é alterado.

No terceiro trimestre, em 12 repositórios, o bot deixou 585 comentários graves. Após 219 deles, o código ao redor foi alterado — 37% contra 7% de ruído de fundo. Dos 27 casos verificados manualmente, em 25 a correção de fato se referia ao comentário. Segundo estimativa do autor do material, no trimestre foram corrigidas antes do merge cerca de 200 questões graves, incluindo 98 bugs.

É importante não tirar conclusões precipitadas. A alteração de código vizinho é um indício indireto de que o comentário foi aceito. Esses números não medem a proporção de todos os erros encontrados e não provam que o bot revisa melhor que uma pessoa. Em compensação, são muito mais úteis que o contador de threads fechados para decidir se o revisor se paga em um repositório específico.

O bot também precisa de fila, verificações e salvaguardas

A infraestrutura rapidamente passou a fazer parte da qualidade da revisão. Uma verificação em um modelo interno levou cerca de 50 minutos e atrasou os demais MRs. Em setembro, o revisor ficou em silêncio por sete dias e, em outubro, por mais 30 horas: nas duas vezes o orçamento da API acabou. Depois disso, surgiram alertas para silêncio, verificações travadas e saldo.

Para testar a troca de modelos, a equipe montou 42 MRs históricos; em 32, uma pessoa confirmou problemas reais. Esse conjunto ajuda a comparar versões do revisor, mas não basta para conclusões amplas sobre confiabilidade.

Há também o problema das discussões infinitas: em um MR, o bot verificou 27 commits e deixou 45 achados, e 44 foram respondidos pelo agente do autor. A equipe considera necessários um limite de ciclos e a verificação apenas do diff novo.

Conclusão prática: vale começar por um repositório com custo de erro claro e fila mensurável para as pessoas. Depois, verificar quais comentários levam a correções úteis, quanto ruído o bot gera e o que acontece quando ele falha. O retorno automático do humano quando os rollbacks aumentam ainda está nos planos da Garage Eight. É justamente esse ponto em aberto que limita a retirada de mais aprovações.