Por que vibe coding não escala

Já vi alguns vídeos no meu feed de pessoal, abrindo alguma IDE e digitando no prompt: "crie um sistema de login com cadastro, recuperação de senha e autenticação JWT", pera... faltou o principal no início, "Atue como um Desenvolvedor Sênior e crie...", esperando 30 segundos e aceitando tudo que apareceu na tela. No final, o título do vídeo: "Como criar autenticação completa em 2 minutos com IA". Pronto, inúmeras curtidas, comentários do tipo "isso vai mudar tudo", "não preciso mais estudar back-end", "programação acabou".

Quem entende um pouco de programação web fica se perguntando: sério que hoje é só isso? Não tem nenhum ensinamento por trás disso? é só pedir e aceitar? Onde estão as decisões de arquitetura? Por que raios vai usar JWT... esse cara sabe pelo menos por que JWT e não o velho e bom Session Cookie?

Você olha aquilo e pensa, continua assim e vai dar merda. E não é porque a IA escreveu código ruim. O código provavelmente até roda. O problema é outro, e é o problema que ninguém está falando porque não vende curso, não vira thumbnail e não gera engajamento. Não existia arquitetura ali. Existia um prompt e uma esperança.

É disso que eu quero falar hoje.


O que é vibe coding (para mim)

Vibe coding não é "usar IA pra programar". Eu uso IA todos os dias e não me considero um vibe coder. Vibe coding é programar aceitando tudo o que a IA cospe sem ter um modelo mental do sistema que você tá construindo. É terceirizar o pensamento, não
a digitação. Sim, na minha visão a maioria dos pensamentos e decisões devem ser teus, a IA deve apenas digitar.

A diferença é sutil, mas é tudo. Quando eu peço pra IA gerar um Service Object (isso aqui dói nos puristas do Ruby on Rails), eu já sei:

  • Onde ele vai morar na estrutura do projeto.
  • Qual padrão os outros Services seguem.
  • O que ele pode e não pode fazer.
  • Como ele vai ser testado.
  • Quem vai chamá-lo e em que contexto.

O vibe coder pede "faz um service pra processar pagamento" e aceita o que vier. No próximo prompt, pede "faz um service pra enviar e-mail" e aceita o que vier também. Sem perceber que os dois saíram com padrões completamente diferentes, porque a IA muitas vezes não vai ter a memória do que ela mesma gerou cinco minutos atrás.


Por que parece que funciona

Essa é a parte traiçoeira. Vibe coding parece funcionar. E parece muito bem.

A demo roda. O CRUD aparece na tela. O login autentica. O usuário cadastra. Você abre o navegador, clica em voltar, tudo responde. Você sente que produziu, que produziu pra caralho. E produziu mesmo, só que produziu uma coisa que ninguém ainda tentou manter, mudar, escalar ou debugar.

O débito técnico do vibe coding não aparece no dia 1. Aparece daqui a 90 dias, quando alguém pede uma mudança "simples" e você descobre que aquela regra de negócio está espalhada em quatro lugares, cada um implementado de um jeito, porque cada prompt foi gerado isoladamente. Aparece quando alguém novo entra no time e leva duas semanas pra entender o que deveria levar dois dias. Aparece quando uma migration mal pensada roda em produção e deixa para trás um monte de overengenharia.


Onde quebra de verdade

Deixa eu ser específico, porque eu mesmo já caí em algumas dessas armadilhas usando IA no modo next, next: Regra de negócio espalhada. Você pede o cadastro de usuário num prompt. Duas semanas depois, pede o endpoint de atualização de
perfil em outro prompt. A IA gera validação de e-mail nos dois lugares diferentes. Quando o cliente pede pra aceitar outro domínio de e-mail, você muda em um e esquece do outro. Bug em produção.

Outro exemplo: inconsistência arquitetural. Metade do projeto usa Service Object, metade tem lógica gorda no controller, metade enfiou no model. Não é decisão, é acidente. Cada prompt veio com um humor diferente da IA.

Testes que parecem testar (quando têm). Se você não tiver no controle, a IA vai ser ótima em gerar testes que passam, e vai ser péssima em gerar testes que protegem dos edge cases. Tem uma diferença enorme entre assert response.successful? e um teste que de fato cobre o caminho crítico do negócio. O vibe coder não percebe a
diferença porque nunca viu um teste salvar um deploy.


O que muda quando você tem arquitetura na cabeça

Quando você sabe pra onde o sistema tá indo, o prompt deixa de ser "faz isso" e vira algo tipo: "implementa esse caso de uso seguindo o padrão dos Services em app/services/, retornando um Result object, e me gera os testes cobrindo o caminho feliz e os dois caminhos de erro que já mapeei."

Sentiu a diferença? O segundo prompt é mais longo, mais chato, e gera código que se encaixa no resto do projeto. O primeiro gera um pedaço solto que vai brigar com tudo que existe.

Mais importante: quando você tem arquitetura na cabeça, você revisa o código que a IA gerou com o mesmo critério que você revisaria um PR de júnior. Você lê, questiona, manda refazer. Você diz "não, essa responsabilidade não é desse objeto", "esse nome não tá claro", "esse teste não testa nada". Você é o sênior na sala. A IA é o estagiário rápido.

Vibe coder não revisa. Vibe coder aceita.


Fato

IA amplifica quem você é como dev. Não inverte, não substitui, amplifica.

Sênior com IA fica absurdamente mais rápido, porque ele sabe o que pedir, sabe o que recusar, sabe quando intervir. A IA tira dele o trabalho mecânico (word/minuto não importa) e devolve foco pro trabalho de verdade, que é decidir.

Júnior sem base com IA produz mais lixo, mais rápido. E o pior: produz lixo que parece bom, porque a IA escreve bonito.
Indentação certa, nomes em inglês, comentário no lugar. Por fora é Google. Por dentro é nada.

A ferramenta não substitui o que você não tem. Ela só deixa mais óbvio.


Fechando

Vibe coding escala pra demo. Escala pra portfólio no GitHub que ninguém vai abrir de novo. Escala pra vídeo de YouTube que vai bombar por uma semana.

Não escala pra produção. Não escala pra time. Não escala pra sistema que precisa estar vivo daqui a cinco anos, com gente nova entrando, requisito mudando, escala crescendo.

Para concluir, é possível sim escrever um sistema bom usando IA, mas você precisa sempre estar no controle, tomando todas as decisões. E aqui vai uma dica: todas essas decisões arquiteturais devem estar no arquivo CLAUDE.md/AGENTS.md. Isso vai te poupar muito tempo.