--- title: "O Problema do Segundo Dia: Quando Seu App de Vibe Coding Encontra Usuários Reais" description: "O primeiro dia do vibe coding é a demo. O segundo são usuários reais, falhas de segurança e dívida de manutenção. O que realmente quebra e as duas formas honestas de resolver." date: 2026-06-10 language: pt canonical: https://best-vibe-coding-tools.com/pt/posts/the-day-two-problem source: "Best Vibe Coding Tools posts" --- O primeiro dia de um app feito com vibe coding é a melhor demo que você já deu. O prompt funcionou, as telas estão limpas, o banco de dados tem linhas 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 nenhum thread de lançamento fala sobre isso. O segundo dia é quando um usuário real faz login, faz algo que você não pensou em testar e seu app encontra a lacuna entre o "gerado" e o "projetado". ## Como é, na verdade, 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 um jeito que ninguém consegue reproduzir. Você cola o erro no chat. A AI corrige com confiança. A correção quebra outra coisa. Bem-vindo ao jogo de whack-a-mole dos prompts. Como a AI corrige sintomas em vez de causas raiz, cada remendo é colocado sobre o anterior, e a base de código silenciosamente se torna o que os builders chamam de código Frankenstein: um retalho 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 AI, 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. O build da sua hospedagem falha por um erro irrelevante, a URL pública continua exibindo a versão antiga e você - não vendo mudança - diz à AI que a correção "não funcionou". Então ela gera uma solução completamente diferente e mais complexa para um problema que já estava resolvido. Várias rodadas depois, você tem uma v5 de código inflada, sendo que a v1 estava ótima. Cada correção rápida pode deslocar o problema em vez de resolvê-lo. ## A parte que você não vê A esteira de debugging é, 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. A pesquisa aqui é genuinamente desconfortável. Códigos gerados por LLM compilam com sucesso cerca de 90% das vezes, mas aproximadamente 45% deles contêm vulnerabilidades do OWASP Top 10, como verificações de login ignoráveis e falhas de injeção. Ferramentas de AI otimizam para que a demo funcione, o que produz 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 que nada dê erro durante o build, e chaves de API hardcoded em arquivos porque o builder não sabe o que é uma variável de ambiente. Esses arquivos são então enviados para repositórios públicos do GitHub, onde scrapers de credenciais os encontram pontualmente. Aqui está o que torna isso especificamente um problema do segundo dia: um app explorável funciona perfeitamente. Não há mensagem de erro para "o cliente A pode tecnicamente ler os registros do cliente B". Você descobre através de um usuário, se tiver sorte, ou de forma muito pior se não tiver. E o conselho padrão ("apenas teste!") colide com a realidade: builders não técnicos testam o caminho feliz, enquanto a falha reside nos casos extremos, o bug de concorrência, o fluxo de redefinição de senha esquecido que a AI nunca gerou porque a demo não precisava de um. A demo pode funcionar enquanto atalhos previsíveis deixam o app exposto. ## A dívida de manutenção que ninguém detalha 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 AI tomou é uma correção futura. Cada correção são mais alguns créditos e um pouco mais de inchaço de código. Atualizações de plataforma chegam e quebram coisas que você não tocou, builders de longo prazo em plataformas de prompt-to-app relatam cobrar taxas de manutenção mensais de clientes apenas para lidar com regressões da própria plataforma. Esta é a piada amarga no centro de tudo: o vibe coding prometeu democratizar o software e, para apps de produção, ele democratizou principalmente a dívida técnica. O builder não técnico acaba segurando exatamente aquilo que usou a AI para evitar, uma base de código que exige o julgamento de um desenvolvedor, exceto que agora ela é o pilar do seu negócio e ele não consegue lê-la. ## A bifurcação honesta Então, o que você faz na prática? Depois de muitos builds e algumas cicatrizes, achamos que tudo se resume a uma bifurcação com dois caminhos honestos, e o meio desonesto é a única resposta errada. **Caminho um: aprenda a manter código.** Se você ama isso 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. Aprenda o que RLS significa antes de lançar um app que dependa disso. Evolua de ferramentas apenas de prompt para [Cursor](/pt/reviews/cursor) ou [Replit](/pt/reviews/replit), onde o código é a interface e você pode desenvolver um julgamento real. Este caminho é genuinamente ótimo, é apenas um caminho, com meses de caminhada, e fingir que você 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 que seu app é uma ferramenta de negócios, um portal do cliente, um rastreador, um CRM interno, e perceba que 80% dele é exatamente a encanamento que a AI pior gera: auth, permissões, redefinições de senha, acesso a dados. Construa essa categoria em uma plataforma no-code como [Softr](/pt/reviews/softr), onde o encanamento é uma infraestrutura testada que você configura visualmente, e o AI Co-Builder ainda te dá a velocidade do primeiro dia. Quando você quiser um toque personalizado, seu bloco de vibe-coding limita o código gerado a um único componente, para que a AI 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 de clientes](/pt/rankings/best-vibe-coding-tools-for-client-portals). Continue fazendo vibe coding nas coisas divertidas com entusiasmo, 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. Antes que os usuários reais cheguem, temos dois caminhos honestos para escolher.