Fiz vibe coding e criei um app funcionando em 40 minutos, e foi glorioso. Depois tentei adicionar uma segunda funcionalidade e tudo desabou como uma torre de Jenga. Se você já lançou algo real com um agente de IA, conhece esse sentimento. O vibe coding é incrível nos primeiros 80% e um pesadelo na parte que realmente importa.
Deixa eu definir o termo para não ficarmos falando de coisas diferentes. Vibe coding é quando você descreve o que quer em linguagem natural, deixa o agente escrever, dá uma olhada no resultado e continua no feeling — sem revisão de verdade, sem arquitetura, só impulso e vibração. É rápido. É divertido. E não escala além da demo. Essa é a opinião polêmica, e vou defendê-la.
Por que a primeira hora parece mágica
A fase inicial de qualquer projeto não tem restrições. Não há código existente para quebrar, nenhuma convenção a respeitar, nenhum usuário dependendo do comportamento de ontem. O agente recebe uma tela em branco e a preenche. Claro que é rápido. Você não está pedindo cautela, está pedindo geração, e geração é o que esses modelos fazem melhor.
Isso tem valor real, diga-se de passagem. Para um protótipo, um spike, um proof-of-concept descartável, o vibe coding é a ferramenta certa. Coloque a ideia na tela, veja se vale a pena construir, jogue fora. Faço isso toda semana. Sem anotações.
O erro é achar que a velocidade do protótipo vai continuar. Não vai.
Onde tudo desmorona
No segundo em que o codebase tem estado — padrões existentes, dados reais, uma funcionalidade da qual alguém depende — o cálculo se inverte. Agora cada mudança precisa ser consistente com o que já existe. E o vibe coding não tem nenhum mecanismo para consistência, porque você nunca olhou com atenção suficiente para saber o que "consistente" significa.
Já vi um agente, três funcionalidades dentro, inventar sua terceira maneira diferente de lidar com erros de API. Não porque é burro. Mas porque ninguém disse que as outras duas existiam, e no feeling você não percebe até que algo quebre de um jeito irritante de rastrear. O codebase vira uma escavação arqueológica — seis estilos, quatro abordagens de gerenciamento de estado, duas bibliotecas de data e uma função chamada handleStuff que faz autenticação.
Os bugs são a pior parte. Bugs feitos no vibe se escondem. O código parece certo — o modelo escreve código plausível e confiante — então você passa os olhos, compila, o caminho feliz funciona, você segue em frente. O bug aparece três funcionalidades depois quando o caso limite finalmente dispara, e agora você está debugando um código que nunca chegou a ler. Você nem tem o contexto de tê-lo escrito.
A revisão que você pulou é a conta que você vai pagar
Aqui está o que ninguém quer ouvir: a velocidade do vibe coding está parcialmente emprestada do futuro. Você não está pulando o trabalho de revisão. Você está adiando, com juros. Cada diff não revisado é um pequeno empréstimo. A demo vai rápido porque você pegou muitos empréstimos. O produto empaca porque os pagamentos vencem todos de uma vez, geralmente no pior momento.
É por isso que equipes batem numa parede por volta da terceira semana de um projeto vibe-coded. As primeiras funcionalidades voaram. Agora a velocidade caiu e ninguém sabe por quê. São os juros. O codebase não tem forma, e codebases sem forma ficam cada vez mais difíceis de mudar, não mais fáceis.
O que eu faço quando vira um produto de verdade
Ainda uso o agente para quase tudo. Só paro de ir no feeling no momento em que a coisa vira um produto. A mudança é assim:
- Leio cada diff antes de ele chegar ao código. Não passo os olhos. Leio. Se não entender, não vai.
- Mantenho um
CLAUDE.mdou equivalente que fixa as convenções — como tratamos erros, como gerenciamos estado, quais bibliotecas são aprovadas. O agente lê. A consistência deixa de ser questão de sorte. - Faço o agente escrever testes para tudo que não for trivial, e os executo. Um teste passando é a diferença entre "parece certo" e "é certo".
- Trabalho em pedaços pequenos e revisáveis. Uma funcionalidade, um diff claro, uma revisão. Não "construa o dashboard inteiro" num prompt febril só.
Nada disso é lento, exatamente. É deliberado. O agente ainda escreve o código. Só voltei ao loop como a pessoa que realmente sabe o que está acontecendo.
O enquadramento honesto
Aqui está um comando que rodo constantemente quando assumo uma bagunça vibe-coded:
git log --oneline -20 && git diff HEAD~5 --stat
Preciso ver o que mudou e quanto, porque no feeling ninguém estava rastreando. A primeira coisa que faço num projeto vibe-coded é reintroduzir a responsabilidade — com o diff, com os testes, com as convenções.
Vibe coding não é ruim. É uma fase. É o brainstorm, não o manuscrito. Os builders que se queimam são os que nunca evoluem — que tratam o workflow do protótipo como o workflow de produção e ficam se perguntando por que o app virou uma sopa.
Use as vibrações para descobrir o que construir. Depois coloque as mãos de volta no volante para construir de verdade. A demo vai te amar de qualquer jeito. O produto só vai te amar se você ler o código.