O que é vibe coding: programar conversando com a IA, onde funciona e onde quebra

O que você leva deste artigo

• O termo é de Andrej Karpathy, fevereiro de 2025, e virou palavra do ano do Collins em novembro de 2025.
• A definição inclui não revisar o código: aceitar sem ler é parte do conceito, não um desvio.
• Protótipo, ferramenta interna e automação pessoal são território legítimo.
• A linha vermelha é dado de terceiro, dinheiro e manutenção futura por outra pessoa.
• O custo escondido não aparece na primeira semana: aparece na primeira mudança.
• Usar IA para programar com revisão é outra coisa, e é o que profissional faz o dia inteiro.

De onde veio o termo, e o detalhe que se perdeu

Em fevereiro de 2025, Andrej Karpathy, um dos nomes mais respeitados da área e ex-diretor de IA da Tesla, descreveu num post uma forma de trabalhar que ele mesmo estava experimentando: conversar com o modelo, aceitar as sugestões, rodar, ver se funciona, pedir para consertar o que quebrou. Sem ler o código com atenção.

A expressão pegou de um jeito que ninguém previu. Em novembro de 2025, o dicionário Collins elegeu vibe coding como a palavra do ano, definida como desenvolvimento de software que transforma linguagem natural em código usando IA.

O detalhe que se perdeu na popularização é justamente o mais importante da definição original: não revisar faz parte do conceito. Karpathy descrevia explicitamente aceitar o código sem entender, deixando o modelo consertar quando algo quebrasse. Não era uma recomendação para software sério: era a descrição de um modo de trabalhar para projeto descartável de fim de semana.

Quando essa parte some, o termo passa a ser usado como sinônimo de "programar com IA", que é outra coisa completamente diferente. Programador profissional usa IA o dia inteiro e revisa cada linha antes de aceitar. Isso não é vibe coding: é ferramenta.

Não revisar não é um desvio do vibe coding. É a definição dele. Quando você revisa, você está fazendo outra coisa, e a outra coisa é melhor.

Por que funciona tão bem no começo

A experiência inicial é genuinamente impressionante, e vale reconhecer isso em vez de torcer o nariz. Você descreve uma tela, ela aparece. Pede um botão, ele funciona. Em uma tarde você tem algo rodando que antes exigiria uma semana e alguém que soubesse programar.

Isso acontece porque a maior parte do software comum é variação de padrão conhecido. Formulário que salva no banco, listagem com filtro, tela de login, envio de e-mail, carrinho de compras. Esses padrões apareceram milhões de vezes no material de treino, e o modelo os reproduz muito bem.

A segunda razão é que o começo de um projeto é o momento em que há menos restrição. Não existe código antigo para não quebrar, não existe usuário para não incomodar, não existe dado em produção para não corromper. Tudo é possível porque nada foi decidido ainda.

A ilusão vem daí: a facilidade do começo é interpretada como facilidade do todo, e a pessoa projeta a velocidade da primeira semana para as próximas doze. É exatamente aí que a conta muda.

Onde ele quebra, e quando isso aparece

A quebra quase nunca acontece na construção. Acontece na primeira mudança, e essa distinção explica por que tanta gente é pega de surpresa.

Quando você pede uma alteração num sistema de vinte arquivos que você não leu, você não sabe o que mais depende daquilo. O modelo também não sabe de tudo, porque ele vê o que cabe na janela dele. A alteração funciona no que você testou e quebra em algum lugar que você nem sabe que existe. E como você não entende o código, não consegue investigar: só consegue pedir para consertar, o que gera outra mudança que você também não entende.

O segundo ponto de quebra é a segurança, e ele é o mais grave porque é silencioso. Código que funciona e código que é seguro são coisas diferentes. Uma tela de login pode funcionar perfeitamente e permitir que qualquer pessoa entre na conta de outra trocando um número na URL. O sistema não dá erro, o teste passa, o cliente usa. O problema aparece quando alguém procura, e às vezes quem procura não é você.

O terceiro é a dependência de quem construiu. Software sem ninguém que o entenda é um ativo que só o autor original consegue mexer, e às vezes nem ele, porque ele também não leu. Quando esse alguém sai, ou perde o interesse, o sistema vira um bloco que só dá para substituir inteiro.

A linha que vale a pena traçar

Existe um corte prático que resolve a maior parte das dúvidas, e ele não é sobre tamanho do projeto nem sobre quem está construindo.

É território legítimo tudo que é descartável, interno e reversível. Protótipo para mostrar uma ideia antes de investir. Planilha inteligente que só você usa. Script que organiza os seus arquivos. Automação pessoal que economiza duas horas por semana. Se quebrar, o pior que acontece é você perder tempo.

Não é território nada que guarde dado de outra pessoa, movimente dinheiro, tome decisão com efeito legal ou precise ser mantido por alguém que não seja você. Cadastro de cliente, pagamento, prontuário, contrato, folha de pagamento. Aqui a consequência do erro sai do seu colo e vai para o de terceiros.

A pergunta que resolve na hora, e ela é mais útil que qualquer regra técnica: se isso vazar, quebrar ou calcular errado, quem paga? Se a resposta é você, e o prejuízo é seu tempo, siga. Se a resposta envolve cliente, dinheiro alheio ou dado pessoal, você precisa de outra abordagem.

• Pode: protótipo, ferramenta interna sua, automação pessoal, prova de conceito, aprendizado.
• Com cuidado: ferramenta usada pela equipe, com dado que não é sensível e cópia de segurança.
• Não: qualquer coisa com dado de cliente, pagamento, saúde, contrato ou obrigação legal.

O meio termo, que é onde o resultado está

A discussão pública ficou polarizada entre "IA vai substituir programador" e "isso não presta". As duas posições ignoram onde as coisas realmente funcionam bem hoje, que é no meio.

O jeito produtivo de trabalhar é usar a IA como quem usa um profissional muito rápido e ocasionalmente distraído: ela escreve, você lê antes de aceitar, ela explica o que fez quando você não entende, você testa o que importa. A velocidade continua muito maior que a de antes, e o entendimento não é perdido.

Isso muda a natureza do trabalho de quem programa: menos tempo escrevendo o óbvio, mais tempo decidindo arquitetura, revisando e testando. Ferramentas construídas para esse fluxo, como o Claude Code, existem exatamente para isso, e trabalham em cima do projeto inteiro em vez de sugerir linha a linha.

E existe um uso do vibe coding que é legítimo dentro de um trabalho sério: usar para descobrir o que você quer. Construir três versões descartáveis de uma tela em uma tarde para decidir qual faz sentido é barato e útil. O que não pode é a terceira versão ir para produção sem ninguém ler.

Se você é dono de empresa e vai contratar

Vale saber o que perguntar, porque a diferença entre um sistema construído com IA e revisado e um construído com IA e aceito no escuro não aparece na demonstração. Nas duas, a tela funciona.

Pergunte quem revisou o código e o que acontece se a pessoa que construiu sair. Pergunte onde ficam os dados, quem tem acesso e se existe cópia de segurança testada, não só configurada. Pergunte o que acontece se dois usuários fizerem a mesma coisa ao mesmo tempo, que é o tipo de problema que código gerado sem revisão quase nunca trata.

E pergunte a coisa mais simples de todas: peça para explicarem uma parte do sistema. Quem entende consegue explicar em português por que aquela decisão foi tomada. Quem só aceitou o que apareceu não consegue, e isso fica evidente em dois minutos.

Nada disso é argumento contra usar IA para construir. É argumento a favor de saber o que você está comprando. A ROO3 constrói com IA todos os dias, em produto próprio e em projeto de cliente, e a diferença está inteira na revisão e nos testes que ninguém vê. Se você está avaliando um projeto agora, é esse tipo de conversa que abre a consultoria em IA, e a parte de site em si está em criação de sites.

Perguntas frequentes

Quem inventou o termo vibe coding?

Andrej Karpathy, em fevereiro de 2025, descrevendo um jeito de programar em que você conversa com a IA, aceita as sugestões e deixa o modelo consertar o que quebra, sem revisar o código com atenção. Em novembro de 2025 o dicionário Collins elegeu a expressão como palavra do ano.

Vibe coding é a mesma coisa que programar com IA?

Não. A definição original inclui não revisar o código gerado. Um programador que usa IA e lê cada linha antes de aceitar está usando uma ferramenta, não fazendo vibe coding. A diferença parece pequena e é justamente ela que define se o resultado é mantível.

Dá para fazer um site profissional com vibe coding?

Dá para colocar algo no ar rápido, e a conta muda na primeira mudança. Site institucional simples costuma sobreviver; qualquer coisa com cadastro de cliente, pagamento ou área logada acumula riscos de segurança que não aparecem na tela e só são descobertos quando alguém procura.

Qual o maior risco do vibe coding numa empresa?

Falha de segurança silenciosa. Código pode funcionar perfeitamente e ainda assim permitir que um usuário acesse o dado de outro. O sistema não dá erro, o teste passa e o problema só aparece quando alguém procura por ele, que às vezes não é você.

Como sei se o meu projeto pode ser feito assim?

Faça uma pergunta: se isso vazar, quebrar ou calcular errado, quem paga? Se a resposta é você e o prejuízo é o seu tempo, siga. Se envolve dado de cliente, dinheiro de terceiros ou obrigação legal, o projeto precisa de revisão e de teste feitos por alguém que entenda do código.

Vou precisar refazer tudo depois?

Nem sempre, mas é comum. Sistema que ninguém entende tende a ser substituído em vez de evoluído, porque cada mudança quebra algo imprevisível. Vale contar com esse custo desde o início, e tratar o que foi construído assim como protótipo caro, não como base definitiva.

Fontes

• Collins Dictionary: palavra do ano de 2025
• CNN: vibe coding eleito palavra do ano pelo Collins

Rodrigo Fávaro

Fundador da ROO3, agência de marketing e tecnologia em São José do Rio Preto. Constrói produtos com IA em produção (Tobia, gerar.app, Pense Mercado) e mantém o AI Benchmark, ranking público de modelos de IA. Veja a consultoria em IA da ROO3.

X @rodmf LinkedIn rodrigofavaro