Quando o app feito com IA começa a quebrar

Alguém viu um anúncio, descreveu uma ideia em português e, em uma tarde, tinha um sistema no ar. Cadastro de clientes, controle de pedidos, um painel. Funcionou por semanas. Depois veio o primeiro bug. A correção trouxe outro. Uma funcionalidade nova não sai de jeito nenhum, e ninguém sabe dizer se os dados dos clientes estão protegidos ou onde, exatamente, aquilo está rodando.

Este texto registra o que os levantamentos públicos de 2025 dizem sobre apps feitos com IA por pessoas sem formação técnica, quais sintomas se repetem e por onde começar a arrumar. É o primeiro de uma série. Os dados citados são de relatórios e relatos abertos. Os dois casos vistos de perto vêm de trabalhos nossos.

Resumo

• Os sintomas se repetem: bug atrás de bug, qualquer mudança quebra tudo, sem versionamento, sem saber se está seguro, sem saber colocar no ar.
• Em outubro de 2025, uma varredura da Escape em mais de 5.600 apps públicos feitos em plataformas de IA achou mais de 2.000 vulnerabilidades.
• Em julho de 2025, um teste da Veracode com mais de 100 modelos de IA mostrou que o código gerado escolheu a opção insegura em 45% das tarefas.
• Na pesquisa do Stack Overflow de 2025, 46% dos desenvolvedores disseram não confiar na precisão do que a IA produz, e 66% apontaram respostas “quase certas” como o problema principal.
• Os problemas mudam conforme a ferramenta: plataforma no navegador, agente no computador ou código colado de um chat. Cada um tem um post nesta série.
• O caminho é o mesmo em todos: diagnosticar antes de editar, travar o que funciona, corrigir uma coisa por vez. Na nossa avaliação, refazer do zero raramente compensa.

Os sintomas

Os relatos públicos, de fóruns a boletins de segurança, descrevem, com frequência, a mesma lista. Em geral os sintomas chegam juntos.

Bug atrás de bug. A pessoa pede uma correção, a IA mexe em dez arquivos, e algo que funcionava para de funcionar. A próxima correção repete o ciclo. Sem testes automatizados, ninguém sabe o que a mudança afetou até um usuário reclamar.

Qualquer alteração quebra tudo. É o mesmo sintoma visto de outro ângulo. O código gerado em uma única conversa longa tende a ter funções que dependem umas das outras de formas que ninguém mapeou, porque ninguém leu.

Sem versionamento. Não há histórico. A versão que funcionava na terça não existe mais depois da mudança de quarta. Quem usa o Git, o sistema de controle de versões que a documentação do GitHub explica para iniciantes, tem cada estado guardado com data e descrição. Quem não usa só tem o estado atual.

Sem saber se está seguro. O app pede login, então parece protegido. Mas o banco pode estar acessível a quem souber o endereço, as chaves de serviços pagos podem estar no código que o navegador baixa, e dados de um cliente podem aparecer para outro ao trocar um número na URL. Um caso que vimos: um site com um endereço de recibos numerados em sequência. Trocando o número, qualquer pessoa abria o recibo de qualquer cliente, sem estar logada. A tela de login protegia a tela, não o dado.

Sem saber colocar no ar, ou tirar. A plataforma hospeda, e a pessoa não sabe o que acontece se parar de pagar, como levar o app para outro lugar ou como fazer uma cópia do banco.

Uma funcionalidade que não sai. Integrar pagamento, enviar e-mail, importar uma planilha. A IA tenta, quebra outra coisa, tenta de novo. Um relato em português no TabNews, de um engenheiro civil, conta mais de 5.000 créditos da Manus gastos em semanas num mapa interativo que nunca chegou a funcionar.

O que os números dizem

Os sintomas não são impressão de quem está frustrado. Há medições.

Vulnerabilidades em escala. Em outubro de 2025, a empresa de segurança Escape publicou a metodologia de uma varredura em mais de 5.600 aplicações públicas feitas em plataformas de criação por IA, cerca de 4.000 delas na Lovable. Resultado: mais de 2.000 vulnerabilidades, mais de 400 segredos expostos e 175 casos de dados pessoais acessíveis, incluindo registros médicos e dados bancários. Os apps funcionavam. O problema não aparecia na tela.

O código gerado escolhe o caminho inseguro. Em julho de 2025, a Veracode publicou um teste com 80 tarefas de programação em mais de 100 modelos de IA. Quando havia um jeito seguro e um inseguro de resolver a tarefa, o modelo escolheu o inseguro em 45% dos casos. A taxa não melhorou com modelos mais novos, embora o código sintaticamente correto tenha melhorado. É um estudo de uma empresa que vende ferramentas de segurança, com tarefas escolhidas por ela, mas o resultado é coerente, na nossa leitura, com o que a varredura da Escape achou em apps publicados.

Quem programa também desconfia. A pesquisa anual do Stack Overflow de 2025, com cerca de 49 mil respostas, mostra que 84% dos desenvolvedores usam ou planejam usar IA, mas 46% não confiam na precisão do que ela produz. O problema mais citado, por 66%, foi a resposta “quase certa, mas não exatamente”. Quem sabe programar percebe o quase. Quem não sabe só percebe quando quebra.

Mais rápido nem sempre. Em julho de 2025, a METR publicou um experimento controlado com 16 desenvolvedores experientes e 246 tarefas reais. Com IA, levaram 19% mais tempo, e ainda assim acharam que tinham sido 20% mais rápidos. A amostra é pequena e os autores pedem cautela, mas o resultado explica uma sensação comum: o progresso parece grande enquanto se conversa com a IA, e pequeno quando se olha o que ficou pronto.

Incidentes com nome. Em maio de 2025, o NVD, o banco de vulnerabilidades do governo americano, registrou uma falha em apps gerados pela Lovable: tabelas de banco sem a proteção por linha, legíveis e graváveis por qualquer pessoa sem login. A Lovable contesta o registro, dizendo que cada cliente é responsável pelos próprios dados. Em julho de 2025, a Wiz encontrou na Base44 uma falha de autenticação que dava acesso a apps privados com um identificador público. Foi corrigida em 24 horas. No mesmo mês, o registro de incidentes da OCDE documentou um agente da Replit que apagou um banco de dados em uso durante um teste, contra a instrução explícita do usuário. A Replit respondeu separando bancos de desenvolvimento e produção.

Nenhum desses casos é exclusivo de uma plataforma. São o mesmo problema: código e configuração que ninguém revisou, em produção, com dados de gente.

E não é exclusivo de quem não programa. Um caso que vimos era de um programador que trabalhava sozinho: o app baixava a coleção inteira do banco para o navegador de cada usuário, o que expunha os dados de todos e gerou uma conta de leituras que ele só notou quando cresceu. Saber programar não substitui olhar. A diferença é que quem sabe tem como olhar.

Três situações, três posts

O que fazer depende de como o app foi feito. Nesta série, separamos três situações.

Plataforma no navegador. Lovable, Bolt, Base44, Replit, v0. A pessoa nunca viu o código. Paga em créditos, hospeda na plataforma, usa o banco que a plataforma criou. O problema central é a dependência: não sabe o que custa, não sabe sair, não sabe o que está exposto.

Agente no computador. Cursor, Claude Code, Codex, Windsurf. O código está na máquina da pessoa, o que já é meio caminho. Falta método: sem Git, sem testes, conversas de horas num só chat, “aplicar tudo” sem ler. O problema central é organização.

Código colado de um chat. ChatGPT ou Gemini no navegador, e o código vai para uma planilha, um site em WordPress, um fluxo de automação, um script que roda no notebook de alguém. Não há projeto. O problema central é juntar o que está espalhado antes de qualquer outra coisa.

Por onde começar, em qualquer caso

A ordem é a mesma nos três.

1. Diagnosticar antes de editar. Listar o que existe: telas, rotas, tabelas, integrações, onde está hospedado, quem tem acesso. Pedir à IA que “conserte” antes disso é mais uma mudança sem controle.
2. Versionar o estado atual. Antes de qualquer alteração, o código vai para um repositório Git. É o ponto de retorno. O livro do Git em português é gratuito e os dois primeiros capítulos bastam para entender o que isso significa.
3. Travar o que funciona. Testes que registram o comportamento atual das partes que estão certas. Daí em diante, qualquer mudança que quebrar algo avisa na hora, e não pelo cliente. Rodar esses testes a cada commit, de forma automática, é o que mostramos no post sobre o build do Tauri no GitHub Actions.
4. Olhar a segurança com lista. O OWASP Top 10 é a lista pública das dez categorias de falha mais comuns em aplicações web. Controle de acesso quebrado é a primeira da lista, e é o tipo de falha dos incidentes citados acima: a tabela sem RLS, o acesso indevido na Base44 e os recibos abertos.
5. Corrigir uma coisa por vez, com o teste rodando a cada passo. Se quebrou, volta. Se passou, guarda.
6. Só depois, decidir o que muda de lugar. Sair da plataforma, trocar o banco, simplificar. Com o app travado e versionado, essa decisão fica barata. Antes, é um salto no escuro.

Refazer do zero é a tentação quando o diagnóstico assusta. Na nossa experiência, costuma ser um erro: joga fora o que já está certo, repete os mesmos problemas com a mesma ferramenta e não deixa nada aprendido. A exceção é quando o diagnóstico mostra que a solução inteira era maior do que o problema, e uma planilha ou um formulário resolvem. Isso acontece, e é bom quando acontece.

O que isto não resolve

Nada acima torna o app bom. Torna o app conhecido, versionado e testado, que é o que permite melhorá-lo sem medo. Também não substitui alguém que leia o código: a IA que gerou os problemas não vai achar todos eles sozinha.

Como verificamos

Este post é um levantamento de fontes públicas, não uma medição nossa. As fontes foram consultadas em 16 de outubro de 2026: a metodologia da Escape de outubro de 2025, o comunicado da Veracode de 30 de julho de 2025, a pesquisa do Stack Overflow de 2025, o estudo da METR de 10 de julho de 2025, o registro CVE-2025-48757 no NVD, a cobertura do The Hacker News sobre a Base44 e o registro de incidentes da OCDE sobre a Replit. Números que só encontramos em páginas de empresas que vendem serviços de correção ficaram de fora. Os casos apresentados como vistos de perto, o dos recibos e o do app em Firebase, são de trabalhos nossos. Não medimos nenhum app de terceiros para este texto. A VirtuaIRES não tem vínculo com nenhuma das plataformas ou empresas citadas.

Um exemplo do que uma IA pode fazer com segurança quando o acesso aos dados é desenhado antes está no post sobre perguntar ao ChatGPT sobre os dados do sistema. Organizar e completar um sistema que começou com IA é parte do que fazemos em soluções com IA.