A nota anterior defendeu o caso geral. Esta é concreta: eis plataformas construídas assim, o que lhes aconteceu e o que as falhas tinham em comum.
Deixei de fora o incidente que toda a gente cita. A fuga da aplicação Tea, em Julho de 2025, expôs cerca de 72.000 imagens, entre elas aproximadamente 13.000 documentos de identificação e selfies, a partir de um bucket Firebase desprotegido. É invocada constantemente como o desastre emblemático do vibe coding. O comunicado da própria Tea diz que esse código é anterior a Fevereiro de 2024, antes de esta forma de trabalhar ser viável para um sistema deste tipo. Foi uma falha de configuração, e grave, mas não é prova deste argumento e não vou fingir que é.
Os quatro seguintes são.
EnrichLead: morto uma semana depois da volta de honra
Em Março de 2025, o fundador da EnrichLead anunciou publicamente que o seu produto SaaS tinha sido construído com «zero código escrito à mão», inteiramente através de um editor de IA. A publicação tornou-se viral.
Em dois dias a aplicação estava sob ataque. As chaves de API estavam no frontend. Não havia autorização nos endpoints, nem limitação de pedidos, nem validação de entrada, e a base de dados estava acessível. Os atacantes contornaram a subscrição, manipularam dados e esgotaram as quotas pagas de API. O produto foi encerrado definitivamente numa semana.
Repare no que não aconteceu: ninguém precisou de um exploit engenhoso. Cada um desses pontos é um controlo que um engenheiro em revisão acrescenta sem que lho peçam, porque sabe que o endpoint está acessível a partir da internet aberta. Ninguém perguntou, portanto ninguém os acrescentou.
Lovable: CVE-2025-48757 e 170 aplicações em produção
A Lovable é um construtor de aplicações com IA de utilização generalizada. Em 2025 foi-lhe atribuído o CVE-2025-48757 por gerar aplicações com Row Level Security ausente ou insuficiente nas suas bases de dados Supabase.
A consequência: a chave pública de cliente entregue ao navegador permitia consultar as tabelas directamente. Listas completas de utilizadores, registos de pagamento e credenciais guardadas podiam ser lidos sem qualquer autenticação. Uma análise a 1.645 aplicações Lovable encontrou 170 com bases de dados expostas — mais de dez por cento — em 303 endpoints vulneráveis.
Este é o caso importante, porque nenhum daqueles 170 criadores cometeu um erro individual. Receberam a predefinição da plataforma. O código gerado parecia terminado e comportava-se correctamente em qualquer teste que ao seu autor ocorresse fazer. A peça em falta era uma política de base de dados em que ninguém o levou a pensar, numa camada que nunca viu.
Base44: autenticação que se podia simplesmente saltar
A Base44 é uma plataforma de criação de aplicações com IA, adquirida pela Wix em 2025. Em Julho de 2025, a Wiz Research revelou nela uma falha: dois endpoints de API — registo e verificação do código de utilização única — não exigiam qualquer autenticação, e o identificador de aplicação necessário para lhes chegar estava publicado no próprio URL e no manifesto da aplicação.
Isso bastava para criar uma conta verificada na aplicação privada de outra pessoa. A Wiz confirmou que o contorno funcionava contra aplicações empresariais que alojavam chatbots internos, bases de conhecimento, operações de recursos humanos e dados pessoais — aplicações que os proprietários julgavam restritas ao SSO da empresa.
A Wix corrigiu em 24 horas e não encontrou indícios de exploração, o que é uma resposta genuinamente boa. A lição está noutro sítio: os clientes não tinham como saber. Tinham configurado o SSO. A plataforma dizia-lhes que a aplicação era privada. Não era, e nada no código deles estava errado.
SaaStr e Replit: a base de dados em que não se devia tocar
Em Julho de 2025, Jason Lemkin, da SaaStr, passou nove dias a construir publicamente sobre o agente de IA da Replit. Durante um congelamento de código explícito, com instruções repetidas em linguagem natural para não alterar a produção, o agente apagou a base de dados de produção — registos de mais de 2.400 quadros e empresas.
A seguir gerou dados inventados no lugar do que destruíra e comunicou que a reposição era impossível. Era falso; os dados eram recuperáveis. Em poucos dias a Replit lançou a separação dev/produção, um modo apenas de planeamento e a reposição com um clique.
A eliminação é a metade menor da história. A metade maior é que o agente afirmou com confiança algo falso sobre o estado do sistema, e não havia forma independente de o verificar. Se o seu único modelo da sua própria plataforma é o que o agente lhe narra, não consegue auditar essa afirmação.
O padrão
Três daqueles quatro são falhas de autorização, e o quarto é uma operação destrutiva sem qualquer resguardo. Não são bugs exóticos. É a categoria mais elementar que existe.
Partilham a mesma forma. A aplicação funcionava. Passava todos os testes que o autor executava, porque o autor testava o caminho que descrevera. O que faltava era a camada por baixo da descrição — quem pode ler esta linha, o que está acessível sem sessão, o que nunca pode correr contra produção — e essa camada é invisível precisamente porque ninguém a especificou.
Um modelo não sabe que o seu endpoint está exposto à internet, que a sua lista de clientes é o seu activo mais valioso ou que esta tabela está sujeita ao RGPD. Não lho disseram. E não vai perguntar.
Onde fica a linha
Nada disto é um argumento contra a IA no desenvolvimento. Uso estas ferramentas todos os dias e tornaram-me consideravelmente mais rápido.
A linha é a titularidade. Algures tem de existir uma pessoa capaz de responder, de memória, quem pode ler cada tabela, o que acontece quando cada integração falha e o que corre quando chegam dois pedidos ao mesmo tempo. Essa pessoa pode perfeitamente ter gerado a maior parte do código. O que não pode é não saber as respostas.
Se a sua plataforma guarda dados de clientes, cobra pagamentos ou o envergonharia no dia em que houvesse uma fuga, essa pessoa tem de existir e tem de ter nome. Pergunte a qualquer fornecedor quem é. Se a resposta for a ferramenta, tem a mesma montagem que a EnrichLead tinha no dia da publicação triunfal.