Tenho uma pasta cemitério. Quarenta e um diretórios de projetos, cada um uma tarde de vibe coding que produziu um demo bonito e zero reais. Depois mudei minha forma de trabalhar e lancei três coisas em dois meses pelas quais as pessoas realmente pagam. A diferença entre o cemitério e a receita não foi talento nem sorte. Foi um fluxo de trabalho.
Vamos falar de vibe coding versus lançamento real, porque a lacuna entre eles é onde a maioria dos construtores de IA solo se afoga silenciosamente. Me afundei lá por um ano.
O que é vibe coding de verdade
Vibe coding é quando você descreve o que quer, deixa a IA gerar, dá uma olhada no resultado, e continua na intuição. É incrível para manter o ímpeto. Você vai de uma pasta vazia a um protótipo funcionando em uma tarde e parece um superpoder.
É um superpoder. Para os primeiros 70%.
O problema está nos últimos 30%, a parte que transforma algo em produto em vez de demo: a auth que não vaza, o caso extremo quando o input está vazio, a mensagem de erro que não diz "undefined", o que sobrevive a um usuário real que não sabe o que você pretendia. O vibe coding passa por cima de tudo isso, porque tudo parece pronto. Parecer pronto e estar pronto são estados muito diferentes, e código gerado por IA é brilhante em parecer pronto.
O momento da mordida
Minha memória mais clara do cemitério: uma ferramenta de agendamento que fiz vibe-code em um fim de semana. Linda. Demonstrei para um amigo. Ele clicou em uma data no passado e tudo explodiu com um stack trace. Eu nunca tinha clicado em uma data no passado. A IA nunca pensou nisso. Por que pensaria? Eu nunca disse.
Essa é a armadilha. O vibe coding otimiza para o caminho feliz porque você está dirigindo na intuição, e sua intuição só cobre o caminho que você imaginou. Usuários reais vivem nos caminhos infelizes.
Como eu realmente lanço agora
Ainda faço vibe-code na primeira passagem. Não vou abrir mão da velocidade. Mas adicionei uma segunda fase, e é nessa fase que os produtos nascem.
Fase um, faço vibe. Rápido, solto, faço o esqueleto ficar de pé. Deixo o Claude Code construir todo o fluxo e não me preocupo com qualidade ainda.
Fase dois, mudo o trabalho do agente de "construir" para "quebrar". Literalmente. Eu digo a ele:
Você agora é um engenheiro de QA hostil. Liste todas as formas que um usuário
poderia quebrar essa funcionalidade. Inputs vazios, datas passadas, inputs enormes,
clique duplo, sem rede. Para cada um, me diga o comportamento atual. Não conserte ainda.
Essa única mudança de prompt extrai os 30% que o vibe coding esconde. O agente que acabou de construir a coisa é ótimo em atacá-la quando você dá permissão. Obtenho uma lista. Depois corrijo a lista, um por um. A passagem de QA hostil é toda a diferença entre minha pasta cemitério e meu painel do Stripe.
Escreva o que significa "pronto" antes de começar
A outra coisa que me tirou dos demos para os produtos: escrevo uma pequena definição de pronto antes de deixar o agente construir qualquer coisa. Não uma especificação. Cinco pontos em um arquivo.
Para aquela ferramenta de agendamento, refeita, foi: rejeita datas passadas, lida com um calendário vazio, funciona sem rede, mostra um erro real não um stack trace, carrega em menos de dois segundos. Cinco linhas. Fixo esse arquivo no contexto e o agente constrói contra ele em vez de contra meus vibes.
Vibes são uma ótima energia de partida e uma péssima especificação. Sua intuição nunca vai incluir "e se a rede estiver fora". Uma linha escrita vai.
O truque do eval que me mantém honesto
Para qualquer coisa com uma funcionalidade de IA dentro, não confio em vibes nem um pouco, porque o output de um LLM é não determinístico e "funcionou quando tentei" não significa nada. Escrevo cerca de dez exemplos de input/output de como o bom parece e os executo toda vez que mudo um prompt. É um conjunto de evals do homem pobre. Um arquivo de texto e um loop.
Quando ajusto um prompt para corrigir um caso, os evals pegam os três casos que quebrei sem perceber. Sem isso, estou jogando whack-a-mole de olhos vendados, corrigindo a reclamação de um usuário enquanto crio silenciosamente mais três. Dez exemplos. Essa é a barra. Você não precisa de um framework.
O que eu diria ao meu eu do cemitério
Vibe coding não é o inimigo. É o motor. Mas um motor sem freios e para-brisa é só uma forma rápida de bater em uma parede, e quarenta e um dos meus projetos bateram nessa parede em velocidade total.
Os construtores que lançam produtos reais solo não escrevem prompts melhores que os seus. Eu prometo. Eles estão fazendo a segunda fase chata que você está pulando: a passagem de QA hostil, a definição de pronto em cinco linhas, o eval de dez exemplos. Nada disso é difícil. Tudo é chato. É exatamente por isso que a maioria das pessoas não faz, e exatamente por isso fazer isso é uma vantagem.
Aqui está a divisão honesta. Vibe coding te leva a um demo em uma tarde, e isso vale tudo para testar se uma ideia tem pernas. Mas o salto do demo ao produto é uma marcha diferente, e ela roda com as coisas chatas. A tarde te faz sentir um gênio. A tarde chata te faz dinheiro.
Minha pasta cemitério tem quarenta e um demos. Meu painel do Stripe tem três produtos. A única coisa que os separava era a parte que eu costumava pular.
Vai quebrar seu próprio demo antes que um usuário faça de graça.