TL;DR
Em uma organização de engenharia nativa de IA, gerar código deixou de ser a etapa mais lenta do processo de entrega de software. Revisão, verificação, correção e tomada de decisão humana se tornam os gargalos e, em última análise, definem o quanto a organização consegue acelerar. Ferramentas de codificação com IA independentes podem até entregar uma aceleração de 30–40%, mas alcançar uma mudança de patamar na produtividade exige otimizar tudo o que acontece depois que o código é escrito.
No nosso artigo anterior sobre como resolver a revisão de código com o Cosmos, descrevemos um sistema de revisão que ajudou nossa organização de engenharia a aumentar a produção de código em 3×, reduzindo o tempo mediano até o merge e mantendo a qualidade. Desde então, expandimos esse sistema para além da revisão, cobrindo todo o ciclo do PR ao merge: agentes especializados cuidam do trabalho mecânico, verificam a corretude e tratam o feedback, enquanto os humanos fornecem julgamento e transferência de conhecimento e sempre detêm a decisão final do merge.
Isso é loop engineering: melhorar o sistema completo que transforma código gerado em uma mudança verificada, compreendida e pronta para merge, em vez de otimizar uma única ferramenta isoladamente.
Por que uma "ferramenta de revisão de código com IA" não basta
Uma ferramenta convencional de revisão de código com IA, como CodeRabbit ou Greptile, analisa o diff e publica comentários. É útil, mas a revisão é só uma etapa. O que realmente trava é a cadeia de repasses manuais:
- Reconstruir a intenção e a arquitetura.
- Triar mudanças de baixo risco.
- Aplicar o feedback da revisão.
- Corrigir falhas de CI e conflitos de merge.
- Verificar o comportamento da funcionalidade de ponta a ponta.
- Reunir evidências suficientes para entregar com segurança.
- Revisar novamente após cada push.
Um loop do PR ao merge mantém Experts especializados atuando em revisão, correção, verificação e suporte à decisão até que um humano possa fazer o merge com confiança. Cada Expert da frota é responsável por um ou mais desses repasses, transformando uma sequência fragmentada de tarefas manuais em um sistema coordenado. O objetivo é otimizar o loop inteiro: tempo humano, custo, qualidade e latência até o merge, não o tempo até o primeiro comentário.
1. Visão geral: engenharia do loop completo
leia a descrição da imagem
ALT
Um loop de revisão de código nativo de IA: agentes encontram e corrigem bugs, verificam mudanças e avaliam políticas; humanos resolvem as decisões de julgamento e tomam a decisão final de merge.
Nosso sistema original separava a análise de risco (Risk Analyzer), a revisão de corretude linha por linha (Deep Reviewer) e a revisão de design guiada por humanos (Pair Review). O sistema expandido adiciona correção, verificação em runtime e aprovação automática ampliada, reduzindo ainda mais o gargalo humano. Para uma visão geral do Cosmos e de seus Experts configuráveis, veja nosso artigo anterior sobre como resolver a revisão de código com o Cosmos.
Experts e capacidades, não um revisor de propósito geral
Expert ou capacidade
Responsabilidade
Risk Analyzer
Classifica o risco e aplica a política de aprovação automática
Deep Reviewer
Faz uma análise exaustiva, linha por linha, em busca de defeitos objetivos de corretude
Pair Reviewer
Reconstrói a intenção, a arquitetura, o contexto do produto e os tradeoffs
Memory Manager
Lembra o feedback das sessões de PR e Pair Review para melhorar execuções futuras
Verifier
<sup>
NEW
</sup>
Testa o comportamento afetado de ponta a ponta em um ambiente de teste (
)
PR Fixer
<sup>
NEW
</sup>
Corrige os apontamentos da revisão, falhas de CI e conflitos de merge
Review Dashboard
<sup>
NEW
</sup>
Observa e resume o estado dos Experts
cosmos approve
<sup>
NEW
</sup>
Avalia uma política de aprovação configurável a pedido do autor
A distinção entre Deep Reviewer e Pair Reviewer é especialmente importante:
- O Deep Reviewer pergunta: "Existe um bug objetivo nesta implementação?" Ele roda de forma autônoma e verifica o PR contra as diretrizes de AGENTS.md ou CLAUDE.md.
- O Pair Reviewer pergunta: "Essa mudança faz sentido no contexto mais amplo do sistema, e quais decisões exigem julgamento humano?" Ele roda de forma interativa com o humano. O humano também pode instruí-lo a monitorar o PR depois de publicar os comentários de revisão e aprovar em seu nome quando esses comentários forem resolvidos.
O Expert PR Author antes acumulava duas funções: escrever o PR e corrigir comentários de revisão, falhas de CI e outros trabalhos de acompanhamento. No design desacoplado, o PR Author para na criação do rascunho do PR e o PR Fixer assume. Isso dá aos usuários mais controle sobre como as correções são executadas e suporta PRs criados sem o PR Author.
O Review Dashboard reúne o status dos Experts, commits revisados, evidências e ações disponíveis em uma única visualização.
- Projetando o humano no loop
A revisão e a verificação humanas estão se tornando os recursos escassos nas organizações de engenharia nativas de IA. O objetivo não é eliminar os humanos indiscriminadamente. É gastar a atenção humana apenas onde ela tem a maior alavancagem.
Por que os humanos permanecem no loop
Os agentes conseguem executar uma grande parcela da análise e da execução mecânica, mas não têm o contexto completo de negócio e organizacional. Os humanos continuam essenciais para:
- Decisões de julgamento: Essa lógica deve ficar no frontend ou no backend? Esse tradeoff é adequado para o produto? Esse risco é aceitável agora?
- Transferência de conhecimento: A revisão é uma das formas de os engenheiros construírem uma compreensão compartilhada da arquitetura e do comportamento do produto.
- Propriedade e responsabilidade: Os agentes não são donos do software depois que ele é entregue; os desenvolvedores humanos e as organizações de engenharia é que são. Por isso, um humano sempre toma a decisão final e clica em Merge. Nenhum desses experts faz merge de um PR.
O objetivo do design é, portanto:
Os agentes fazem o trabalho mecânico. Os humanos tomam as decisões importantes.
O fluxo de trabalho do autor e do revisor: antes e depois
Fluxo de trabalho tradicional
Fluxo de trabalho com humano no loop
Fazer a triagem manual de cada PR e identificar mudanças de baixo risco
Deixar o
Risk Analyzer
classificar o risco e aplicar a política de aprovação automática da organização
Ler o PR linha por linha
Confiar no
Deep Reviewer
para fazer a análise exaustiva linha por linha
Reconstruir o contexto, a intenção e a arquitetura a partir do diff
Usar o briefing do
Pair Reviewer
para entender a mudança e identificar decisões de julgamento
Implantar e testar a funcionalidade manualmente
Inspecionar as evidências do
Verifier:
screenshots, logs, traces e saídas capturadas
Revisar cada correção do zero
Deixar o
Pair Reviewer
monitorar se os comentários autorizados foram resolvidos
Triar o feedback, implementar correções, reparar o CI, resolver conflitos e explicar cada mudança
Deixar o
PR Fixer
—ou o
PR Author
quando ele detém o ciclo de vida completo—cuidar do acompanhamento mecânico e reportar o que mudou
Buscar nos comentários e checks o estado atual
Usar o
Review Dashboard
como ponto de entrada
Reunir manualmente evidências de revisão, propriedade e verificação antes de solicitar aprovação
Invocar o
cosmos approve
para avaliar a política de aprovação configurada contra as evidências atuais
Decidir se faz o merge
Continuar decidindo se faz o merge
A intuição econômica do uso de múltiplos experts
Vale a pena investir em tokens que reduzam de forma mensurável o tempo humano no gargalo da revisão. Quando os Experts transformam horas de revisão e condução de PRs em minutos, eles liberam o escasso julgamento de engenharia para as decisões importantes que só humanos podem tomar, além de ajudar as funcionalidades a chegarem mais rápido aos clientes.
Um dos compromissos centrais da Augment é ajudar organizações a otimizar custos. Isso significa otimizar o custo total por tarefa: esforço humano mais custo de tokens. Não significa minimizar o uso de tokens à custa de resultados bem-sucedidos. Um único Expert sobrecarregado com seis responsabilidades fará um trabalho mediano em cada uma e exigirá mais intervenção humana. Seis Experts dedicados podem se concentrar cada um em uma parte diferente da revisão de PR, produzir artefatos de revisão de maior qualidade e conduzir mais do processo de forma autônoma.
3. Custo e qualidade: otimize o custo por resultado bem-sucedido
O modelo mais barato em preço de token geralmente é uma falsa economia. Um defeito que passa, uma correção ruim ou uma nova tentativa podem custar mais do que acertar a tarefa de primeira. Avaliamos trabalhos representativos e escolhemos o modelo de menor custo que atinge o padrão de qualidade de cada Expert, o mesmo princípio de custo por sucesso que usamos em todo o Cosmos.
Hoje, usamos o GPT-5.6 Sol para trabalhos que exigem muito julgamento, como análise de risco, revisões Deep e Pair e correção de código. Tarefas delimitadas e mecanicamente verificáveis, como agregação de dashboard e monitoramento de conflitos de merge, rodam no GPT-5.6 Luna. Modelos com TTLs de cache mais longos também favorecem agentes de execução prolongada, porque a entrada em cache normalmente tem desconto de 90%.
4. Um caminho de aprovação configurável com cosmos approve
O Risk Analyzer sempre pôde aprovar mudanças intrinsecamente de baixo risco sob uma política conservadora. Agora oferecemos um segundo modo de aprovação, desativado por padrão, para outras mudanças.
O autor do PR pode comentar cosmos approve para solicitar uma avaliação contra uma política de aprovação. Um humano ainda detém e executa o merge final.
As organizações definem sua própria política de aprovação. Nossa política interna verifica:
- Propriedade: O solicitante é o autor do PR, e o autor é um CODEOWNER efetivo de todos os arquivos modificados.
- Revisão no commit atual: Não há apontamentos não resolvidos do Deep Reviewer, bloqueios do Pair Reviewer ou comentários humanos sem resposta.
- Sem evidências de runtime contraditórias: O Verifier não relatou nenhum defeito não resolvido no commit atual.
5. A customização faz parte da arquitetura
Projetamos a frota para que as equipes possam customizar o loop com o Cosmos Advisor.
- Frota: Adicionar, remover ou substituir experts; escolher o modelo e o prompt para cada responsabilidade.
- Operação: Configurar triggers, ferramentas, integrações e ambientes de verificação.
- Controle: Restringir quem pode acionar ações e quais credenciais, repositórios e sistemas cada expert pode acessar.
- Política: Definir regras de aprovação, checks obrigatórios, requisitos de CODEOWNER e evidências aceitáveis.
O modelo operacional para revisão de PR nativa de IA
A lição da nossa primeira versão foi que a revisão de código não poderia escalar pedindo que humanos lessem código gerado por IA mais rápido. A lição desta versão é mais ampla: nenhum agente de revisão individual consegue otimizar o caminho completo até o merge.
Um loop do PR ao merge de alto desempenho precisa de:
- Especialização dos agentes: Separar risco, corretude, julgamento de design, verificação em runtime e correção.
- Minimizar os checkpoints humanos: Trazer os humanos apenas para decisões importantes e transferência de conhecimento.
- Evidências: Dar aos revisores provas inspecionáveis em vez de veredictos sem embasamento.
- Loops de correção: Deixar que os apontamentos voltem para a implementação sem esperar intervenção manual.
- Observabilidade: Deixar o estado de toda a frota legível em um só lugar.
- Disciplina de custo: Usar o modelo mais barato que atinge o padrão de qualidade de cada responsabilidade.
- Configurabilidade: Customizar o loop para os requisitos específicos de cada organização.
- Propriedade humana: Manter a decisão final de merge com as pessoas responsáveis pelo software.
Isso é loop engineering aplicado ao ciclo de vida do PR: otimizar o sistema que produz uma mudança verificada, compreendida e pronta para merge, e não a quantidade de saída produzida por um único agente.
Monte seu próprio loop do PR ao merge
O Cosmos dá às equipes de engenharia o contexto compartilhado, os controles de runtime, as integrações e os checkpoints humanos para executar agentes em revisão, verificação, correção e no restante do ciclo de vida do software.
