Como eu faço vibe coding?

O que o vibe coding realmente exige de você

Vibe coding soa como a ausência de método, e é exatamente por isso que dá errado para tanta gente. Deixar um modelo escrever o código elimina o problema da sintaxe, mas não elimina os dois trabalhos que sempre foram a parte difícil: dizer com precisão o que deve acontecer, e verificar se aconteceu. Seu esforço se desloca em vez de desaparecer — de digitar código para especificá-lo e revisá-lo. Para saber de onde vem o termo, veja vibe coding.

É por isso que dois fundadores usando exatamente a mesma ferramenta chegam a resultados completamente diferentes. Quem começa com "construa um marketplace para mim" recebe uma demo que desmorona na segunda funcionalidade. Quem começa com um parágrafo nomeando o usuário, os dados e a única coisa que a versão um precisa fazer recebe algo em que vale a pena construir em cima. A escolha da ferramenta importa menos do que a maioria das comparações sugere — as melhores ferramentas de vibe coding explica como as famílias se diferenciam — porque o ciclo abaixo é o mesmo, seja qual for a que você escolher.

O ciclo, passo a passo

1. Escreva a especificação antes do prompt — um parágrafo: quem usa isso, o que precisa fazer, quais dados armazena, e o que explicitamente não vai fazer na versão um. Dez minutos aqui evitam a reconstrução que acontece quando o modelo chuta tudo que você deixou sem dizer.
2. Construa uma fatia de cada vez — peça a menor coisa que rode de ponta a ponta, confirme que ela realmente roda, e só então estenda. Um único prompt enorme produz uma superfície grande demais para você ter alguma chance real de revisar.
3. Faça commit toda vez que algo funcionar — controle de versão é o botão de desfazer do trabalho generativo. Quando a próxima mudança quebra três coisas ao mesmo tempo, um commit sabidamente bom é o único caminho confiável de volta, e custa apenas um comando para fazer.
4. Leia você mesmo as linhas de risco — logins, pagamentos, qualquer coisa que toque dados de clientes, e qualquer coisa que apague. Um modelo escreve código plausível e não vai te contar qual verificação ele pulou, então esses caminhos precisam ser lidos linha por linha mesmo quando o resto não é.
5. Teste como um estranho — navegue como um usuário de primeira viagem: entradas erradas, estados vazios, o botão de voltar, uma segunda conta. Apps gerados costumam estar corretos no caminho que o prompt descreveu e rasos em todo o resto.
6. Mantenha um registro de mudanças — peça ao modelo para resumir o que mudou e por quê depois de cada fatia, e guarde esse texto junto do projeto. É a defesa mais barata contra uma base de código que você não consegue mais explicar para ninguém, nem para si mesmo.

Onde ele quebra

Os modos de falha são consistentes entre ferramentas, e nenhum deles é realmente sobre o modelo ser ruim em código:

• Suposições silenciosas — o modelo constrói o que você pediu, não o que você quis dizer. Tudo que você deixou não dito é preenchido com algo plausível, e você descobre a lacuna quando um usuário de verdade esbarra nela.
• Coisas que funcionavam e param de funcionar silenciosamente — edições geradas alcançam mais longe do que parece. Se você não consegue rodar tudo depois de cada mudança, não vai perceber o que a última mudança quebrou até muito mais tarde.
• Segurança que você nunca escolheu — regras de acesso padrão, políticas de banco de dados permissivas demais e chaves commitadas onde não deveriam estar são comuns em apps gerados, e nada te avisa. Verifique isso antes do lançamento, não depois.
• Os últimos vinte por cento — os primeiros oitenta chegam em uma tarde; o resto é onde o modelo precisa que você realmente entenda o sistema. Ou reserve tempo para essa etapa, ou defina o escopo da versão um para que ela não precise dessa etapa.

O que acontece depois que funciona

Terminar o ciclo te dá um software funcionando que ninguém sabe que existe, que hoje é a situação padrão do fundador: construir ficou drasticamente mais barato e a distribuição não. Antes de construir mais, decida para que a versão um realmente serve — esse é todo o sentido de um produto mínimo viável — e quando funcionar, a próxima pergunta é como fazer marketing de um app feito com vibe coding.

Nota em primeira mão de quem constrói a AgentCeres — o Diretor de Crescimento com IA em agentceres.com: a maior parte do nosso código e das nossas páginas de marketing é redigida por IA e revisada por um humano, e a classe de erro mais cara nunca foi código ruim. Foi trabalho que desapareceu silenciosamente. Duas mudanças geradas em paralelo, cada uma correta e passando em todas as verificações contra o ponto de partida em que foi escrita, e quebrada no momento em que foram combinadas — porque ninguém rodou de novo as verificações sobre o resultado combinado. Se você levar um hábito desta página, leve esse: fatias pequenas, e verifique a coisa que você de fato entregou, não a peça que você acabou de gerar.