Vibe Coding sem Bagunça: 6 Hábitos que Evitam que Projetos Gerados por IA Desmoronem

Vibe coding é ótimo até não ser. Você descreve o que quer, a IA escreve, você clica em volta, funciona, você pede a próxima coisa. Na primeira hora ou duas parece cola. Aí uma mudança quebra algo que não tinha nada a ver, você pede pra IA consertar, o conserto quebra outra coisa, e de repente você está olhando pra um projeto que você não escreveu e não consegue entender.

Essa falha não é sinal de que você precisa aprender a programar primeiro. É o que acontece quando nada no processo te dá um caminho de volta. Um punhado de hábitos pequenos resolve a maior parte disso, e nenhum deles exige entender cada linha que a IA produz.

Aqui estão seis que valem a pena adotar antes do seu próximo projeto.

1. Escreva uma Especificação de Uma Página Antes do Primeiro Prompt

A forma mais comum de um projeto vibe-coded dar errado é um primeiro prompt tipo “monta um app de hábitos pra mim.” A IA precisa inventar cada decisão que você não tomou: a stack, o modelo de dados, o que “pronto” significa. Cada suposição é razoável sozinha, e juntas elas somam um app que não é bem o seu.

Gaste dez minutos escrevendo o que você realmente quer antes de abrir o chat. Não precisa ser formal. Precisa responder quatro perguntas: o que faz, quem usa, quais ferramentas deveria usar, e o que explicitamente não faz parte dessa versão.

Depois cole essa especificação no topo da conversa e deixe ela lá:

Here is the spec for what we're building. Follow it and ask me before
adding anything that isn't in it.
What it does: [one or two sentences]
Who uses it: [who, and on what device]
Stack: [e.g. plain HTML/CSS/JS, or React + Vite]
Out of scope for this version: [things you don’t want yet]
Don’t write any code yet. First, tell me in plain English how you
plan to build it in small steps.

Essa última linha importa. Pedir o plano primeiro te dá a chance de pegar uma suposição errada enquanto ela ainda é uma frase, e não uma pasta cheia de arquivos.

2. Uma Funcionalidade por Prompt

Prompts do tipo “constrói o app inteiro” produzem muito código que você nunca viu rodar. Se algo está errado, você não consegue saber qual das quinze partes é a culpada.

Peça a menor fatia que funcione de ponta a ponta, rode, e só depois peça a próxima. Adiciona o formulário. Faz ele salvar. Mostra os itens salvos. Adiciona exclusão. Cada passo é pequeno o suficiente pra que, se quebrar, você saiba exatamente qual prompt quebrou.

Isso também mantém a IA honesta. Pedidos menores deixam menos espaço pra ela reestruturar silenciosamente coisas que você não pediu pra mexer.

3. Faça Commit Depois de Cada Passo que Funcionar

Esse é o hábito que rende mais pelo menor esforço. Controle de versão com Git é um save de jogo: toda vez que algo funciona, você salva, e se o próximo prompt destruir o projeto, você volta pro último save em vez de tentar desfazer o estrago.

Depois de cada passo que funcionar, rode:

git add -A
git commit -m "Add the save button"

Quando um prompt dá errado e você ainda não commitou o resultado, isso descarta as mudanças não commitadas nos arquivos que o Git já rastreia e te coloca de volta no seu último save:

git restore .

Cuidado: isso realmente descarta essas mudanças, então é pra “essa tentativa foi ruim”, não pra nada que você queira manter. Se você nunca usou Git, peça pra IA configurar e explicar cada comando. Leva cinco minutos e é a maior rede de segurança que você pode ter.

4. Mantenha Segredos Fora dos Prompts e Fora do Repositório

Mais cedo ou mais tarde seu projeto vai precisar de uma API key, uma senha de banco de dados, ou um token. O erro a evitar é colar isso no chat ou fixar no código, porque a IA vai escrever isso direto no seu código-fonte com todo gosto, e código-fonte acaba no GitHub.

Coloque segredos num arquivo .env, e garanta que .env está listado no .gitignore antes do seu primeiro commit, não depois. Diga pra IA que essa é a regra:

Read all API keys and passwords from environment variables loaded
from a .env file. Never put a real key in the code. Make sure .env
is in .gitignore, and add a .env.example with the variable names
but no values.

Se uma chave chegar a ser commitada ou colada em algum lugar público, não basta apagar ela do arquivo. Trate como comprometida: revogue no painel do provedor e crie uma nova, porque o histórico do Git e repositórios públicos guardam o valor antigo.

5. Faça a IA Revisar o Próprio Trabalho

Código gerado por IA geralmente é escrito pra parecer certo, e pode estar errado de formas que só aparecem com uma entrada fora do comum. Você não precisa achar esses casos sozinho. Você pode pedir por eles.

Depois de cada funcionalidade, antes de seguir em frente, faça a IA revisar o que acabou de escrever:

Before we move on: list what could break with this change, including
empty inputs, very long inputs, and anything that depends on the
other features. Then write tests for the two riskiest cases and run
them. Explain any part of the code you changed in plain English.

Duas coisas pra ter em mente. Primeiro, isso é uma segunda olhada, não uma garantia, então continue abrindo o app e tentando quebrar você mesmo. Segundo, a parte de “explique em português claro” é como você vai, aos poucos, entendendo seu próprio projeto, o que compensa no dia em que você precisar debugar ele.

6. Reinicie o Chat Quando Ele Começar a Entrar em Loop

Existe um padrão familiar: a IA tenta um conserto, não funciona, você cola o novo erro, ela tenta outro conserto, e três rodadas depois o código está pior do que onde você começou. Conversas longas acumulam ideias meio abandonadas, e a IA continua construindo em cima delas.

Quando um bug sobrevive a duas ou três tentativas, pare. Volte com git restore . se as tentativas bagunçaram tudo, abra uma conversa nova, e dê a ela só o que precisa: a especificação, o arquivo com o problema, e o erro exato.

Fresh start. Here's the spec, the file that's failing, and the exact
error. Before changing anything, explain what you think is causing
it and how you can confirm that. Then make the smallest fix possible.
[paste spec] [paste file] [paste error]

Um contexto limpo mais “explique a causa primeiro” ganha de uma quarta tentativa às cegas quase sempre.

A Versão Resumida

Se você só for levar uma coisa daqui, que seja a rede de segurança. Os hábitos, em ordem de esforço versus retorno:

• Faça commit depois de cada passo que funcionar, pra sempre ter um caminho de volta.
• Escreva uma especificação curta, pra IA não ficar adivinhando o que você quer.
• Peça uma funcionalidade por vez, pra uma quebra ser fácil de rastrear.
• Mantenha segredos no .env, pra uma chave nunca parar num repositório público.
• Faça a IA revisar o próprio trabalho, pra problemas aparecerem antes de você lançar.
• Reinicie o chat quando ele entrar em loop, pra uma conversa ruim não afundar o projeto.

Nada disso deixa o vibe coding muito mais lento. Só significa que, quando algo quebrar, e algo vai quebrar, você tem um save pra voltar e uma ideia clara de onde deu errado.