Vibe coding, e a primeira semana que não termina em bagunça
Vibe coding é construir descrevendo o que você quer e aceitando o que o modelo escreve sem ler tudo. Funciona quando errar custa pouco e o feedback é imediato — protótipos, scripts, ferramentas descartáveis. Para de funcionar quando o código sobrevive à sessão, porque o que você pulou é justamente o que depois vai precisar ser entendido.
Vibe coding é construir descrevendo o que você quer e aceitando o que o modelo escreve sem ler tudo. O termo é do Andrej Karpathy, e o que distingue não é a IA ter escrito o código — isso hoje é comum — mas que ninguém revisou linha por linha.
Isso é uma troca, não um erro. Se é uma boa troca depende inteiramente de uma pergunta: por quanto tempo esse código precisa viver?
Onde o vibe coding funciona de verdade?
Protótipos que você pretende apagar. O custo de errar é jogar fora, que era o que você ia fazer de qualquer jeito.
Scripts e ferramentas de uso único. Uma coisa que reformata um CSV, popula um banco de dados, faz scraping de uma página uma vez só. Se produz a saída certa, acabou; ninguém vai manter aquilo.
Aprender o formato de algo desconhecido. Conseguir um exemplo funcionando de uma biblioteca que você nunca usou é mais rápido assim do que ler a documentação antes, e você pode ler a documentação depois com uma coisa concreta na frente.
Qualquer coisa em que o feedback seja imediato e total. Se funciona, funciona, e você descobre em dez segundos.
O fio comum é que errar é barato e óbvio. Essa é a condição. Não o tamanho do projeto, nem a linguagem, nem se é “de verdade” — só se um erro aparece na hora e custa pouco.
Quando ele para de funcionar?
No momento em que o código sobrevive à sessão que o produziu.
Isso não é um julgamento moral. É aritmética: você comprou velocidade pulando o entendimento, e a conta chega quando alguém precisa mudar código que ninguém entendeu quando foi escrito. Se ninguém nunca mudar, a conta nunca chega e a velocidade saiu de graça. Esse é um desfecho real e acontece muito.
O que faz dar errado é não saber em qual dos dois casos você está. Quase toda experiência ruim começa como um protótipo que virou crítico em silêncio, sem ninguém decidir nada.
Como sei em qual caso estou?
Três perguntas, e elas são sobre a situação mais do que sobre o código:
| Pergunta | Vibe coding vale quando | Deixa de valer quando |
|---|---|---|
| Com que rapidez descubro que errei? | Em segundos. Você roda e vê | Em semanas, por um cliente |
| Quanto custa errar? | Você apaga e começa de novo | Dinheiro, dados ou a confiança de alguém |
| Quem mais depende disso? | Ninguém | Qualquer pessoa que não seja você |
As três apontando para o mesmo lado é o caso para o qual isso foi feito. As três apontando para o outro lado e você não está fazendo vibe coding, está apostando com passos a mais.
O útil é que isso se decide por peça de trabalho, não por projeto. A mesma tarde comporta um script descartável que você nunca lê e uma mudança de permissões que você lê duas vezes. Tratar um repositório inteiro como um ajuste único é o que produz os dois erros comuns: ler tudo num protótipo, e não ler nada na parte que morde.
O que eu nunca deveria fazer com vibe coding?
Uma lista curta, e o motivo é o mesmo em todos os itens:
- Autenticação e permissões. Errar aqui não lança erro. Deixa a pessoa errada entrar em silêncio, e você descobre por outra pessoa.
- Dinheiro. Preços, cobranças, estornos, moeda. Um off-by-one num laço é um bug; um off-by-one em centavos é um chargeback e um e-mail que você não quer escrever.
- Qualquer coisa que apague. Exclusões em cascata principalmente. O teste dessa categoria é se existe um desfazer.
- Migrações de banco de dados. Rodam uma vez, contra dados reais, e a falha é descoberta depois que os dados já se foram.
- Tudo que lida com dados pessoais dos outros. Errar aqui vem com um regulador junto.
Repare no que não é o critério: dificuldade. Alguns desses são código fácil. A propriedade que compartilham é que errar não se anuncia sozinho — que é exatamente a suposição sobre a qual o vibe coding roda.
Isso não é “escreva você mesmo”. É “leia esse aqui”. Deixe o modelo escrever, depois leia de verdade o que ele escreveu, e peça que explique as partes que você não conseguir acompanhar. A leitura é todo o custo, e nessas cinco vale a pena pagar.
A primeira semana
Mantenha as sessões curtas, e termine cada uma em algo que funciona. Esse é o hábito de maior retorno e não tem nada a ver com a IA. Uma sessão longa acumula decisões que ninguém escreveu, e quando enfim algo está errado não existe ponto para voltar. Sessões curtas com um commit que funciona no fim te dão um lugar para onde voltar.
Leia as partes caras. Não tudo — isso derrubaria o propósito. Leia qualquer coisa que toque dinheiro, autenticação, exclusão de dados, ou código em que outra pessoa também trabalha. O resto, passe o olho. A habilidade construída aqui é triage, e é uma habilidade real: saber onde errar sai caro é a maior parte do que engenheiros seniores sabem.
Diga o que ele não pode fazer. Quase todo mundo descreve o que quer e para por aí. A instrução que mais economiza tempo é a que exclui coisas — não toque no módulo de auth, não adicione dependências, não mude o schema do banco. Modelos são prestativos e vão fazer com prazer uma coisa útil que você não queria.
Rode antes de acreditar. Código gerado que parece certo e não roda é a falha isolada mais comum, e a mais barata de pegar.
Perceba quando o protótipo deixou de ser protótipo. Costuma existir um momento específico: outra pessoa abre, ou vai para a frente de um usuário, ou você faz deploy. Esse é o momento em que a troca muda, e a resposta honesta é voltar e ler direito.
Como é uma boa sessão, do começo ao fim
Concretamente, porque “mantenha as sessões curtas” é um conselho com o qual você concorda e mesmo assim não aplica:
- Comece de um commit. Não de um repositório arrumado — de um com commit. Esse é o ponto de save, e leva dez segundos.
- Diga o objetivo e o limite na mesma mensagem. O que você quer, e o que está fora de alcance. A segunda metade é a que as pessoas pulam.
- Deixe trabalhar sem interromper. Corrigir o rumo no meio do voo produz uma mudança que é metade de um plano e metade de outro, o que é mais difícil de ler do que qualquer um dos dois.
- Leia o diff, não a base de código. Quantos arquivos, quais arquivos, e se apagou algo que você não pediu para apagar.
- Rode. Antes de acreditar em qualquer parte.
- Faça commit, ou jogue a sessão inteira fora. Os dois são desfechos aceitáveis. O que não é aceitável é carregar um estado meio pronto para a próxima sessão.
Cerca de uma hora é onde isso costuma cair para a maioria, e o número importa menos que o formato: a sessão é a unidade que você pode jogar fora. Assim que uma sessão está longa a ponto de descartá-la ser impensável, você perdeu a propriedade que tornava toda a abordagem segura — e isso acontece de forma gradual, que é justamente por que vale a pena ficar de olho.
As perguntas que as pessoas realmente fazem
“Eu ainda sou um desenvolvedor de verdade fazendo isso?”
A pergunta por baixo é se você está construindo uma habilidade ou fugindo de uma. Está construindo uma — triage, especificação, saber onde o risco mora — e não é a mesma habilidade de escrever a sintaxe você mesmo. As duas são reais. Nenhuma se basta sozinha.
“Como impeço que ele invente bibliotecas que não existem?”
Rode o código. Imports alucinados falham na hora, o que faz dessa a classe de erro menos perigosa. Preocupe-se mais com os que rodam.
“Ele reescreveu algo que eu não pedi para tocar.”
Muito comum, e a correção normal é dizer o que está fora de alcance antes de começar. Num repositório em que outras pessoas trabalham, isso deixa de ser um incômodo e vira o problema de verdade — o que tem um post próprio.
“Devo fazer commit de código que não li?”
Em algo descartável, sim. Em algo compartilhado, você está entregando aos seus colegas um diff sobre o qual não consegue responder perguntas, e isso é um problema social antes de ser técnico.
“É assim que times profissionais trabalham agora?”
Em parte, e honestamente a resposta ainda está se movendo. O que está claro é que a restrição saiu de com que rapidez isso pode ser escrito para com quanta confiança isso pode ser mudado depois, e os times que vão bem são os que tratam isso como o eixo do desenho.
Para onde isso está indo, e o que a gente faz a respeito
Tudo acima funciona para uma pessoa sozinha na própria máquina. As falhas interessantes começam quando o repositório é compartilhado — quando o código gerado é localmente razoável e globalmente errado porque o modelo não conseguia ver uma convenção que mora na cabeça de alguém.
Esse é o problema em que o CommitCycle trabalha: cada agente ganha um grant preso a uma task e a um branch que expira sozinho, os paths que doeriam carregam um owner, e cada task fecha com um registro do que declarou contra o que tocou.
Sendo direto sobre onde isso está: o plugin instala hoje o enforcement, e o pacote commitcycle no npm instala a CLI — o processo sem o muro. O board hospedado é só por convite enquanto isso é pequeno. E nada disso é o que você precisa na sua primeira semana de vibe coding — na primeira semana você precisa de sessões curtas e do hábito de ler as partes caras.
Na semana seguinte, quando você já tiver decidido que a coisa vai existir além da sexta, a pergunta sai de hábitos e vai para setup: o que ter no lugar antes do primeiro prompt, e por que cada peça está ali.