Por que produtos feitos com vibe coding travam ao chegar em produção

O que é vibe coding de fato

Vibe coding é construir software descrevendo o que você quer para um modelo de IA e aceitando a maior parte do que ele escreve, sem ler linha por linha. Você conduz por intenção em vez de sintaxe. O termo pegou porque nomeia algo real: pela primeira vez, a distância entre uma ideia e uma interface rodando se mede em horas.

Não é sinônimo de usar IA para programar. Um engenheiro que revisa cada diff, mantém um modelo mental do sistema e rejeita metade do que o modelo sugere está fazendo outra coisa. A marca do vibe coding é que ninguém segura o quadro inteiro. O código existe, roda, e nenhum humano tem um modelo completo do porquê.

Todo mundo quer fazer vibe coding agora. Quase ninguém pensa em quem mantém o que sobra.

Virou tendência. "Construí um SaaS em 48 horas com IA." "Lancei um produto sem escrever uma linha." "O agente cuida da arquitetura, eu cuido da ideia."

Por que parece que funciona

Porque no primeiro trecho funciona mesmo. A fase inicial de um produto é quase toda terreno limpo: sem dado legado, sem usuário dependendo do comportamento de ontem, sem exigência de compliance, sem integração com um sistema que alguém construiu em 2011. Toda decisão é reversível porque nada ainda sustenta peso.

Nesse ambiente o modelo é extraordinariamente eficaz. Ele escreve código plausível rápido, e plausível basta quando o único juiz é se a tela renderiza. O ciclo de feedback é imediato e lisonjeiro.

A armadilha é concluir daí que a parte difícil está resolvida. O que aconteceu de fato é que você gastou a fase do projeto em que corretude era mais barata.

Aí chega a produção

Aí chega a produção.

O primeiro cliente pagante encontra um bug que mora num lugar que ninguém consegue localizar. A segunda funcionalidade obriga a reescrever metade do que já existe. Depois de algumas semanas o agente perdeu o rastro do próprio código. Uma migração quebra porque o domínio nunca foi modelado.

E o fundador acha que o próximo modelo vai resolver. Não vai.

As quatro falhas, e a causa real de cada uma

O bug que ninguém localiza. Depurar não é ler código, é ter um modelo de onde um determinado comportamento pode se originar. Quando nenhum humano construiu esse modelo, todo bug vira busca exaustiva. O código é legível; o sistema não é inteligível.

A funcionalidade que força reescrita. Isso é ausência de fronteira. Código gerado tende a resolver o pedido imediato do jeito mais direto disponível, o que em geral significa meter a mão direto no dado de que precisa. Faça isso cinquenta vezes e tudo toca tudo, então nenhuma mudança é mais local.

O agente perdendo o rastro do próprio código. Um modelo trabalha com o contexto que recebe. A partir de certo tamanho a base não cabe mais, então o modelo vê fragmentos e escreve com confiança a quinta versão de algo que já existe em quatro. O resultado não é um sistema, são vários sobrepostos.

A migração que quebra. Quando o domínio nunca foi modelado, o schema do banco é um acidente da ordem em que as funcionalidades foram pedidas. Migrar significa descobrir as regras do seu próprio negócio a partir do dado, que é exatamente o trabalho pulado no início, agora feito sob pressão e com clientes pendurados.

A parte que ficou mais rápida, e a que não ficou

Velocidade de escrita nunca foi o que impedia as pessoas de construir produtos. O que impedia era entender o problema, modelar o domínio, decidir o que escala e o que vira dívida.

A parte fácil ficou mais rápida. A parte difícil continuou exatamente onde estava.

Vale parar nisso, porque prevê para onde vão os próximos anos. Se digitar era dez por cento da dificuldade e digitar agora é de graça, você removeu dez por cento. Os outros noventa, que são julgamento sobre estrutura, seguem intactos, e agora são o gargalo inteiro.

Por que o próximo modelo não resolve

A aposta de que um modelo mais forte dissolve o problema erra sobre qual é o problema. Um modelo melhor produz código melhor por requisição. Ele não produz um sistema coerente ao longo de duas mil requisições feitas em quatro meses por alguém que não acompanhou as consequências.

Coerência não é propriedade de nenhuma saída isolada. Ela vem de decisões sustentadas com consistência ao longo do tempo: esta é a nossa fronteira, esta é a nossa fonte de verdade, esta invariante nunca é violada. Alguma coisa precisa segurar essas decisões. Hoje essa coisa é uma pessoa, ou um documento que uma pessoa mantém.

Modelos vão continuar melhorando na tarefa local. A tarefa global é outro tipo de trabalho, e não está obviamente na mesma curva.

O que fazer antes do primeiro prompt

Antes de pedir o primeiro prompt, modele o domínio. Depois delegue a execução.

Na prática isso é uma página, não um documento de arquitetura. Nomeie os três a cinco substantivos que seu negócio de fato tem e o que cada um significa. Escreva as regras que nunca podem ser violadas, aquelas em que a violação é incidente real e não bug. Decida as fronteiras: o que tem permissão de saber sobre o quê.

Aí deixe o modelo escrever dentro dessa estrutura. A diferença não é quanta IA você usa, é se a IA está preenchendo uma forma que você definiu ou inventando a forma no caminho. A primeira acumula valor. A segunda acumula bagunça.

Quando vibe coding é exatamente a escolha certa

Seria uma conclusão ruim ler isso como argumento contra a técnica. Vibe coding é a ferramenta correta sempre que o valor do artefato é a informação que ele te dá, não o artefato em si.

Protótipos feitos para serem jogados fora. Testar se um fluxo faz sentido antes de alguém se comprometer. Ferramenta interna com cinco usuários onde o custo de errar é uma conversa. Uma demo que precisa existir até quinta. Em todos esses casos, estrutura é overhead, porque a coisa não vai viver o suficiente para pagar esse custo de volta.

O erro não é usar. O erro é não perceber o momento em que um protótipo virou o produto em silêncio, o que quase sempre acontece sem que nenhuma decisão tenha sido tomada.

A linha entre uma demo e um sistema

Vibe coding valida uma ideia num fim de semana. Não sustenta um produto rodando em produção com SLA. Quem confunde as duas coisas descobre o preço no mês 4, quando o código para de evoluir e ninguém lá dentro consegue ler o que foi escrito.

O teste prático é uma pergunta só: se isso quebrar às duas da manhã, existe uma pessoa capaz de raciocinar sobre o porquê. Se a resposta é não, você ainda não tem um sistema, tem uma demo que por acaso tem usuários.

Essa distância entre algo que faz demo e algo que se sustenta em produção é onde a Studio Labs vive. É também por isso que construímos a coisa rodando em produção em vez de entregar um deck. Se você está descobrindo que forma o seu caso deve ter, o que é um agente de IA cobre a mesma pergunta pelo outro lado, e é o raciocínio por trás de como construímos IA em produção, ponta a ponta.