Toda demo de vibe coding é uma história de Primeiro Dia. Um prompt, um app funcionando, uma tela que parece pronta para o lançamento. O problema é que o software não vive no Primeiro Dia. Ele vive no Segundo Dia, quando usuários reais fazem login, os dados deixam de ser amostras e alguém precisa alterar algo sem quebrar todo o resto. É nesse dia que a demo e o produto revelam-se objetos diferentes.
Por que o Segundo Dia é uma máquina diferente
No Primeiro Dia, pede-se ao modelo que escreva em uma tela em branco, algo em que ele é ótimo. No Segundo Dia, pede-se que ele modifique um sistema que ele lembra apenas parcialmente, algo em que ele não é bom. O vibe coding ainda é uma camada de abstração, não uma fuga do desenvolvimento de software: você não está digitando sintaxe, mas ainda está gerenciando estados, desenhando esquemas relacionais e lidando com casos extremos, porque a IA transferiu essa complexidade para você em vez de eliminá-la.
O artefato se degrada à medida que cresce. Quando a base de código excede a janela de contexto do modelo, ele começa a esquecer suas próprias decisões estruturais e a propor códigos que contradizem padrões anteriores. O contexto limitado também significa que ele reescreve funções utilitárias que não consegue ver no momento, deixando lógicas duplicadas espalhadas pelo projeto. Modelos treinados em datas de corte diferentes escrevem para versões conflitantes das mesmas bibliotecas, introduzindo a deriva de versão. O que resta é o código Frankenstein: um retalho de estilos onde a lógica de interface, as queries de banco de dados e as regras de negócio estão emaranhadas em arquivos que ninguém planejou, e cada edição posterior precisa navegar por todo esse caos.
As falhas não avisam quando chegam
Um crash é honesto; ele avisa que algo está errado. As falhas do Segundo Dia que realmente machucam são as silenciosas. A IA constrói o caminho de sucesso específico descrito no prompt e ignora os casos que ninguém demonstra: edições simultâneas de dois usuários, um formulário que perde a conexão no meio do envio, um botão clicado duas vezes, um input com formato errado. Um pequeno erro de arredondamento ou cálculo roda tranquilamente em cada transação e aparece meses depois em um relatório de faturamento ou em uma contagem de reservas que não bate mais.
O gap de confiança é o que torna isso perigoso em vez de apenas irritante. Um operador não técnico não consegue ler o código gerado para confirmar o que ele faz, e os testes manuais exercitam o ‘caminho feliz’, não as exceções. Portanto, o app que “funciona perfeitamente” no preview e o app que corrompe silenciosamente um quarto de seus registros podem ser - e frequentemente são - o mesmo app. Você descobre isso através de um cliente, não de um teste.
A cláusula de manutenção
É aqui que o Segundo Dia se soma ao restante da conta. Cada alteração que você faz é uma nova geração, e é na geração que residem tanto os custos quanto os riscos. Re-promptar uma funcionalidade ligada à autenticação é como jogar os dados da segurança novamente, como explicado em o que ‘45% do código de IA é vulnerável’ realmente significa; portanto, uma camada que você já verificou precisa ser verificada de novo. E cada rodada de correção de sintomas, em vez de causas raiz, alimenta a taxa do loop de correção: o ciclo de depuração pago que transforma uma assinatura barata em um custo aberto, a mesma dinâmica que separa os competidores em Lovable vs Bolt.
A infraestrutura adiciona suas próprias surpresas no Segundo Dia. Desenvolvedores que fazem self-hosting para evitar o lock-in da plataforma acabam sincronizando manualmente um banco de dados Supabase, um frontend Cloudflare Worker e uma plataforma de cron; qualquer dessincronização em um deles derruba tudo. Já quem permanece na hospedagem de uma única plataforma herda o uptime, os preços e o roadmap dessa plataforma. Nenhuma das opções é a alternativa gratuita que a demo sugeria.
O que continuar gerando e o que não gerar
A leitura honesta não é que o vibe coding seja inútil; ele é excelente para ferramentas pessoais, protótipos e componentes customizados delimitados, onde o escopo permanece pequeno. O erro é aplicá-lo às partes de um app que precisam sobreviver à manutenção. Se você está construindo dentro de uma base de código real e será o responsável pela revisão, uma ferramenta focada em código como o Cursor ou uma plataforma em nuvem como o Replit mantém você no controle do que muda e quando.
Para apps de negócios - portais, ferramentas internas, CRMs, qualquer coisa com logins, funções e dados reais - a camada que quebra no Segundo Dia é, em grande parte, a de autenticação, permissões e a estrutura de CRUD. Em uma plataforma como o Softr, isso não é gerado por projeto; é a infraestrutura configurada da plataforma. Assim, alterar uma permissão é apenas mudar uma configuração, não iniciar uma nova rodada de geração, e não há loop de correção para entrar. O Softr possui créditos de IA para seu Co-Builder, mas como tudo o que a IA faz também pode ser feito manualmente, um saldo zerado nunca bloqueia um ajuste. O Segundo Dia mais barato é aquele em que a parte mais importante nunca foi gerada para começar.