O primeiro dia de um app de vibe coding é a melhor demo que você já deu. O prompt funcionou, as telas estão limpas, o banco de dados tem registros e você postou um tweet com a gravação da tela. Já passamos por esse dia muitas vezes. Não estamos aqui para tirar isso de você.
Estamos aqui para falar sobre o segundo dia, porque ninguém menciona isso nos fios de lançamento. O segundo dia é quando um usuário real faz login, faz algo que você não pensou em testar e seu app encontra o abismo entre o “gerado” e o “projetado”.
Como é realmente o segundo dia
Raramente começa com um crash. Começa com algo estranho: um formulário que aceita lixo, uma página que quebra para um usuário específico, um número que está errado de uma forma que ninguém consegue reproduzir. Você cola o erro no chat. A IA corrige com confiança. A correção quebra outra coisa.
Bem-vindo ao “jogo de acertar a pinta” dos prompts. Como a IA corrige sintomas em vez de causas raízes, cada remendo é colocado sobre o anterior e a base de código silenciosamente se torna o que os desenvolvedores chamam de “código Frankenstein”: um mosaico de estilos conflitantes, funções duplicadas e lógica emaranhada, onde consultas de banco de dados vivem dentro do código de interface. À medida que o projeto cresce além da janela de contexto da IA, o modelo começa a esquecer suas próprias decisões anteriores e propõe códigos que as contradizem. Você não está mais mantendo um app. Você está negociando com um.
Existe uma variante ainda mais cruel: a falha silenciosa de deploy. Seu build de hospedagem falha por um erro menor, a URL ao vivo continua mostrando a versão antiga e você — não vendo mudança — diz à IA que a correção dela “não funcionou”. Então, ela gera uma solução completamente diferente e mais complexa para um problema que já havia sido resolvido. Várias rodadas depois, você tem uma v5 inflada de um código cuja v1 estava perfeita.
A parte que você não vê
A esteira de depuração é, pelo menos, visível. Os problemas de segurança não são, e é por isso que somos rigorosos com isso em builds de negócios.
As pesquisas nesta área são genuinamente alarmantes. Códigos gerados por LLMs compilam com sucesso em cerca de 90% das vezes, mas aproximadamente 45% deles contêm vulnerabilidades do OWASP Top 10 — como verificações de login contornáveis e falhas de injeção. As ferramentas de IA otimizam para que a demo funcione, o que gera atalhos previsíveis: controle de acesso implementado no navegador (onde qualquer usuário pode burlá-lo editando a página), permissões de banco de dados abertas para evitar erros durante o build e chaves de API hardcoded nos arquivos porque o construtor não sabe o que é uma variável de ambiente. Esses arquivos acabam sendo enviados para repositórios públicos no GitHub, onde scrapers de credenciais os encontram rapidamente.
O que torna isso especificamente um “problema do segundo dia” é que um app explorável roda perfeitamente. Não há mensagem de erro dizendo que “o cliente A tecnicamente consegue ler os registros do cliente B”. Você descobre isso por meio de um usuário, se tiver sorte, ou de forma muito pior, se não tiver. E o conselho padrão (“é só testar!”) colide com a realidade: construtores não técnicos testam o caminho feliz (happy path), enquanto a falha reside nos casos extremos — o bug de concorrência, o fluxo de recuperação de senha que a IA nunca gerou porque a demo não precisava de um.
A dívida de manutenção que ninguém contabiliza
Acumule essas mecânicas ao longo de meses e você terá o que consideramos como o “empréstimo predatório” da dívida técnica: software instantâneo agora, juros compostos depois. Cada atalho que a IA tomou é um conserto futuro. Cada conserto custa mais alguns créditos e gera um pouco mais de inchaço no código. Atualizações de plataforma são lançadas e quebram coisas que você nem tocou — construtores de longo prazo em plataformas prompt-to-app relatam que cobram taxas mensais de manutenção de clientes apenas para lidar com regressões da própria plataforma.
Aqui está a piada amarga no centro disso: o vibe coding prometeu democratizar o software e, para apps de produção, ele acabou democratizando a dívida técnica. O construtor não técnico acaba com exatamente aquilo que usou a IA para evitar — uma base de código que exige julgamento de um desenvolvedor — com a diferença de que agora ela sustenta o seu negócio e ele não consegue lê-la.
A bifurcação honesta
Então, o que fazer na prática? Após muitos builds e algumas cicatrizes, acreditamos que tudo se resume a uma bifurcação com dois caminhos honestos; o meio termo desonesto é a única resposta errada.
Caminho um: aprenda a manter o código. Se você gosta disso o suficiente para se aprofundar, o vibe coding se torna um acelerador legítimo em vez de uma armadilha. Leia o que o agente escreve. Entenda o que RLS significa antes de lançar um app que dependa disso. Evolua de ferramentas baseadas apenas em prompts para Cursor ou Replit, onde o código é a interface e você pode desenvolver um julgamento real. Este caminho é genuinamente ótimo — é apenas um caminho que exige meses de caminhada, e fingir que está nele enquanto entrega código não lido para clientes é a armadilha.
Caminho dois: coloque as partes perigosas em uma fundação que não seja gerada. Seja honesto ao admitir que seu app é uma ferramenta de negócios — um portal do cliente, um rastreador, um CRM interno — e perceba que 80% dele é exatamente a infraestrutura que a IA pior gera: autenticação, permissões, recuperação de senha, acesso a dados. Construa essa categoria em uma plataforma no-code como Softr, onde a infraestrutura é testada e configurada visualmente, e o AI Co-Builder ainda te entrega a velocidade do primeiro dia. Quando quiser um toque personalizado, o bloco de vibe-coding delimita o código gerado a um único componente, para que a IA possa decorar a casa sem derrubar o telhado. O “segundo dia” neste caminho é uma edição, não uma escavação arqueológica — é por isso que ele lidera nosso ranking de portais do cliente.
Continue usando vibe coding para as coisas divertidas sem medo — protótipos, brinquedos e experimentos de fim de semana são exatamente aquilo em que essas ferramentas são brilhantes. Apenas decida, antes que usuários reais apareçam, em qual lado da bifurcação você está. O segundo dia não pede licença.