Vibe coding é programar descrevendo para uma IA o que você quer e aceitando o código que ela gera sem ler: se funciona quando você testa, segue em frente. Serve para protótipos rápidos e ferramentas pessoais. O risco aparece quando esse código chega a usuários reais sem que ninguém tenha revisado nem testado de verdade.
Uma pergunta do app. Escolha uma resposta.
O agente responde "Pronto, já funciona". O que sustenta isso melhor?
Parecer seguro não é evidência. Um modelo pode afirmar algo falso com toda a calma.
Editar mostra que mudou algo. Para saber se está certo, falta conferir.
É um resultado que você pode ver e repetir. Testes que passam sustentam o que testam, não o app inteiro.
O termo se popularizou no começo de 2025 com um post de Andrej Karpathy, pesquisador de IA. A ideia: você fala com um agente de código, aceita todas as mudanças e, se aparece um erro, cola a mensagem e pede para ele consertar. Você não lê o código; julga pela aparência e pelo comportamento do app.
Nem tudo que se programa com IA é vibe coding. Se você pede uma mudança com um prompt claro, lê o que ela fez e roda os testes, está programando com ajuda. A diferença não está na ferramenta, e sim em alguém entender e revisar o que entra.
Para coisas que dá para jogar fora ou que só você usa: uma página para calcular quanto cada um põe no churrasco, um script que renomeia as fotos da viagem por data, uma maquete para mostrar uma ideia a um cliente antes de investir semanas. Ali o que importa é a velocidade, e se algo falha, o estrago é pequeno.
Também abriu a porta para quem não programa: alguém de vendas ou de design pode montar a ferramenta de que precisa sem esperar o time técnico. Isso tem valor, desde que a ferramenta não mexa com dados de outras pessoas nem com dinheiro.
Antes de começar, três perguntas. Alguém além de você vai usar? Mexe com dados de outras pessoas, como e-mails, senhas ou fotos? Movimenta dinheiro? Se as três forem "não", vá em frente: é o terreno do vibe coding (mesmo assim, com dados de teste e tudo salvo no git). Com um único "sim", alguém que entende precisa ler o código e testar o que acontece quando falha.
Um script que organiza suas fotos no seu computador: três "não". Um app em que seus amigos cadastram os dados deles e pagam a parte da viagem: três "sim". O que muda é quem paga se falhar.
O código funciona na demo e falha na borda: o formulário aceita um valor negativo, ou a busca cai com um sobrenome com acento. Ninguém viu porque ninguém leu. Outros erros típicos: uma chave de API colada no código que o navegador enxerga, ou uma biblioteca que o modelo inventou e que alguém poderia publicar com esse nome para infiltrar código malicioso.
O outro problema chega com o tempo. Depois de cinquenta pedidos, o projeto é um monte de remendos que ninguém entende, e cada conserto quebra outra coisa. Nesse ponto, nem o agente sabe direito como está montado.
Comece com algo só para você, com dados inventados e sem movimentar dinheiro: por exemplo, uma página que divide uma despesa entre amigos. Antes de pedir, defina um teste concreto: "12 dividido por 4 tem que dar 3". E teste também o que acontece com zero pessoas.
Use um agente de código e peça primeiro um plano curto (modo de planejamento): veja se combina com a sua ideia. Depois avance uma mudança por vez e teste o resultado. Se você repete regras em cada pedido, deixe-as num CLAUDE.md ou num AGENTS.md. Para aprender, peça que ele mostre no código como uma parte funciona; a explicação também pode estar errada.
Dá para manter a velocidade e somar controles baratos. Peça ao agente que escreva testes para o que importa (que um valor negativo seja recusado) e que os rode; olhe você a saída, não o resumo dele. Trabalhe em passos pequenos e salve cada um no git, assim dá para voltar atrás se algo quebrar.
Antes de aceitar, dê uma olhada no diff, nem que seja por cima: quais arquivos ele mexeu e se tem algo que você não pediu. E não dê acesso ao banco de dados real nem a chaves de produção enquanto experimenta. Se o protótipo agradar e for ter usuários, esse é o momento de ler tudo.
Para montar um protótipo, não. Para saber se o que a IA fez está certo, o básico, sim. Não precisa escrever cada linha, mas precisa ver o que mudou no diff, saber onde uma chave de API nunca deve ficar e perceber se os testes verificam o que importa. Essa é a diferença entre fazer vibe coding às cegas e dirigir um agente.