A Mainlane é um engenheiro e uma equipe de agentes de IA. Isso levanta uma pergunta justa: quem verifica o código que uma IA escreveu? Nossa resposta é outra IA — uma que não o escreveu — seguida por uma pessoa que decide se ele vai para produção.
O ciclo
- Uma sessão do Claude pega uma tarefa e abre um pull request.
- Um revisor separado começa em uma sessão limpa. Ele nunca viu como o código foi escrito, então lê o diff como um colega leria — sem as suposições do autor.
- O revisor deixa apontamentos em três níveis: 🔴 precisa corrigir, 🟡 deveria corrigir, 🟢 seria bom ter.
- A sessão autora corrige e responde ponto por ponto, terminando com uma seção “Verificação”: os comandos que executou e o que eles imprimiram.
- O revisor confere o novo head. O ciclo se repete até não restar nenhum apontamento — nem mesmo 🟢.
Duas regras mantêm o processo honesto. Um apontamento só pode ser contestado com uma medição — um número, a saída de um comando, um mutante que um teste não consegue pegar —, e não com “está tudo bem”. E, depois de cinco rodadas, o ciclo para e chama uma pessoa, para nunca girar sem fim.
A parte humana
Nenhum agente faz merge. Quando a revisão está limpa e o CI está verde exatamente no commit que o revisor viu, a sessão escreve “pronto para merge” e espera. O merge só acontece depois que uma pessoa autoriza, e apenas para esse mesmo commit.
O que ele pega
Alguns exemplos reais do repositório deste site:
- No pull request que adicionou verificações do Lighthouse ao CI, o revisor notou que uma configuração de build do CSS apontava para a pasta errada, e os estilos de layout sumiam do site sem alarde. Nem o Lighthouse nem o verificador de acessibilidade perceberam. Ele também pegou um banner fixo de idioma que podia cobrir o elemento em foco para quem navega pelo teclado.
- Na verificação de restauração do backup do banco de dados, o teste diário comparava os dados restaurados com eles mesmos, e não com a exportação — nunca teria notado linhas faltando. A mesma revisão encontrou uma mensagem de erro que podia gravar o e-mail de um lead nos logs.
- Na implantação da Content Security Policy, relatórios de extensões do navegador teriam impedido que a meta de “uma semana sem violações” fosse atingida, e imagens externas nos posts do blog teriam quebrado assim que a política entrasse em vigor.
Nada disso era exótico. Era o tipo de coisa que uma pessoa cansada deixa passar numa sexta-feira à noite.
Em números
No fim de outubro de 2026, o ciclo roda em oito repositórios, com 385 pull requests mesclados e 1.069 revisões. A maior parte do custo é o próprio trabalho: na última semana de outubro, cerca de três quartos dos tokens vão para a implementação e menos de um décimo para a revisão.
Limites
O revisor é o mesmo tipo de modelo que o autor, então pode ter os mesmos pontos cegos. Ele não substitui a revisão humana de mudanças importantes, e o texto dentro de um pull request é tratado como dado, nunca como instrução. O que ele substitui é a etapa que a maioria dos desenvolvedores solo pula: um segundo par de olhos em cada mudança.
Se você quer o mesmo processo na sua equipe, esse é um dos nossos serviços — fale com a gente.