Revisão de código com IA: a política que mantém humanos no controle

Uma política de revisão de código com IA estabelece uma regra inegociável para o time: a IA pode escrever e inspecionar código, mas uma pessoa identificada responde pelo merge. Toda alteração feita com auxílio de IA deve informar como a tecnologia foi usada, passar por verificações determinísticas e receber uma revisão humana proporcional ao dano que pode causar.

Essa separação é especialmente importante agora. Em 17 de agosto de 2026, a Wiz revelou uma falha crítica de injeção no GitHub Actions em um repositório público da Snowflake. O commit squash final creditava o Copilot Autofix como coautor, e a revisão de segurança assistida por IA do GitHub considerou que a mudança não apresentava problemas. A Wiz deixou claro que não se sabe se a alteração no código em si teve auxílio de IA. Cinco dias depois de a falha entrar no ar, um agente autônomo de segurança a encontrou e explorou em testes autorizados.

A conta ajuda a entender por que as equipes ainda querem automação. Um time que processa 50 pull requests por semana e gasta 30 minutos na primeira análise humana consome 25 horas de engenharia. Considerando um custo total ilustrativo de $120 por hora, são $3,000 por semana antes mesmo de uma revisão mais profunda. Hoje, o GitHub estima que uma revisão do Copilot custe de $0.05 a $1 em créditos de IA no esforço Lite ou de $0.25 a $5 no esforço Balanced, além dos minutos do GitHub Actions. A primeira triagem está ficando barata. A autoridade para aprovar, não.

O que uma política de revisão de código com IA realmente faz

Uma boa política funciona como controle de tráfego para o código, não como proibição ao uso de IA. Ela define o que os autores precisam declarar, o que a automação deve bloquear e quando um segundo par de olhos humanos se torna obrigatório.

Imagine um pull request como uma carga chegando ao porto. Testes e scanners inspecionam o contêiner. Um revisor de IA lê o manifesto e aponta itens suspeitos. Ainda assim, é um agente humano que decide se a carga cruza a fronteira. Entregar o carimbo desse agente à ferramenta de inspeção anula o controle.

Use este texto como núcleo da política:

Código criado ou alterado de forma relevante com uma ferramenta de programação por IA só é permitido por meio de um pull request. O autor continua responsável por compreender a mudança e deve identificar a ferramenta, o escopo da assistência de IA, os testes executados e o responsável humano. Os testes e controles de segurança obrigatórios devem passar antes da aprovação. A revisão por IA é apenas consultiva e nunca conta como uma aprovação humana obrigatória. Arquivos sensíveis exigem um responsável pelo código. Mudanças críticas exigem um segundo aprovador independente e um plano de rollback. Novos commits invalidam aprovações anteriores e acionam uma nova revisão.

Essa política se baseia nas consequências, não na detecção de autoria. Um desenvolvedor não deveria ter de provar quais linhas vieram do preenchimento automático. Ele deve declarar o uso relevante de IA e assumir a responsabilidade por todo o diff. Isso é muito mais útil do que discutir um percentual que nenhuma ferramenta consegue transformar em uma decisão de aprovação.

Adote três faixas de revisão

A faixa Crítica é cara de propósito e deve concentrar apenas uma pequena parcela das mudanças. A ideia é direcionar a atenção escassa dos profissionais mais experientes para os pontos em que um erro aparentemente plausível pode expor credenciais, corromper dados ou alterar quem tem acesso.

Como funciona, sem complicação

O fluxo tem seis controles. Cada um gera evidências que o próximo revisor pode inspecionar.

1. Declare a assistência. Adicione ao template do pull request os campos AI-assisted, tool, scope, human owner e tests run. O autor responde por todas as linhas, seja a IA responsável por uma única função ou por todo o primeiro rascunho.
2. Classifique o risco. Um pequeno arquivo de política associa caminhos e tipos de alteração às faixas Rotineira, Sensível ou Crítica. Uma mudança em .github/workflows/ jamais deveria seguir a mesma faixa de uma correção ortográfica na documentação.
3. Execute primeiro as verificações determinísticas. Determinístico significa que a mesma entrada sempre produz o mesmo resultado de aprovação ou reprovação. Compile, faça a checagem de tipos, execute o lint e os testes, procure segredos, inspecione dependências e rode a análise estática de segurança antes de pedir a opinião de outro modelo. As próprias orientações do GitHub sobre revisão colocam testes automatizados e análise estática em primeiro lugar.
4. Use a IA como revisora crítica. Peça que ela procure casos não cobertos, incompatibilidades de arquitetura, testes removidos, APIs alucinadas, pacotes suspeitos e mudanças de permissão. Use uma revisão de maior esforço em trabalhos que envolvam segurança ou atravessem vários serviços. A autorrevisão do agente que criou o código não deve cumprir esse controle.
5. Deixe o veredito com uma pessoa. O revisor confirma a intenção, testa o comportamento de risco, questiona novas dependências e decide se o diff deve entrar no sistema. Comentários da IA são pistas, não constatações, até que uma pessoa ou ferramenta determinística os confirme.
6. Reinicie o processo após cada push. Descarte aprovações desatualizadas, execute novamente os controles obrigatórios e solicite outra revisão quando chegarem novos commits. O GitHub informa que a revisão automática do Copilot normalmente é executada uma só vez, a menos que a revisão a cada push esteja ativada.

Dois controles menos óbvios também precisam entrar na política. Primeiro, arquivos de dependências exigem um scanner próprio, pois a revisão de código do GitHub Copilot exclui arquivos como package.json e Gemfile.lock. Segundo, alterações em arquivos de instruções para IA devem passar pela revisão Crítica. O Copilot lê as instruções do repositório, as instruções dos agentes e as skills a partir do branch de origem do pull request. Isso permite que a mudança proposta altere as instruções usadas para revisar a si própria.

Sete contextos em que essa política gera retorno primeiro

1. Equipes de plataforma que executam agentes de programação em vários repositórios

As equipes de engenharia de plataforma são as que mais ganham, pois uma única política pode governar milhares de mudanças futuras. Coloque o mapa de riscos em um template compartilhado, exija os mesmos campos de declaração e disponibilize um único status check que todos os branches protegidos entendam. O retorno vem do controle centralizado, sem obrigar cada equipe de produto a criar seu próprio ritual. Times que comparam os melhores agentes de programação com IA para empresas podem trocar de ferramenta sem reconstruir o modelo de aprovação.

2. Equipes de SaaS que protegem autenticação, cobrança e dados de clientes

Uma liderança de engenharia de SaaS pode classificar como Críticos os caminhos de autenticação, as verificações de permissão, o código de pagamentos e a exportação de dados. Um agente pode preparar a correção, e um revisor de IA pode questioná-la, mas o responsável por identidade ou pagamentos e mais uma pessoa precisam aprovar. O ganho é foco: revisores experientes deixam de dedicar o mesmo tempo a todos os arquivos e se concentram nas mudanças com consequências realmente amplas.

3. Equipes de DevOps responsáveis por fluxos de CI/CD

Trate arquivos de workflow como infraestrutura de produção executável. Encaminhe toda mudança a um responsável DevOps pelo código, procure a interpolação direta de conteúdo não confiável vindo de issues ou pull requests, verifique as permissões dos tokens e exija um rollback. O caso da Wiz torna o benefício concreto: o título de uma issue pública chegou a um comando do shell, e o token exposto podia ler projetos internos no Jira. Uma política intercepta essa categoria de erro antes que alguém comece a discutir se o autor original era humano ou IA.

4. Líderes de engenharia que estão adotando Copilot, Codex ou Claude Code

Quem lidera a adoção pode separar a permissão para usar a ferramenta da permissão para fazer o merge. Os desenvolvedores ganham geração rápida e uma primeira revisão, enquanto as regras dos branches continuam exigindo aprovação humana, workflows aprovados e revisão do responsável pelo código. O resultado é uma adoção com uma camada de controle auditável. Uma análise dos modos de revisão local e no GitHub do Codex pode orientar a escolha da ferramenta, mas o mesmo controle humano deve sobreviver a uma troca de fornecedor.

5. Mantenedores de projetos open source diante de pull requests sem contexto

Inclua uma caixa de seleção sobre assistência de IA e uma lista de evidências em CONTRIBUTING.md. Depois, deixe a automação rejeitar contribuições sem etapas de reprodução, testes ou um mantenedor responsável. A IA pode resumir e fazer a triagem inicial da fila. Assim, as pessoas dedicam tempo à intenção, à compatibilidade e à decisão de aceitar ou não a contribuição no projeto. O retorno é uma dívida de revisão menor, sem reduzir silenciosamente o nível de exigência para desconhecidos.

6. Agências que entregam software pertencente ao cliente

Uma agência pode anexar a cada release um comprovante de revisão: ferramentas usadas, componentes afetados, resultados dos testes, problemas ainda não resolvidos e aprovadores identificados. Os caminhos sensíveis do cliente passam pelo responsável dele antes do lançamento. O ganho é uma responsabilização mais clara e um artefato de transição que continua útil depois que a equipe de entrega sai.

7. Fundadores solo que lançam produtos com um agente de programação por IA

Um fundador solo não tem, por padrão, um colega independente. Por isso, o fluxo precisa criar essa separação. Deixe um modelo preparar o código, rode verificações determinísticas, faça outra rodada de revisão e depois teste pessoalmente o caminho de risco antes do merge. Para pagamentos, autenticação ou infraestrutura de produção, envolva um especialista externo. O retorno é um primeiro filtro barato, sem fingir que um segundo modelo equivale a uma segunda pessoa responsável.

O que dá para construir a partir dessa política

O mercado já paga por revisão automatizada. A demanda no Google é de cerca de 1,600 buscas mensais nos EUA por "ai powered code review platform", 1,300 por "ai code review" e 590 por "ai code review tools". Hoje, o CodeRabbit cobra $24 por desenvolvedor ao mês no plano Pro anual e $48 no Pro Plus. O Qodo começa em $30 por mês. A oportunidade não está em mais um bot que comenta em todo pull request, mas em uma camada de controle que decide qual revisão realmente vale.

1. Controle de pull request com policy as code, a oportunidade mais forte

Crie um GitHub App para líderes de engenharia e segurança que transforme um arquivo curto de política em verificações obrigatórias. Ele lê os caminhos alterados, confere a declaração de uso de IA, atribui uma faixa de risco, solicita os responsáveis corretos pelo código, confirma a execução dos scanners obrigatórios, invalida aprovações desatualizadas e registra um comprovante de auditoria.

A demanda sustenta a categoria: "ai powered code review platform" recebe cerca de 1,600 buscas mensais nos EUA, enquanto "ai code review" soma 1,300, com CPC de $63.85. A menor versão comercializável precisa de um GitHub App, um arquivo de política no repositório, um status check, um serviço de encaminhamento a revisores e uma tabela de auditoria. O desafio é o cansaço com configurações. O produto só vence se bons padrões cobrirem as stacks mais comuns e as exceções forem fáceis de explicar.

2. Roteador de revisores para arquivos críticos

Crie uma ferramenta mais focada para equipes de plataforma e AppSec. Ela monitora caminhos como workflows, infraestrutura, migrações, autenticação e arquivos de política; então eleva o nível da revisão, chama o responsável correto e exige uma nova análise após cada push. O código rotineiro pode passar por uma triagem barata, enquanto o raciocínio mais caro e o tempo humano ficam reservados aos diffs críticos.

"AI code review tools" recebe cerca de 590 buscas mensais nos EUA, tem intenção comercial e apresenta uma tendência anual de 50% no conjunto de palavras-chave. "Secure code review" acrescenta 170 buscas mensais, com CPC de $50.19. O MVP reúne regras por caminho, integração com CODEOWNERS, uma interface de check run e encaminhamento de revisões atento ao orçamento. O risco é o produto tentar abraçar categorias demais. Ele precisa complementar SAST, varredura de segredos e análise de dependências, não se vender como substituto.

3. Comprovante de procedência para mudanças feitas com IA

Crie uma CLI leve e um bot de pull request para agências e equipes reguladas. A solução registra a ferramenta declarada, o identificador da sessão, os arquivos alterados, os testes executados, as decisões dos revisores e o responsável humano final; depois, emite um comprovante de release assinado. O objetivo é demonstrar o processo, não tentar adivinhar a autoria pelo estilo do código.

Cerca de 210 buscas mensais nos EUA procuram um "ai generated code detector", com CPC de $16.70. Essa demanda revela uma preocupação real, mas a promessa de detecção é o produto errado. A versão comercializável entrega aos compradores evidências de revisão e responsabilidade. O desafio é a adesão: se as equipes puderem ignorar a declaração, o comprovante vira fachada. Proteção de branches e integração de identidade são o produto, não extras opcionais.

Também há espaço na disputa por citações. A verificação de citações do ChatGPT não encontrou fontes citadas de forma recorrente para "ai code review tools". Um produto que publique um esquema de política rigoroso, versionado e com controles transparentes pode se tornar a camada de referência, enquanto vende por trás dela a solução de aplicação das regras.

Limites e uma avaliação honesta

A revisão por IA é um filtro útil, não uma garantia de segurança. O GitHub afirma que a revisão do Copilot pode deixar problemas passar e precisa ser complementada por revisão humana. Ela também exclui alguns arquivos, pode recorrer a um modo menos capaz quando os runners estão indisponíveis e para quando o orçamento de créditos de IA se esgota. Nenhuma dessas condições deveria reduzir silenciosamente o rigor exigido para o merge.

O autofix agêntico tem o mesmo limite. O sistema em public preview do GitHub consegue explorar um repositório, propor uma correção, executar o CodeQL novamente e abrir um pull request em rascunho, muitas vezes em dois a quatro minutos. O GitHub também informa que o recurso opera no regime de melhor esforço, não consegue confirmar correções para algumas consultas personalizadas ou estendidas de segurança e não garante a qualidade das correções para alertas de terceiros. Uma nova execução verde comprova apenas que um detector parou de reclamar. Não prova que o comportamento do negócio, o modelo de permissões ou o workflow ao redor estejam seguros.

Essa política não resolve a detecção de autoria, testes fracos, conhecimento arquitetural ausente nem uma cultura que aprova pull requests sem análise. Ela também será pesada demais se toda correção ortográfica entrar na faixa Crítica. Mantenha a faixa Rotineira barata, reserve a Crítica para poucos casos e nunca permita que a ferramenta que produziu uma mudança se torne a única autoridade a aprová-la.

A ação para segunda-feira

Na segunda-feira, uma liderança de engenharia deve acrescentar cinco campos ao template de pull request: AI-assisted, tool, scope, human owner e tests run. Em seguida, deve classificar .github/workflows/, autenticação, pagamentos, infraestrutura de produção, segredos e migrações destrutivas como Críticos. Exija CI aprovada, revisão do responsável pelo código, descarte de aprovações desatualizadas e uma segunda pessoa nesses caminhos. Isso basta para transformar uma opinião sobre código produzido por IA em uma primeira versão aplicável.

Devo revisar o código gerado por IA?

Sim. Execute primeiro os testes e scanners determinísticos, use a revisão por IA como uma crítica adicional e então atribua a uma pessoa identificada a responsabilidade pelo merge. A revisão por IA não pode cumprir a regra de aprovação humana obrigatória.

O ChatGPT consegue fazer revisão de código?

Ele consegue criticar um diff, pedir testes ausentes e apontar lógicas suspeitas. Não consegue aplicar a proteção de branches, comprovar que a CI foi executada nem assumir as consequências em produção. Use-o dentro da política, não no lugar dela.

Qual é a melhor IA para revisão de código?

A melhor opção é a que compreende contexto suficiente do repositório, integra-se às verificações existentes, respeita os controles de dados e deixa um histórico de auditoria claro. A qualidade do modelo importa, mas a integração com o controle de merge e a responsabilidade humana importam mais.

Existe uma ferramenta gratuita de revisão de código com IA?

Há recursos gratuitos ou já incluídos. O Copilot Autofix clássico do GitHub não exige assinatura do Copilot nem consome créditos de IA em repositórios qualificados, e as ferramentas de CI existentes podem aplicar muitos controles determinísticos. Uma política completa ainda exige configuração e revisão humana.

Se quiser integrar esse controle de revisão ao seu fluxo de engenharia, conheça os sistemas de IA para produção.