Como verificar código gerado por IA sem saber programar: 7 verificações em 2026

A IA criou-lhe um site ou um bot numa noite. Tudo abre, os botões funcionam e parece estar tudo a correr bem. Mostra o projeto a outras pessoas — e, um dia depois, descobre que o formulário de pagamento cobra o dinheiro, mas as encomendas nunca chegam. Ou que a base de dados com os números de telefone dos clientes está acessível a toda a Internet.

Também eu costumava lançar os meus primeiros projetos assim: coisas que pareciam funcionar acabavam por surpreender os utilizadores reais. Agora, antes de mostrar seja o que for a alguém, passo o projeto pela mesma lista de verificação. Não leio uma única linha de código enquanto o faço — não foi para isso que aqui vim, e provavelmente você também não.

E isto não é paranoia. A Anthropic analisou 400 000 sessões do Claude Code: ao longo de sete meses, a percentagem do trabalho dedicada a corrigir código com erros caiu de 33% para 19%. Diminuiu, mas não desapareceu. Uma em cada cinco sessões continua a ser sobre «corrigir aquilo que a IA estragou».

Escrever código já não é o estrangulamento. O que importa agora é até que ponto compreende a tarefa e consegue verificar o resultado.

Pode encontrar materiais adicionais sobre a configuração de ferramentas na documentação da Ailoot.

Porque verificar código gerado por IA se já funciona?#

A IA escreve código que passa num primeiro olhar. É executado, o ecrã aparece e a demonstração parece convincente. Mas lançá-lo não lhe diz se o dinheiro está a ser calculado corretamente, se a sua base de dados está exposta ao exterior ou se tudo vai falhar quando chegar o centésimo utilizador.

Os números confirmam-no. O benchmark FrontierCode avaliou, em junho de 2026, até que ponto o código gerado por IA estava pronto para trabalho real sem alterações. Mesmo nos melhores modelos e nas tarefas mais difíceis, a percentagem foi de cerca de 13%. Por outras palavras, em tarefas sérias, a maior parte do código gerado por IA tem de ser aperfeiçoada manualmente antes de poder confiar nele.

A boa notícia é que qualquer pessoa pode fazer esta verificação. Eis a conclusão da Anthropic a partir das mesmas 400 000 sessões:

A sua vantagem em relação a qualquer programador que contrate é compreender a sua tarefa. Verificar também implica compreender; não precisa de ler código para o fazer. As verificações abaixo são precisamente do tipo que pode fazer por si, sem complicações.

O que pode realmente correr mal com código gerado por IA?#

Antes de verificar, ajuda saber o que procura. O código gerado por IA tem cinco problemas típicos, e pode detetar todos sem ler código — observando o comportamento do projeto.

Seguem-se sete verificações, por ordem. As primeiras detetam problemas do tipo «não funciona» e «funciona incorretamente»; as do meio abrangem segurança e invenções; as últimas são salvaguardas antes da publicação. É melhor fazê-las por ordem: cada uma pressupõe que a anterior está concluída.

Verificação 1: Peça à IA que explique o código em linguagem simples#

Descreveu a tarefa por palavras. A IA traduziu-a para código. Pode perder-se o significado entre estes dois passos: a IA pode ter percebido algo diferente, preenchido lacunas por si ou tomado atalhos. Pode detetar a discrepância sem ler código — basta pedir-lhe que descreva, em linguagem simples, aquilo que fez.

Explica em linguagem simples, sem código, exatamente o que acabaste de fazer:

a tarefa que este código resolve

o que acontece quando um utilizador clica no botão ou envia o formulário

onde os dados são guardados e quem tem acesso a eles

o que pode correr mal e em que situação

Escreve como se estivesses a explicar isto a alguém que nunca programou. Se houver alguma parte cuja correção não tenhas a certeza, diz isso claramente.

Leia a resposta e compare-a com aquilo que tinha em mente. Se corresponder, avance. Se a IA «disser coisas vagas», se confundir na própria explicação ou descrever algo diferente do que pediu, isso significa que não compreende totalmente aquilo que criou. Peça-lhe que reveja o trabalho e esclareça o pedido, em vez de aceitar a resposta sem questionar.

A propósito, se a IA faz regularmente algo diferente do que pediu, o problema está muitas vezes na forma como a tarefa foi formulada, não no modelo em si. Tenho uma análise separada sobre porque é que o Claude não faz o que pediu.

Verificar o resultado da IA faz parte da engenharia de contexto: controla tanto aquilo que fornece à IA como entrada como a forma de avaliar o resultado como saída. O conjunto de ferramentas inclui um clone de IA, um Segundo Cérebro e Engenharia de Contexto. Depois disso, o Claude deixa de ser um «assistente que alucina» e passa a ser uma ferramenta em que pode confiar para trabalhar num projeto.

Verificação 2: Percorra os cenários como um utilizador real faria#

Uma demonstração de IA segue sempre o percurso ideal: dados corretos, um clique, tudo corre bem. Um utilizador real não se comporta assim. Comete erros, clica na coisa errada ou introduz um emoji no campo do telefone. A sua tarefa é percorrer o projeto como ele o faria.

1. Conclua o cenário principal do princípio ao fim

   Faça aquilo para que o projeto foi criado: registe-se, faça uma encomenda, envie um pedido. Vá até ao fim, não fique a meio.

2. Verifique os pagamentos separadamente e na prática

   Se o projeto aceitar dinheiro, faça um pagamento por si no modo de teste, pelo valor mínimo. Confirme que a encomenda é criada, que o estado muda e que recebe um e-mail, tal como o cliente. Um pagamento que «é efetuado», mas não cria uma encomenda, é uma falha silenciosa clássica.

3. Provoque problemas de propósito

   Deixe campos em branco. Introduza letras onde são esperados números. Clique duas vezes seguidas em «Enviar». Carregue um ficheiro no formato errado. Um bom projeto dirá educadamente «não pode fazer isso»; um mau projeto falha ou descarta os dados sem avisar.

4. Abra-o num telemóvel

   Metade das pessoas chegará através de um telemóvel. Confirme que o esquema não ficou desfeito e que os mesmos botões funcionam.

Apresente à IA tudo o que encontrou numa só lista: «Foi isto que falhou nestes passos; corrige e explica porque aconteceu.» Não trate um problema de cada vez — entregue-lhe a lista completa, para que consiga ver o panorama geral e tenha menos probabilidades de estragar uma coisa enquanto corrige outra.

Verificação 3: Pergunte à IA sobre segurança — aqui está um pedido#

Um botão avariado é imediatamente óbvio. Uma falha de segurança não: o projeto continua a funcionar como se nada se passasse até alguém tirar partido dela. Os problemas mais comuns nos projetos criados com vibe coding são chaves secretas escritas diretamente no código, uma base de dados exposta à Internet e formulários que permitem a alguém enviar dados maliciosos. A IA consegue encontrar tudo isto se lhe perguntar diretamente.

Audita este projeto à procura de problemas de segurança e explica cada descoberta em linguagem simples, sem jargão. Verifica esta lista:

Os segredos privados devem ser usados só no servidor, com configuração local como .env excluída do Git. .env e .gitignore não impedem variáveis frontend/públicas de entrar na compilação para o navegador. Inspeciona JavaScript, source maps, HTML e respostas de rede realmente entregues ao cliente e verifica a ausência de chaves privadas.

Verifica se a base de dados está exposta à Internet e quem tem acesso a ela.

Verifica se a entrada de dados pode comprometer os formulários: injeções nas consultas à base de dados ou código adicional nos campos de texto.

O que acontece se um utilizador enviar dados maliciosos?

Verifica se há páginas internas ou o painel de administração expostos sem palavra-passe.

Para cada item, diz se existe um problema, dá um exemplo claro do risco e explica como o corrigir. Começa pelo problema mais perigoso.

Verifique também se o seu projeto não faz cegamente tudo aquilo que recebe do exterior. Isto chama-se injeção indireta de prompt: um comando está escondido num e-mail, num comentário ou num ficheiro de outra pessoa, e o seu agente de IA segue-o, confundindo-o com uma tarefa. Se o projeto lê dados externos e age com base neles, pergunte à IA o que aconteceria se esses dados contivessem uma instrução oculta.

É um tema abrangente, e um único pedido não consegue cobri-lo completamente. Se o projeto processa dinheiro ou dados pessoais de clientes, leia o guia separado sobre segurança em vibe coding.

Verificação 4: A IA inventou bibliotecas ou dados?#

A IA escreve com confiança sobre coisas que não existem. Pode adicionar uma biblioteca com um nome plausível que, na realidade, não existe. Pode deixar marcadores de teste no projeto: um produto chamado «Exemplo», o endereço de e-mail example@example.com ou texto de preenchimento em vez de conteúdo real. É fácil não reparar numa demonstração, mas para um utilizador real é embaraçoso ou não funciona.

Pode detetar isto em dois passos. Primeiro, pergunte diretamente:

Percorre o projeto e verifica com honestidade:

Todas as ferramentas externas e bibliotecas que adicionaste existem mesmo e são instaladas corretamente? Inventaste alguma coisa?

Ainda há marcadores de teste, exemplos ou texto de preenchimento no lugar de dados reais?

As ligações, moradas e informações de contacto do projeto são reais, em vez de marcadores?

Enumera o que encontraste e sugere o que usar em substituição.

Em segundo lugar, basta executar o projeto e percorrê-lo. Uma biblioteca inventada quase sempre provoca um erro ao iniciar. E os marcadores são fáceis de detetar: se a página disser «Produto 1», ainda não os substituiu.

As bibliotecas inventadas representam um perigo específico, porque os atacantes registam deliberadamente ferramentas com os nomes que a IA gosta de inventar. Instale uma e o código de outra pessoa entra no seu projeto. Por isso, deve levar a sério a pergunta «esta biblioteca existe sequer?» — está diretamente relacionada com a segurança do seu projeto.

Verificação 5: Peça a outro modelo para verificar o primeiro#

A IA tem uma característica desagradável: concorda. Pergunte «está tudo bem aqui?» e confirmará que está tudo bem porque se adapta à resposta que espera. Isto chama-se bajulação da IA, e escrevi sobre o assunto separadamente. Um interlocutor assim será brando com o próprio trabalho.

A solução é simples: peça uma segunda opinião. Abra uma sessão nova ou use outro modelo e peça-lhe para verificar o projeto com o mesmo pedido da Verificação 3, acrescentando: «Este código foi escrito por outra IA; encontra os pontos fracos.» Um modelo novo não está preso à conversa anterior e tem mais probabilidades de assinalar problemas.

1. Abra uma sessão limpa ou use outro modelo

   Use um segundo modelo ou o mesmo modelo numa janela nova, sem histórico da tarefa.

2. Dê-lhe o projeto e explique-lhe o que pretende

   Diga claramente: «Este código foi escrito por outra IA; a tua tarefa é encontrar erros e riscos, não elogiá-lo.» Isto reduz a bajulação.

3. Compare as duas opiniões

   Se ambas concordarem, provavelmente têm razão. Se discordarem, investigue esse ponto — é aí que as coisas ficam interessantes.

É exatamente isto que está a acontecer atualmente no setor: a IA escreve, a IA verifica e a decisão final continua a pertencer a uma pessoa. Não pode delegá-la no modelo — é da sua responsabilidade.

Verificação 6: Como reverter uma alteração se algo correr mal?#

As verificações desta lista conduzem muitas vezes a alterações, e estas por vezes estragam o que estava a funcionar. Para evitar que isso se transforme num desastre, guarde a versão funcional no git antes de cada ronda de correções. É como guardar um jogo: se estragar alguma coisa, carrega o último ponto guardado.

Não precisa de ler código para fazer isto. Basta pedir à IA: «Guarda a versão funcional atual no git com uma etiqueta clara antes de alterares seja o que for.» E, se tudo correr mal depois das alterações: «Restaura o projeto para a versão guardada anteriormente.»

Se o git ainda lhe for desconhecido, tenho dois guias para si: como reverter alterações no Claude Code e o que fazer se a IA apagar a sua base de dados. O segundo é para quando já é demasiado tarde para reverter, mas ainda pode recuperar os dados.

Verificação 7: O que deve verificar por último antes de publicar?#

As primeiras seis verificações dizem respeito ao que o código faz. A sétima verifica se o projeto está pronto para chegar às pessoas. É aqui que as pessoas mais tropeçam: o projeto funciona, mas esqueceram-se de mudar os pagamentos da chave de teste para a chave real, e os primeiros clientes pagam «a fingir».

1. Pagamentos: de teste para real

   Se aceita pagamentos, confirme que está ligada a chave real do sistema de pagamentos, e não a chave de teste. Faça um pagamento real pelo valor mínimo e devolva-o a si próprio.

2. Os segredos estão onde devem estar

   Pergunte à IA: «As chaves privadas são usadas só no servidor e o .env está excluído do Git? A compilação real do navegador ou alguma resposta ao cliente contém chaves privadas, incluindo por variáveis frontend/públicas ou source maps?» Verifique os ficheiros compilados e as respostas de rede, não só o .env. A exclusão do Git não impede um valor de entrar no pacote frontend.

3. Faça uma cópia de segurança dos dados

   Confirme que a base de dados está a ser guardada automaticamente nalgum local. Se o seu projeto estiver num servidor próprio, explico o que fazer para publicar no guia do Coolify.

4. A publicação funciona fora do seu próprio dispositivo

   Abra o projeto no telemóvel através de uma ligação externa, não apenas no seu computador. Algo que funciona localmente nem sempre funciona depois de publicado.

Percorra os quatro pontos e poderá mostrar o projeto a outras pessoas com tranquilidade. Se algum não estiver certo, é melhor gastar meia hora agora do que lidar mais tarde com clientes insatisfeitos.

E se verificar demorar demasiado — deve simplesmente confiar na IA?#

Compreendo a tentação. Verificar parece aborrecido e «não foi para isso que arranjei IA». Mas é você, não o modelo, quem é responsável pelo resultado. A IA não tem reputação nem sofre consequências: produziu o código e esqueceu-se dele. Será você a responder ao cliente cujo pagamento não foi efetuado.

O criador do Claude Code tem uma visão ainda mais abrangente:

Escrever código deixou de ser o estrangulamento — a IA tratou disso. O valor está agora noutro lado: compreender a tarefa e verificar o resultado. Essa é a sua força — sabe melhor do que qualquer programador externo qual deve ser o resultado para o seu cliente.

Porque é que verificar é uma competência, e não uma tarefa pontual?#

Estas sete verificações são o mínimo que separa «lancei e espero que funcione» de «lancei e sei que funciona». Percorra-as uma vez e já conseguirá detetar a maioria das surpresas antes dos seus clientes.

A partir daí, torna-se um hábito. Dê à IA o contexto certo como entrada e verifique o resultado como saída. Cada novo projeto ficará pronto mais depressa, porque não estará a começar do zero.

Encontre materiais adicionais sobre trabalhar com ferramentas na documentação da Ailoot.