O Que É Vibe Coding, De Verdade?

O termo "vibe coding" se espalhou rápido em 2024-2025 porque nomeia algo que muitos desenvolvedores já faziam discretamente: descrever o que querem em inglês comum para um modelo como GPT-4, Claude, ou uma ferramenta como Cursor ou GitHub Copilot, e deixar que ele gere a maior parte do código real. O programador continua no loop, mas o loop parece diferente da programação tradicional.

A definição real

Andrej Karpathy cunhou a frase, descrevendo um fluxo de trabalho onde você "se entrega completamente às vibes" — você faz um prompt, aceita sugestões, executa o código, vê o que quebra, e faz um prompt de novo. Você não lê cada diff linha por linha. Você navega pelo resultado: o app faz o que deveria fazer, o teste passa, a página renderiza corretamente. A habilidade muda de escrever sintaxe para descrever a intenção com clareza e reconhecer quando o resultado está errado.

Isto é diferente de apenas usar autocomplete. Sugestões inline no estilo Copilot ainda assumem que você está escrevendo a função com alguma ajuda para terminar as linhas. Vibe coding assume que o modelo escreve a função, o arquivo, às vezes a feature inteira, e você está revisando e redirecionando em vez de criar do zero.

Como é uma sessão real

Um loop de vibe coding típico com uma ferramenta como Cursor ou Agent mode do Replit é mais ou menos assim:

1. Prompt: "Adicione um rate limiter a essa API Express, 100 requisições a cada 15 minutos por IP, retorne 429 com um corpo de erro JSON."
2. O modelo edita middleware/rateLimit.js, conecta em app.js, talvez puxe express-rate-limit.
3. Você executa npm test ou bate no endpoint com curl em um loop para checar se o 429 realmente dispara.
4. Algo está errado — o limiter reseta a cada deploy porque está em memória. Você diz isso.
5. O modelo troca para um armazenamento backed por Redis, adiciona a dependência ioredis, atualiza o arquivo docker-compose.
6. Você testa de novo, funciona, você faz commit.

Nenhuma linha daquele middleware foi digitada à mão. Mas seis ou sete decisões de julgamento foram tomadas por uma pessoa: qual deveria ser o limite, que armazenamento em memória era errado para produção, que o arquivo docker-compose também precisava ser atualizado.

Onde funciona bem

Vibe coding é forte para trabalho pesado em boilerplate: endpoints CRUD, validação de formulário, scaffolding de testes, arquivos de config, código de cola entre duas APIs que você já entende. Também é bom para prototipagem — pôr um demo funcional de uma ideia em uma hora em vez de um dia, depois decidir se vale a pena construir direito.

É genuinamente rápido para devs solo e times pequenos lançando ferramentas internas ou MVPs onde o custo de um bug é baixo e velocidade de iteração importa mais que pureza arquitetônica.

Onde falha

O modo de falha que as pessoas não falam o suficiente: modelos produzem código que executa mas está sutilmente errado de formas que não aparecem até depois. Uma query SQL gerada pode funcionar para o caminho feliz mas ser vulnerável a injection porque concatenação de string parecia ok para o modelo. Uma verificação de auth gerada pode passar nos testes mas pular uma verificação de role em uma rota. Se você não está lendo o código, não vai pegar isso — vai só ver os testes passarem e enviar.

Isto importa mais em código sensível a segurança do que em quase qualquer outro lugar. Simon Willison e outros apontaram que projetos com vibe coding e dados reais de usuários precisam do mesmo rigor de review de qualquer outro código, argumentavelmente mais, porque a pessoa que o "escreveu" pode não conseguir explicar o que faz linha por linha.

Sistemas complexos com muito estado implícito — concorrência, transações distribuídas, qualquer coisa com bugs sutis de timing — também são um encaixe ruim. Modelos tendem a gerar código que parece plausível para estes casos mas falha de formas que são difíceis de debugar precisamente porque ninguém, humano ou modelo, modelou completamente os edge cases de antemão.

A habilidade que realmente importa agora

Se você está fazendo vibe coding, a habilidade valiosa não é velocidade de digitação, é especificação. Prompts vagos recebem código vago e bugado. Prompts específicos — com nomes exatos de biblioteca, expectativas de tratamento de erro, e edge cases chamados — recebem output muito melhor. A segunda habilidade mais valiosa é ler código rápido o suficiente para pegar o que está errado, o que significa você ainda precisa entender a linguagem e o domínio mesmo que não esteja digitando cada caractere.

Trate código gerado por IA como você trataria um pull request de um dev junior que é rápido mas ocasionalmente confiante demais: útil, frequentemente correto, mas vale uma review real antes de tocar produção.

Quer ir mais fundo em escrever código com ferramentas de IA sem perder o controle da qualidade? Confira os segmentos AI e Python da Korra Studio para walkthroughs práticos.