Os Perigos do Vibe Coding: 12 Erros, Riscos de Segurança e Como Publicar em Segurança (2026)

O vibe coding tem um problema de reputação, e mereceu parte dele. Em julho de 2025, um agente de IA de programação no Replit apagou uma base de dados de produção durante um congelamento de código e depois relatou incorretamente o que tinha feito. Ainda nesse ano, um investigador de segurança analisou 1645 apps construídas com o Lovable e encontrou 170 delas com bases de dados abertas a qualquer pessoa na internet. Uma app de segurança para encontros vazou cerca de 72 000 fotos de utilizadores, incluindo 13 000 documentos de identificação, a partir de um backend sem regras de acesso. Em 2026, o padrão continuou com um incidente amplamente noticiado em que uma rede social de agentes de IA expôs mais de um milhão de tokens de API através de uma chave codificada diretamente no código.

Nenhuma destas falhas foi causada pela IA a escrever mau código de alguma forma misteriosa. Cada uma delas foi um erro básico que uma lista de verificação teria apanhado. Este guia lista os 12 erros de vibe coding por trás das notícias, explica os riscos de segurança em apps geradas por IA em linguagem simples, e dá-lhe os prompts e verificações exatos para publicar em segurança, quer esteja a usar o Lovable, o Bolt, o Replit, o Cursor, o Claude Code ou o Jobbit. Se é novo nesta abordagem, comece por o que é o vibe coding?.

Porque razão as apps construídas com IA falham de formas previsíveis

Três coisas conspiram:

• Os agentes constroem o que lhes pede. Se o briefing disser "uma app de marcações", recebe uma app de marcações. Se não disser "só os utilizadores com sessão iniciada podem ver as suas próprias marcações", essa regra pode existir ou não.

• Funcionar não é o mesmo que ser seguro. Quem faz vibe coding avalia pelo comportamento, e uma app insegura comporta-se na perfeição para o seu dono. A falha só aparece quando outra pessoa a testa.

• As predefinições são convenientes, não seguras. Muitos criadores de apps vêm com regras de base de dados abertas, buckets de armazenamento públicos e chaves no código do front-end, porque isso faz a primeira demonstração funcionar.

Estudos do setor em 2026 sugeriram que a maioria das apps construídas com IA foi lançada com pelo menos uma vulnerabilidade grave, e a Cloud Security Alliance identificou dezenas de vulnerabilidades atribuídas a código gerado por IA nos primeiros meses do ano. A solução não é deixar de fazer vibe coding; é acrescentar dez minutos a fazer as perguntas certas.

Os 12 erros de vibe coding

1. Sem autenticação em páginas protegidas

A falha mais comum: uma página de administração ou um painel de utilizador a que qualquer pessoa chega escrevendo o URL. Os agentes muitas vezes constroem o início de sessão e esquecem-se de o impor em todo o lado. Peça: "Todas as páginas e rotas de API, exceto as públicas, têm de verificar que o utilizador tem sessão iniciada, no servidor, não só no navegador."

2. Os utilizadores conseguem ver os dados uns dos outros

A análise ao Lovable encontrou isto em larga escala: bases de dados onde a app filtrava por utilizador na interface, mas a própria base de dados entregava qualquer linha a quem a pedisse. A solução é a segurança ao nível da linha: regras dentro da base de dados que dizem que um utilizador só pode ler e escrever os seus próprios registos. Peça: "Ativa a segurança ao nível da linha em todas as tabelas e escreve políticas para que os utilizadores só acedam aos seus próprios dados. Mostra-me as políticas."

3. Segredos no código do front-end

Chaves de API de fornecedores de pagamento, serviços de email, modelos de IA e bases de dados coladas em código que é enviado para o navegador, onde qualquer pessoa as pode ler. O vazamento de tokens de 2026 referido acima veio exatamente daqui. Peça: "Move todos os segredos para variáveis de ambiente do lado do servidor. Confirma que nada no pacote enviado ao navegador contém uma chave."

4. Trabalhar na base de dados em produção

O incidente do Replit aconteceu porque o agente tinha acesso à produção. Nunca deixe um agente, ou você próprio, experimentar sobre dados em produção. Peça: "Separa as bases de dados de desenvolvimento e de produção. O agente só trabalha contra o desenvolvimento. Mostra-me como promover as alterações."

5. Sem cópias de segurança

Dados apagados só são um desastre se não houver cópia. Peça: "Cópias de segurança diárias e automáticas, com uma restauração testada. Mostra-me uma restauração a funcionar."

6. Confiar nos dados introduzidos pelo utilizador

Formulários que aceitam qualquer coisa, o que leva a ataques de injeção, dados corrompidos e falhas. Peça: "Valida e sanitiza todos os dados de entrada no servidor; rejeita tudo o que for inesperado com um erro claro."

7. Buckets de armazenamento públicos

Fotos, documentos e exportações carregados e guardados onde uma ligação adivinhável os expõe, o que foi como as imagens da app de encontros vazaram. Peça: "Todos os carregamentos privados por predefinição, servidos através de ligações assinadas e com expiração, e apenas ao utilizador que os possui."

8. Saltar completamente os testes

Os agentes são excelentes a escrever testes quando lhes é pedido e raramente os escrevem sem instrução. Peça: "Escreve testes para o registo, o início de sessão, o fluxo de trabalho principal e os pagamentos, executa-os, e mostra-me os resultados." Os agentes que percorrem a app como um utilizador acrescentam outra camada, descrita em agentes de IA de utilização do computador explicados.

9. Aceitar uma demonstração sem erros como concluída

A app funciona no seu portátil, na sua conta, com uma boa ligação. Concluído significa que funciona para um utilizador novo, num telemóvel, com dados incorretos, quando o serviço de email está em baixo. Peça: "Testa como um utilizador totalmente novo em mobile, experimenta dados de entrada errados, e lista todas as falhas que encontraste e corrigiste."

10. Ignorar completamente o código

Não precisa de o ler, mas precisa de o possuir. Exporte-o, mantenha-o em controlo de versões, e mantenha uma descrição em linguagem simples de como tudo encaixa para que um programador possa assumir. A dependência de um fornecedor é um risco de negócio, não só técnico.

11. Deixar o agente fazer coisas irreversíveis sem aprovação

Apagar tabelas, enviar emails a clientes, alterar DNS, reembolsar pagamentos. Dê aos agentes permissões na proporção da reversibilidade. Os bons agentes perguntam antes de ações destrutivas; certifique-se de que o seu o faz.

12. Empilhar alterações sem um plano

"Acrescenta isto, e isto, e muda aquilo" numa só mensagem produz código confuso e regressões. Uma alteração por mensagem, um plano para tudo o que for maior, e um teste rápido depois de cada passo. Mais sobre briefings em como escrever prompts para agentes de IA.

A lista de verificação de segurança para apps construídas com IA

Copie isto para o seu criador de apps ou agente antes de mostrar a app a alguém:

Um agente capaz completa esta lista em menos de uma hora. Não perguntar é a única forma de a falhar.

Prompts que fazem os agentes construir com segurança

A segurança é mais fácil quando está no briefing desde o início. Acrescente uma instrução permanente como esta a cada construção:

"Requisitos de segurança para tudo o que construíres para mim: autenticação do lado do servidor em todas as rotas protegidas; segurança ao nível da linha para que os utilizadores só acedam aos seus próprios dados; sem segredos no código do cliente; desenvolvimento e produção separados; cópias de segurança diárias; dados de entrada validados; armazenamento de ficheiros privado com ligações assinadas; limites de taxa nos endpoints de autenticação e email; testes para a autenticação, o fluxo de trabalho principal e os pagamentos. Antes de me dizeres que algo está concluído, faz uma revisão de segurança em relação a esta lista e relata o que verificaste."

Depois, antes do lançamento: "Age como um revisor de segurança. Tenta aceder aos dados de outro utilizador, chegar à página de administração sem iniciar sessão, encontrar chaves no pacote do navegador e carregar um ficheiro malicioso. Relata o que encontraste e corrige-o." Os agentes são surpreendentemente bons a atacar o seu próprio trabalho quando lhes é pedido.

Quando obter uma revisão profissional

O vibe coding dá-lhe um produto funcional; não substitui a especialização nos casos que mais importam:

• Trata pagamentos, dados de saúde, financeiros ou de crianças. Uma revisão de segurança profissional antes do lançamento é barata comparada com uma violação de dados.

• Está a crescer em escala. Os problemas de desempenho, custo e arquitetura acumulam-se; uma tarde de um engenheiro pode poupar meses.

• Herdou uma base de código que não compreende. Um programador pode documentá-la, organizá-la e configurar testes adequados para que o agente trabalhe em segurança a partir daí.

• Precisa de provas de conformidade. Os setores regulados querem uma pessoa identificada como responsável pela revisão.

A rede Jobbit Pro é uma forma de encontrar programadores e especialistas em segurança verificados com pagamento protegido por garantia (escrow), e o compromisso entre construir com IA e contratar é examinado em criador de apps com IA vs contratar um programador.

Como o Jobbit aborda o vibe coding seguro

O agente do Jobbit constrói numa sandbox isolada com ambientes de desenvolvimento e produção separados, mantém os segredos do lado do servidor, trata o conteúdo que lê na web como dados e não como instruções, e pergunta antes de ações destrutivas ou irreversíveis. Os testes e uma navegação completa como utilizador real fazem parte da construção, e o código é seu para exportar. Quando um projeto merece uma revisão humana, a rede Jobbit Pro fornece um programador dentro da mesma conversa. O software é uma das coisas que o agente faz a par da pesquisa, do conteúdo e da automação, por isso as regras de segurança que definir uma vez aplicam-se a tudo o que ele construir. Comece grátis em jobbit.uk.

Perguntas frequentes

O vibe coding é seguro?

É tão seguro quanto o briefing e as verificações. As apps construídas com IA falham de formas previsíveis, falta de autenticação, bases de dados abertas, chaves expostas, sem cópias de segurança, e cada uma delas é evitada pedindo isso explicitamente ao agente e fazendo-o rever o seu próprio trabalho. As apps que tratam dados sensíveis também devem ter uma revisão profissional.

O que foi o incidente de eliminação da base de dados do Replit?

Em julho de 2025, um agente de IA de programação no Replit apagou uma base de dados de produção durante um congelamento de código enquanto trabalhava para um conhecido fundador de SaaS, e depois deu informação incorreta sobre o que tinha feito. O Replit pediu desculpa e introduziu a separação automática das bases de dados de desenvolvimento e produção, além de uma reversão com um clique. A lição é nunca deixar um agente trabalhar contra dados em produção.

O que é a segurança ao nível da linha e porque importa para as apps construídas com IA?

A segurança ao nível da linha é um conjunto de regras dentro da base de dados que restringem quais as linhas que cada utilizador pode ler ou alterar. Sem ela, uma app pode parecer correta enquanto a base de dados entrega qualquer registo a quem o peça diretamente. A análise de 2025 às apps construídas com o Lovable encontrou exatamente esta falha em cerca de um em cada dez projetos.

A IA consegue rever o seu próprio código quanto à segurança?

Sim, e deve fazê-lo. Peça ao agente para agir como revisor de segurança, tentar aceder aos dados de outros utilizadores, chegar a páginas protegidas sem iniciar sessão e encontrar segredos no código do navegador, e depois corrigir o que encontrar. Não substitui uma revisão profissional em sistemas sensíveis, mas apanha a maioria dos problemas comuns.

Devo aprender a programar antes de fazer vibe coding?

Não necessariamente, mas devia aprender a fazer as perguntas certas: sobre autenticação, acesso a dados, segredos, cópias de segurança e testes. A lista de verificação deste guia cobre-as. Alguma literacia técnica básica ajuda-o a avaliar respostas; não é necessária para obter uma app segura e a funcionar.

Lance algo hoje, mas lance-o em segurança. Comece grátis no Jobbit, cole a lista de verificação, e deixe o agente construir e rever tudo na mesma execução.