Code review com IA: a IA consegue revisar seu app construído com IA?

O code review com IA é útil para um app construído com IA, mas não basta sozinho. Ele é bom para encontrar bugs óbvios, padrões inseguros e código bagunçado. É fraco justamente no que mais machuca os fundadores: quem pode ler quais dados, quais chaves estão no navegador e se um pagamento realmente foi concluído.

Sou um engenheiro brasileiro que já fez muitos code reviews humanos, e eu mesmo uso revisores de IA. Minha regra prática: deixe a IA fazer a primeira passada e depois peça para uma pessoa verificar os poucos fluxos em que um erro custa dinheiro ou vaza dados.

O que o code review com IA pega bem?

Onde um padrão é comum e bem documentado, os revisores de IA se saem bem. Eles leem um arquivo inteiro em segundos e não se cansam. Na minha experiência, são fortes em:

• Legibilidade e estrutura: lógica duplicada, componentes gigantes, nomes pouco claros, código morto.
• Padrões comuns de bugs: falta de tratamento de erros, promises sem await, acesso a null, erros de off-by-one.
• Trechos inseguros conhecidos: SQL montado com strings, renderização de HTML sem sanitização, segredos obviamente fixos em um arquivo.
• Testes e tipos faltando: sugerir onde um teste ou um tipo mais estrito de TypeScript ajudaria.
• Higiene de dependências: apontar pacotes desatualizados ou não utilizados.

Isso é valor real. Em um time, eu ficaria feliz em ter cada pull request passando por uma revisão automática antes de uma pessoa abri-lo. Isso economiza o tempo do revisor para as perguntas que só uma pessoa consegue responder.

Onde funciona melhor

Funciona melhor em mudanças pequenas e autocontidas, com contexto claro. Quanto mais do quadro ele consegue ver, melhor. Dê uma função e ele revisa uma função. Ele não consegue dizer que essa função é chamada de uma tela onde o usuário errado consegue chegar.

O que ele deixa passar em apps gerados por IA?

As falhas não são aleatórias. Elas se concentram em lugares onde o código parece correto, mas as regras estão erradas. O código pode passar em todas as verificações de estilo e ainda assim deixar qualquer usuário logado ler os registros de todo mundo.

Regras de acesso a dados

Apps construídos com Lovable têm mostrado um padrão de regras fracas de row level security (RLS) no Supabase. Um revisor lendo o frontend vê uma query que funciona. Ele não sabe se a policy do banco de dados por trás dela permite só as linhas do dono ou todas as linhas. Você precisa olhar as próprias policies e testá-las com dois usuários diferentes.

Chaves no navegador

Algumas chaves foram feitas para ser públicas, como a anon key do Supabase, desde que a RLS esteja correta. Outras, como a chave secreta do Stripe ou uma service role key, nunca podem chegar ao navegador. Um revisor de IA pode não saber qual é qual na sua configuração, ou pode tratar uma chave vazada como uma observação menor.

Fluxos de pagamento e lógica de negócio

Scanners genéricos e revisores de IA deixam passar lógica de negócio, como webhooks do Stripe e pedidos duplicados. Perguntas como estas precisam de alguém que entenda o fluxo:

• O acesso é liberado quando o usuário volta para uma página de sucesso, ou só depois de um webhook verificado?
• A assinatura do webhook é verificada?
• O que acontece se o mesmo evento chegar duas vezes?
• Um usuário consegue alterar um preço ou uma quantidade na requisição?

Nenhum desses é um problema de sintaxe. São perguntas sobre intenção, e o modelo não conhece a sua intenção a menos que você a escreva.

Por que pedir para o construtor revisar o próprio código não basta?

É tentador digitar “revise este app em busca de problemas de segurança” na mesma ferramenta que o construiu. É grátis e rápido, e às vezes encontra algo real. Mas tem limites.

As regras de dados, as chaves e os fluxos de pagamento são justamente o que essas ferramentas costumam errar. Quando o mesmo modelo revisa o próprio resultado, muitas vezes ele compartilha os mesmos pontos cegos e as mesmas suposições. Ele também pode “corrigir” um problema mudando o código de um jeito que quebra outra coisa, porque não enxerga o seu sistema inteiro.

Há também uma questão de responsabilidade. A plataforma protege a própria infraestrutura e as contas. O dono do app é responsável por quem pode ler quais dados, pelas chaves no navegador, pela confirmação de pagamento e pelos backups. Uma resposta no chat do construtor não transfere essa responsabilidade. Você ainda precisa verificar.

Não digo isso para desmerecer as ferramentas. Um exemplo documentado: em julho de 2025, pesquisadores da Wiz descobriram que o Base44, da Wix, permitia que um atacante se cadastrasse em apps que deveriam ser privados usando apenas o ID do app, e isso foi corrigido em um dia. Era um problema da plataforma, não do dono do app. As regras do seu próprio app são uma camada separada, e ninguém mais vai verificá-las por você.

Como combino code review com IA e revisão humana?

Use cada um para o que faz de melhor. Esta é a ordem que eu seguiria:

1. Rode um revisor de IA para a primeira passada. Se puder, use uma ferramenta diferente da que escreveu o código. Reúna os apontamentos e não os aplique às cegas.
2. Rode um scanner ou uma verificação de dependências. É barato e pega problemas conhecidos. Trate um resultado limpo como uma informação, não como um veredito.
3. Escreva suas regras em linguagem simples. Por exemplo: um usuário só pode ver os próprios pedidos; um pedido só é considerado pago depois de um webhook verificado.
4. Peça para uma pessoa testar essas regras. Faça login com dois usuários e tente ler os dados do outro. Reenvie um webhook. Tente alterar um preço na requisição.
5. Corrija os itens de maior risco no código existente. Uma reescrita raramente é a primeira resposta.
6. Rode as verificações de novo depois das mudanças e confirme que os backups podem de fato ser restaurados.

A maior parte do risco é encontrada por algumas verificações focadas, e não por uma auditoria completa. O custo de corrigir cresce depois que chegam usuários e pagamentos reais, então fazer isso cedo é o caminho barato.

Quais partes do app precisam primeiro de um olhar humano?

Se você só tem uma tarde, gaste aqui. Estas são as quatro verificações que cobrem a maior parte do risco antes da chegada dos usuários reais.

Sobre code review em geral, já liderei mais de 15 pessoas em projetos web, mobile e de e-commerce, incluindo planejamento de sprint, code review, mentoria e DevOps. O que aprendi ali se aplica diretamente: os revisores devem gastar a atenção nos fluxos arriscados, não na formatação. A automação cuida do resto.

Quando continuar no construtor tudo bem

Continuar no construtor às vezes é a melhor decisão, por exemplo para uma ferramenta interna ou um protótipo com poucos usuários e sem pagamentos. Código construído no Lovable pode ser levado para o GitHub e para a sua própria hospedagem depois, então você mantém essa opção. As verificações acima continuam valendo onde quer que o app rode.

Quer uma segunda opinião sobre o seu app?

Se você tem um app construído com IA e quer trocar ideias, mande um email para me@filipeeduardo.dev com o link e algumas linhas sobre o que ele faz, e eu digo o que verificaria primeiro.