Revisão de código com IA: o que deteta e o que lhe escapa
A revisão de código com IA consiste em ferramentas que leem um pull request ou um repositório inteiro e assinalam bugs, padrões de vulnerabilidade conhecidos, segredos expostos e problemas de estilo antes de o código ser fundido. Em 2026 traz uma ironia que o nome esconde: boa parte do código que a IA revê foi escrito por outra IA — um modelo a corrigir os trabalhos de casa de outro.
Quem está mais perto desse ciclo é quem mais desconfia dele. O inquérito de programadores 2025 da Stack Overflow mostra a confiança no resultado da IA sem revisão a cair precisamente entre quem usa as ferramentas todos os dias. A Doomity, empresa de desenvolvimento de software com clientes nos EUA, Reino Unido, Espanha e Portugal, audita codebases geradas por IA para produção e para due diligence de investidores — este guia cobre o que a revisão com IA faz mesmo bem, e onde para.
Atualizado: agosto de 2026
O que verifica de facto uma revisão de código com IA?
Problemas com forma de padrão, depressa e barato. As ferramentas atuais são genuinamente boas a apanhar classes de vulnerabilidade conhecidas — injeção, path traversal, desserialização insegura — além de segredos hardcoded, validação de entrada em falta, erros óbvios de nulos e deriva de estilo. A correr em cada pull request, isso é valor real: um primeiro leitor incansável que não salta nenhum diff por ser sexta-feira.
Essa força tem uma fronteira com nome: a ferramenta revê o código que vê, contra padrões que já viu. Numa codebase que foi ela própria gerada por IA — o cenário de corrigir código feito com IA vs refazer do zero — a revisão herda os pontos cegos da geração.
O que escapa à IA que um engenheiro sénior apanha?
Tudo o que não está no diff. Um revisor de IA vê a alteração; não esteve na reunião onde a alteração era a ideia errada. As falhas recorrentes que a Doomity encontra ao auditar atrás de codebases revistas por IA: arquitetura que não escala para lá da demo, modelos de permissões coerentes mas errados para o negócio, lógica plausível e incorreta — código que se lê bem e faz o que não deve — e as decisões simplesmente ausentes: sem plano de rollback, sem política de retenção de dados, sem modelo de ameaças.
A evidência de que os geradores não conseguem auditar-se a si próprios é quantitativa: cerca de 45% do código gerado por IA introduz vulnerabilidades conhecidas (Veracode 2025), produzido por modelos que reveriam esse mesmo código e o dariam por bom. Um modelo diferente a rever é melhor do que nada. Continua a ser correspondência de padrões, não critério.
Revisão com IA ou auditoria humana — quando é cada uma?
As duas têm lugar, e o erro é usar a barata onde é devida a cara. A posição da Doomity, sem rodeios: revisão com IA como porta de cada pull request, sim — como única auditoria antes de produção ou de uma due diligence, não:
| O que está a ser julgado | Revisão com IA | Auditoria humana sénior |
|---|---|---|
| Padrões de vulnerabilidade conhecidos | Forte: o seu terreno, em cada PR | Coberto, mas mais lento e caro por conclusão |
| Segredos e configuração | Boa a apanhá-los dentro do código | Verifica também onde os segredos vivem fora do repo |
| Arquitetura e modelo de permissões | Vê ficheiros, não o sistema nem o negócio | O coração do trabalho — incluindo o que devia existir e não existe |
| Correção da lógica de negócio | O código plausível-mas-errado passa | Apanha-se lendo o código contra o negócio, não contra padrões |
| Veredicto para agir | Uma lista de conclusões, sem ordem de consequência | Um plano priorizado: o que bloqueia o lançamento e o que espera |
O que deve cobrir a revisão de uma aplicação feita com IA?
Se a codebase foi gerada por IA, a lista de revisão não é genérica: aponta aos sítios que a geração falsifica com mais fiabilidade. Seis pontos, pela ordem em que a Doomity os audita:
- Autenticação que verifica. Não o ecrã de login: as verificações atrás de cada rota e de cada chamada à API.
- Regras de dados por utilizador. Um utilizador autenticado consegue ler os registos de outro? A fuga clássica do código gerado.
- Segredos fora do cliente. Chaves e tokens fora do bundle do frontend e fora do histórico do repositório.
- Deploys com retorno. Um caminho de rollback ensaiado, não presumido.
- Testes que protegem o crítico. Pagamento, registo, exportação de dados: os fluxos onde uma regressão custa dinheiro a sério.
- Rastreabilidade de dependências e licenças. O que a IA foi buscar e sob que licenças — a primeira coisa que o assessor de um investidor verifica.
Quando é que a revisão de código vira um problema de due diligence?
No momento em que uma ronda ou uma aquisição entra no roteiro. O assessor técnico do investidor vai ler o repositório, e uma codebase gerada por IA com apenas revisão de IA por trás é exatamente o perfil que trava negociações — a lista do que procuram está em 5 red flags que matam uma ronda. Chegar com a sua própria auditoria sénior ganha a explicar as conclusões de outro.
A Doomity trabalha os dois lados desse momento: o endurecimento para produção e a preparação do exame com o seu serviço de due diligence tecnológica. Os seus engenheiros vêm de equipas que construíram para a Holcim, a Canon España e a Indra, e o seu processo de entrega integra IA — até 40% mais rápido, com cada conclusão verificada por um engenheiro sénior. Essa última cláusula é o argumento inteiro desta página.
FAQ
Como porta por PR, pode carregar quase toda a rotina: padrões, segredos, estilo, bugs óbvios. Como autoridade final antes de produção ou de uma decisão de investimento, não — não sabe julgar arquitetura, lógica de negócio nem o que falta por completo. A montagem que funciona: revisão com IA em cada pull request, auditoria humana sénior nos momentos com consequências.
Ajuda, com uma nuance: a revisão herda os pontos cegos da geração. O relatório 2025 da Veracode concluiu que cerca de 45% do código gerado por IA introduz vulnerabilidades conhecidas — escrito por modelos que também o reveriam sem protestar. Um segundo modelo apanha parte. Um engenheiro sénior a ler a autenticação, as regras de dados e as permissões apanha a parte que acaba num relatório de incidente.
Escolha pelo fluxo de trabalho, não por ranking: uma que comente pull requests se a equipa vive no GitHub, revisão integrada no editor se as falhas devem ser apanhadas antes do PR, ou ambas. O diferenciador é a adoção — a ferramenta que a equipa deixa ligada ganha à teoricamente melhor. Nenhuma escolha de ferramenta muda o que a revisão com IA perde estruturalmente.
Corra os dois diagnósticos gratuitos da Doomity antes de pagar a alguém: o de produção em /pt/ferramentas/diagnostico-de-producao para saber se está pronta para lançar, e o de investidores em /pt/ferramentas/diagnostico-para-investidores para a due diligence. Dez perguntas cada, três minutos, e um veredicto pontuado sobre se o próximo passo honesto é corrigir ou ser examinado.
Se a sua codebase foi escrita — ou revista — sobretudo por uma IA e o próximo passo são utilizadores ou investidores reais, o passo útil é uma auditoria em que um engenheiro sénior lê o que os padrões não sabem julgar.