Aviator lança sistema que redefine revisão de código

Tecnologia

Novo sistema da Aviator utiliza IA para aprimorar a revisão de código, mantendo o controle humano na aprovação final.

Leia também: Docusign lança motor de IA que entende contratos complexos

A Aviator lançou o Aviator Verify, sistema que automatiza a verificação de mudanças em código-fonte com agentes de inteligência artificial, mas preserva o julgamento e a decisão final nas mãos de engenheiros humanos, integrado ao fluxo de trabalho de pull requests usado hoje por equipes de desenvolvimento.

Como funciona o Aviator Verify na prática

O Aviator Verify organiza a revisão de código em sete partes e submete cada mudança a duas camadas principais: critérios de aceitação, que descrevem o que a alteração deve fazer, e invariantes, que são regras codificadas da equipe ou da organização, pensadas para serem sempre verdadeiras, independentemente do tipo de mudança.

Na maior parte das ferramentas atuais de revisão com IA, o modelo é apontado diretamente para o diff e recebe a pergunta se a alteração é boa ou não, enquanto o humano apenas confere por alto antes de aprovar. A Aviator parte do princípio oposto: agentes verificam, pessoas decidem. Segundo a empresa, “judgment needs intent, and accountability needs a person”.

Para isso, o Verify separa claramente geração e verificação. Os agentes de IA ficam responsáveis por ler o código, cruzar a alteração com as regras e cenários definidos e produzir evidências; engenheiros humanos avaliam essas evidências, checam se o resultado condiz com o que a equipe pretendia construir e aprovam, pedem ajustes ou registram exceções.

Entenda o contexto

Critérios de aceitação sem invariantes deixam os padrões do time na memória de cada engenheiro, o que aumenta a chance de erro ou de repetição dos mesmos comentários em vários PRs. Já invariantes sem critérios de aceitação produzem código que segue as regras formais, mas pode resolver o problema errado ou exagerar na solução. O Aviator Verify tenta equilibrar essas duas camadas.

A lógica da ferramenta é capturar tanto o “por quê” da mudança — a intenção — quanto “como” ela deve se comportar — os critérios de aceitação — e usar isso como referência para a verificação automática, em vez de confiar apenas no que aparece no diff.

Como o sistema cria e usa invariantes

Os invariantes são o coração da camada de padrões do time. Eles traduzem em regras explícitas aquilo que hoje aparece disperso em comentários de revisão, documentos e arquivos de contribuição. Exemplos típicos são orientações como usar um tipo específico para valores monetários, evitar escritas diretas em certas tabelas de banco de dados ou exigir contadores em todos os fluxos de erro.

O Aviator Verify gera automaticamente uma lista desses invariantes a partir do histórico de pull requests, dos comentários feitos em plataformas como o GitHub, de arquivos CONTRIBUTING.md e de arquivos de instrução para agentes. Também é possível criar invariantes “no ato”, marcando comentários com uma tag específica para que virem regras recorrentes.

Essa lista forma um registro vivo dos padrões da equipe, que a própria Aviator descreve como uma espécie de catálogo de deslizes comuns da IA. Com o tempo, cada revisão alimenta esse registro: se um invariante falhar em um PR, o autor pode justificar a exceção, revisar a regra ou corrigi-la em outro momento. Métricas internas mostram quais invariantes mais se aplicam, quais falham com frequência e quais são frequentemente ignorados, ajudando o time a ajustar o conjunto de regras.

A funcionalidade de geração de invariantes pode ser usada gratuitamente, mesmo por equipes que não adotem o sistema completo, o que abre espaço para que times comecem apenas formalizando seus padrões de código.

Como o Aviator Verify captura intenção e critérios

Em vez de depender apenas de especificações escritas antes do desenvolvimento ou de tickets detalhados, o Aviator Verify captura a intenção e os critérios de aceitação diretamente da sessão de codificação em que engenheiro e agente de IA interagem.

Durante o trabalho, cada vez que o agente para para fazer perguntas e o engenheiro toma uma decisão — onde guardar determinado estado, o que fazer quando uma dependência falha, se deve reaproveitar um helper existente ou criar um novo — esses pontos vão definindo, na prática, o comportamento esperado da mudança. A Aviator lembra que “an AI-written PR is full of calls like these, and almost none of them show up in the diff”.

Antes que o pull request seja aberto, um comando do Verify extrai, com ajuda de um agente, a intenção e os critérios de aceitação a partir de tudo o que aconteceu nessa sessão. O engenheiro revisa, corrige e complementa o texto. O resultado é uma descrição fiel do que se quis fazer e de como o código deveria se comportar, associada à própria mudança.

Verificação automática e papel dos agentes de IA

Com intenção, critérios e invariantes definidos, o Aviator Verify cruza essas informações com o diff para montar uma lista de cenários de verificação. São passos concretos que agentes de IA vão executar para testar o comportamento da mudança e checar se as regras da equipe foram respeitadas.

Quando há infraestrutura disponível, o sistema cria um ambiente de pré-visualização e despacha agentes verificadores para rodar esses cenários. Eles podem interagir com a interface gráfica, tirar capturas de tela, inspecionar estado de banco de dados, logs de servidor e console e, para cada critério e invariante, produzir um veredito com evidências anexadas.

Não é obrigatório ter esse ambiente desde o início. Muitas checagens estruturais podem ser feitas diretamente a partir do diff, com scripts determinísticos ou agentes separados, sem exigir mudanças de infraestrutura. Segundo a Aviator, o uso de previews ganha importância à medida que os critérios de aceitação passam a exigir comportamento que não é evidente apenas lendo o código.

O que muda para engenheiros na revisão de código

No fluxo de trabalho de pull requests, quase nada muda em termos de interface: o Verify adiciona um link com o resultado da verificação e registra um status de checagem, semelhante ao que já acontece com pipelines de integração contínua.

O impacto está no tipo de informação que o revisor vê. Em vez de ler o código linha a linha à procura de problemas, o engenheiro passa a olhar primeiro para a intenção descrita, para as decisões registradas — rotuladas como humanas ou tomadas por agentes — e para o conjunto de veredictos sobre critérios e invariantes, cada um ancorado em evidências.

A pergunta central da revisão deixa de ser apenas “o código está certo?” para virar “as evidências mostram que construímos o que combinamos?”. A partir daí, o revisor pode aprovar, contestar uma decisão específica, pedir novos cenários de verificação ou abrir exceções justificadas para determinadas regras.

Segundo a Aviator, a adoção do Verify tende a ser gradual. Em um primeiro momento, as equipes podem ligar apenas a geração de invariantes, o que implica algum trabalho em dobro: revisão tradicional e registro de padrões. Com o tempo, à medida que a lista de invariantes fica mais robusta, a revisão manual tende a encolher, focando mais em decisões de arquitetura, casos-limite e alinhamento com objetivos de produto.

Impacto para empresas de tecnologia

Para empresas que usam intensivamente agentes de IA na escrita de código, o Aviator Verify se posiciona como uma forma de acelerar ciclos de desenvolvimento sem abrir mão de governança, segurança e responsabilidade sobre o que vai para a base de produção.

Ao automatizar as partes mais repetitivas e detalhistas da revisão e registrar padrões de forma sistemática, a ferramenta promete reduzir erros recorrentes, retrabalho e violações a normas internas, além de facilitar a adoção e a manutenção de boas práticas entre times grandes e distribuídos.

Como o modelo de uso mantém a decisão final nas mãos de engenheiros humanos, a solução também tenta responder a uma preocupação crescente do setor: evitar que sistemas de IA tomem decisões de forma opaca, sem contexto e sem alguém claramente responsável pelos resultados.