# Verificação fora do agente: o que sustenta um time em que a IA escreve o código
Agentes erram de formas previsíveis: duplicação, ramificações sem teste, falhas de segurança. Por que checagens determinísticas ficam fora do agente.
Em 12 de outubro de 2026, a Bloomberg noticiou que a Epic Games atrasou um projeto e, segundo a reportagem, pediu aos desenvolvedores um modelo de produção "AI-first", sem mais código escrito à mão. Tim Sweeney confirmou o pivô da empresa para IA, mas não os detalhes da orientação. No dia seguinte, a Microsoft publicou um texto sobre o agente que resolve incidentes de rede em produção na Azure Networking, com uma lição: nenhum mecanismo isolado é suficiente, e as quatro fronteiras descritas são todas determinísticas. Quando a orientação é "o agente escreve", o que fica entre ele e a produção?
Na Develoz, reunimos essas checagens na gem rails-quality-assurance. Ela combina análise de código, auditorias de segurança e testes no desenvolvimento e no CI. O agente recebe os resultados para corrigir o trabalho, mas não decide sozinho se ele pode ser aceito.
Como usamos a rails-quality-assurance
Essas checagens rodam no desenvolvimento e no CI de todos os nossos projetos Rails, dentro da rails-quality-assurance, uma gem nossa. O comando bin/ci executa a sequência: RuboCop, Reek, Flay, lint do JavaScript, lint de markdown e YAML, auditorias de dependências, Brakeman e RSpec. O critério de cobertura vem do SimpleCov configurado pela gem, com 100% de linha e de ramificação, e o pré-commit hook é gerado no mesmo pipeline. Cada projeto herda a base de configuração do RuboCop em uma única linha, e os ajustes locais ficam explícitos no nível da aplicação.
Revisão hoje é conselho, não bloqueio
O retrato mais útil do estado atual vem do State of AI Code Review 2026, da Kodus, publicado em kodus.io/data, com 180.739 sugestões. Três números importam: PRs escritos por IA recebem 1,6 vezes mais apontamentos, quebram as regras internas do time 2,1 vezes mais, e 71,8% dos PRs marcados com um problema foram mesclados mesmo assim, com a marcação ainda aberta.
Esse último número define a situação: a revisão entrega um comentário, e quem decide agir sobre ele é o autor. Com um agente escrevendo sem parar, conselho sem consequência vira dívida em escala.
O que cada passo checa
Um agente competente ainda erra de formas previsíveis, e cada erro tem uma checagem que o intercepta.
Duplicação e problemas de estrutura. Ao resolver dois tickets parecidos, o agente copia a solução em vez de extrair uma abstração. O Flay e o Reek apontam trechos idênticos e padrões de estrutura, algo que o autor raramente vê.
Segurança estática e dependências. O agente reproduz padrões inseguros que leu em outros contextos. O Brakeman aponta pontos de ataque em código Rails, e a auditoria de dependências pega versões com vulnerabilidade conhecida. O GenAI Code Security Report, da Veracode, publicado em 28 de julho de 2026, mostra o seguinte: cerca de 44% das tarefas de geração de código produziram uma vulnerabilidade conhecida, e a taxa de aprovação em segurança segue estagnada em torno de 56%. O problema não é de um modelo específico.
Cobertura de ramificações. O agente escreve o teste do fluxo principal e esquece os caminhos alternativos: valor nil, exceção do serviço externo, registro inexistente. Exigir 100% de cobertura de linha e de ramificação transforma essa omissão em falha de build. No nosso caso, um &. sobre um valor nunca nil vira uma ramificação inalcançável: a checagem acaba policiando o próprio teste.
Hook de pré-commit. Antes do PR existir, um hook roda RuboCop, Reek e RSpec no commit. O agente recebe a correção com o contexto carregado, mais barato do que descobrir tudo no CI.
Por que a checagem precisa ficar fora do agente
Poderia o agente se autoavaliar? Em 13 de outubro de 2026, o site de Martin Fowler publicou "Are Harnesses Worth the Cost?", de Naresh Jain. O experimento compara dois modelos em um único serviço Java novo, em 10 execuções. O GPT-6 Sol, o modelo mais avançado, passou nos 178 testes de aceitação nas 10 execuções, com ou sem estrutura de verificação; a estrutura multiplicou o custo por cerca de 7. O GPT-6 Luna, o modelo mais barato, foi de 3 em 10 sem estrutura para 10 com ela, e ainda custou 33% menos por execução: US$ 0,273 contra US$ 0,406. O custo estimado não inclui montar e manter a estrutura. Direção observada em um único serviço, não prova universal nem promessa de economia.
A conclusão do artigo sustenta este post: o que muda com a capacidade do modelo é a frequência dos sensores, não a necessidade de um verificador independente. Para modelos de fronteira, o artigo sugere rodar as checagens uma vez, como porta final de aceitação. Escolhemos um lado prático: sensores baratos comparados ao custo de um erro em produção, então mantemos verificação em todo ciclo, mesmo com modelos bons.
Há um segundo motivo: o agente é probabilístico. A Microsoft resume a arquitetura em um princípio: esqueleto determinístico, preenchimento probabilístico. O que vai para produção não pode ser decidido por quem adivinha. Em 1º de setembro de 2026, a Manifold Security divulgou oito falhas, em sete agentes de linha de comando, que deixavam o próprio .git/config executar código do atacante antes de qualquer pedido de confirmação de confiança, com quatro das oito sem correção na data da publicação. O ambiente do agente também é superfície de ataque, o mesmo ponto das fronteiras de credencial do post anterior.
Em 13 de outubro de 2026, a Rails Foundation publicou a terceira etapa do Agents on Rails, o mesmo benchmark do post anterior, agora com tarefas grandes, de vários passos, em que o agente estende o próprio trabalho. Nossa leitura: nesses casos, a distância entre o que o agente acredita ter feito e o que o código faz cresce, e é ela que as checagens medem.
```mermaid
flowchart TD
A[Agente escreve código] --> B[Hook de pré-commit
RuboCop, Reek, RSpec]
B -- falha --> A
B -- passa --> C[Pipeline de CI
estilo, segurança, testes,
cobertura de linha e ramificação]
C -- falha --> A
C -- passa --> D[Porta de aceitação
revisão humana]
D -- aprovado --> E[Mesclar e liberar]
```
A mesma ideia em JavaScript e, futuramente, Go
Rails segue como nossa stack principal, e a ideia não ficou presa a ela: o @develoz/quality-assurance leva a mesma bateria para JavaScript e TypeScript, lançado em 3 de outubro de 2026. O pacote é novo demais para ser chamado de maduro, e não fazemos essa afirmação. A estrutura é outra, Biome, Vitest com cobertura via v8, pnpm, mas o desenho é o mesmo: critérios que quebram o build, fora do agente. Ele responde: "isso funciona só porque vocês escolheram Ruby?". Não.
Um kit equivalente para Go está sendo preparado, ainda sem data anunciada.
Em resumo
A rails-quality-assurance reúne análise de código, auditorias de segurança e testes para verificar o trabalho do agente.
O estudo da Kodus mostra um problema: 71,8% dos PRs sinalizados foram mesclados com apontamentos ainda abertos. Não recomendamos tratar a revisão como conselho opcional.
Na Develoz, usamos checagens no desenvolvimento e no CI. Os resultados orientam as correções; a decisão de negócio continua com pessoas.
Rails é nossa stack principal. A ferramenta para JavaScript e TypeScript já existe; a equivalente para Go está em preparação.
Em outro post nosso, revisão humana e limites de automação, detalhamos onde a aprovação humana fica. Ela vale no fim deste pipeline: as checagens eliminam o mecânico, e a decisão de negócio segue com gente.
Quer avaliar onde agentes e IA podem entrar na sua operação, conectados aos sistemas que já rodam? Solicitar diagnóstico.
- [Página inicial](https://develoz.com/)
- [Blog](https://develoz.com/blog)