Como manter uma software factory estável com 1.000 PRs por semana

A equipe do Kiro Crew parte de uma pergunta diferente da que mais recebeu após o post anterior, em que contou como três engenheiros e um grupo de agentes integraram 1.000 pull requests em uma semana. Em vez de "como isso não quebra tudo", ela pergunta se uma pessoa pode responder por um PR que não escreveu nem leu linha a linha. A resposta do time é que a confiança sempre veio dos testes, não da leitura do diff. Por isso, cerca de 20% do tempo vai para infraestrutura de automação, e a cobertura de testes passou de 90%, com meta de 100%.

O artigo descreve cinco estágios. A revisão manual durou menos de um dia, em março. Depois vieram o revisor automático com regra rígida (todo comentário resolvido antes do merge), a classificação por severidade com um segundo agente revisor, a migração para GitHub com CI real e revisores por papel (design, primeiros princípios, UX e modelos de famílias diferentes), e o fechamento do ciclo com a skill prepare-pr. Ela corrige falhas até um check único, o PR Readiness, ficar verde. Esse check consolida mais de 80 verificações e só passa quando todas as ações esperadas rodaram e passaram. PRs simples são aprovados e integrados automaticamente.

O tema já vinha sendo tratado no CEVIU. Em 13 de outubro de 2026, o CEVIU noticiou "Revisão de Código com IA: O Futuro da Qualidade e Segurança no Desenvolvimento de Software", e em 14 de outubro de 2026, "A IA e o Futuro da Revisão de Código: Menos Linhas, Mais Estratégia", ambas sobre a análise humana linha a linha perder espaço. Em 24 de julho de 2026, "Sobrecarga em Code Review Acende Alerta para Líderes de Engenharia" apontava avaliações menos profundas por excesso de carga. A matéria atual traz um caso prático: o time relata que revisores de IA acharam problemas mais fundos que um leitor humano e que abandonou a leitura manual.

Para quem opera um pipeline com agentes de código, a leitura editorial é que o gargalo deixa de ser escrever e passa a ser a qualidade dos sinais de CI. O relato sugere que o registro de revisão e um veredito único de prontidão valem mais que a leitura do diff. Também mostra riscos do próprio ciclo automático, como excesso de engenharia e limites de recursos do GitHub.