Este guia mostra de onde veio o termo, quanta gente usa IA para programar (com amostra, e por que esse número não é o mesmo que vibe coding), o que os estudos dizem sobre velocidade e segurança do código gerado, o que um profissional de marketing consegue construir sozinho e onde isso quebra.
O que é vibe coding?
É pedir o software em português (ou inglês) e aceitar o que a ferramenta devolve, sem auditar o código. Você descreve o comportamento, testa o resultado na tela, e se não estiver certo, descreve de novo. O código existe, mas não é onde você está olhando.
A definição que entrou no dicionário Collins é direta: "o uso de inteligência artificial, instruída por linguagem natural, para escrever código de computador". Foi eleita palavra do ano de 2025, anunciada em 06/11/2025.
Uma ressalva sobre essa fonte, porque o blog leva isso a sério: o Collins não publica o corpus nem a metodologia por trás da escolha. É um sinal cultural forte e não é uma medida.
O que separa o vibe coding de "usar IA para programar" é o nível de conferência. Um desenvolvedor que pede uma função à IA, lê, entende e ajusta não está fazendo vibe coding: está usando um autocompletar caro. Vibe coding é quando você não lê.
De onde veio o termo?
De um post de Andrej Karpathy no X, em 2 de fevereiro de 2025. O trecho que fundou o termo:
"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
Em português: existe um novo tipo de programação, em que você se entrega totalmente às vibes e esquece que o código sequer existe.
Duas notas de procedência. A plataforma bloqueia leitura automatizada do post original, então conferimos o texto e a data em duas fontes independentes, que batem. E circula muito uma continuação sobre "aceitar tudo" atribuída ao mesmo post. Não conseguimos confirmar aquele trecho literalmente, então ele não aparece aqui entre aspas, e recomendamos que você também não o cite.
Sobre dicionários: o Collins registrou, o Merriam-Webster tem verbete com primeiro uso em 2025, e o Oxford não tem, ao contrário do que muitos textos afirmam.
Quanta gente programa assim?
Os números que existem medem uso de IA para programar, que é mais amplo que vibe coding. A distinção importa, porque é exatamente aí que o dado costuma ser esticado.
O que foi medido | Número | Quem mediu e com que amostra |
|---|---|---|
Usam ou pretendem usar IA no trabalho | 84% | Stack Overflow, mais de 49.000 respondentes em 177 países, 2025 |
Profissionais que usam todo dia | 51% | mesma pesquisa |
Confiam muito no resultado | 3,1% | mesma pesquisa |
Desconfiam ativamente do resultado | 45,7% | mesma pesquisa |
Reclamam de código "quase certo" | 66% | mesma pesquisa |
Adotaram IA no fluxo de trabalho | 90% | DORA (Google), cerca de 5.000 profissionais, 23/09/2025 |
Tempo diário com IA (mediana) | 2 horas | mesma pesquisa DORA |
Fonte: Stack Overflow Developer Survey 2025 (49.000+ respondentes, 177 países) e relatório DORA do Google, publicado em 23/09/2025 com cerca de 5.000 profissionais.
O contraste dentro da mesma pesquisa é o dado mais interessante: 84% usam e 3,1% confiam muito. Adoção quase universal convivendo com desconfiança quase universal.
Um aviso sobre o que você vai encontrar por aí: muitos textos citam uma "pesquisa Stack Overflow 2026" repetindo exatamente esses números. A edição de 2026 abriu o questionário em 23/06/2026 e, até setembro de 2026, os resultados não tinham saído. É o levantamento de 2025 com o rótulo trocado. Se um texto atribui esses percentuais a 2026, ele não conferiu a fonte.
Vibe coding deixa o trabalho mais rápido?
Aqui está o achado que deveria mudar a conversa, e que quase não aparece nos textos sobre o assunto.
O METR conduziu um ensaio controlado randomizado com desenvolvedores experientes trabalhando nos próprios repositórios, em tarefas reais:
Fonte: METR, ensaio controlado randomizado com 16 desenvolvedores experientes e 246 tarefas nos próprios repositórios, usando Cursor Pro com Claude 3.5 e 3.7, publicado em 10/07/2025.
Eles previram ganhar 24% de tempo. Ficaram 19% mais lentos. E o detalhe que dá o tom: mesmo depois de terminar, ainda achavam que tinham ganhado 20%.
Duas honestidades obrigatórias sobre esse estudo. A amostra é pequena: 16 pessoas. E o recorte é específico: desenvolvedores experientes em bases de código que já dominam. Não é o mesmo caso de quem não sabe programar e está construindo algo do zero, onde a alternativa não é escrever mais devagar, é não construir.
O que ele mostra, e isso vale para qualquer recorte, é que a percepção de velocidade não é medida de velocidade. O relatório do DORA registra que mais de 80% dizem se sentir mais produtivos. Sentir é o que o METR mediu e não encontrou.
O código gerado é seguro?
A Veracode, que vende justamente segurança de aplicação e portanto é parte interessada, testou 80 tarefas de programação em 4 linguagens, com mais de 100 modelos em 2025 e mais de 150 na atualização de 24/03/2026. O resultado tem duas metades que andam em direções opostas:
- Sintaxe: a taxa de código sintaticamente correto subiu de cerca de 50% para mais de 95%.
- Segurança: cerca de 45% do código gerado falha em pelo menos uma categoria do OWASP Top 10. Esse número não se moveu entre as duas rodadas.
Fonte: Veracode, avaliação de 80 tarefas em 4 linguagens, mais de 100 modelos em 2025 e mais de 150 na atualização de 24/03/2026.
Os modelos ficaram muito melhores em produzir código que roda e não ficaram melhores em produzir código que não pode ser invadido. Como o que roda é o que você vê na tela e a falha de segurança é o que você não vê, o progresso visível esconde o problema invisível.
Isso não é teórico. O guia de Lovable traz dois episódios documentados de exposição de dados em aplicações geradas assim, ambos ligados a configuração de permissão de banco.
O que acontece com o código depois?
A GitClear analisou 623 milhões de linhas de código alteradas entre 2023 e 2026. Vale dizer que a empresa vende análise de qualidade de código, então é parte interessada no assunto que mediu. O que ela registra:
Indicador | Variação | O que significa |
|---|---|---|
Duplicação de blocos | +81% | o mesmo trecho repetido em vários lugares |
Refatoração | -70% desde 2023 | quase ninguém mais reorganiza o que existe |
Manutenção de código legado | -74% | mexe-se pouco no que já estava lá |
Fonte: GitClear, 623 milhões de linhas de código alteradas entre 2023 e 2026, publicado em janeiro de 2026. As variações são medidas contra 2023.
Duplicação subindo e refatoração caindo descrevem o mesmo fenômeno por dois lados: ficou mais barato escrever de novo do que entender o que já existe. Para um projeto que vai durar uma semana, tanto faz. Para um que vai durar dois anos, é dívida acumulando em silêncio.
O que dá para construir sem saber programar?
Sendo concreto sobre o que um profissional de marketing consegue entregar sozinho:
Funciona bem: página de campanha com formulário e dados guardados, calculadora ou simulador para captar lead, painel interno que lê uma planilha, protótipo clicável para aprovar uma ideia antes de pedir desenvolvimento, automação pequena que junta duas ferramentas.
Funciona com cuidado: qualquer coisa que guarde dado de pessoa. A seção de segurança explica por quê.
Não funciona: site de conteúdo que precisa ranquear. Não porque a ferramenta seja ruim, mas porque a estrutura, a velocidade e o controle de HTML que otimização de sites e SEO técnico descrevem saem mais fáceis e mais baratos de um CMS comum.
As ferramentas mais usadas, pela fonte com amostra que encontramos:
Ferramenta | Uso declarado |
|---|---|
ChatGPT | 81,7% |
GitHub Copilot | 67,9% |
Gemini | 47,4% |
Claude Code | 40,8% |
Microsoft Copilot | 31,3% |
Fonte: Stack Overflow Developer Survey 2025, mais de 49.000 respondentes. Não existe levantamento equivalente de 2026 por fonte neutra, então leia esses números como de 2025.
Para gerar aplicação inteira, a Lovable é a referência da categoria. Para trabalhar com mais controle sobre o código, Cursor e Claude Code atacam o mesmo problema por caminhos diferentes, e o Google Antigravity entrou nessa disputa depois.
Como fazer sem se machucar?
Cinco regras que saem direto da evidência das seções acima:
- Separe o que é descartável do que vai durar. Protótipo e teste interno podem ser vibe coding puro. O que vai receber tráfego e guardar dado precisa de alguém que leia o código.
- Trate permissão de banco como item obrigatório de conferência. É onde os dois incidentes públicos aconteceram, e é justamente o que não aparece na tela quando você testa.
- Não confie na sua sensação de velocidade. Se o objetivo é ganhar tempo, marque o tempo. O estudo do METR existe porque a percepção errou o sinal, não só a magnitude.
- Peça menos por mensagem. O relato mais comum na pesquisa do Stack Overflow é o código "quase certo", com 66%. Instrução grande produz erro grande, e depurar o que você não escreveu é mais lento do que escrever.
- Guarde o que funcionou. Como a refatoração despencou, o risco não é escrever mal, é acumular cinco versões do mesmo trecho sem perceber.
Conclusão
Vibe coding é programar descrevendo, sem ler o que saiu. A evidência disponível desenha um retrato consistente: quase todo mundo usa, quase ninguém confia, o código sai sintaticamente correto em mais de 95% das vezes e falha em segurança em cerca de 45%, e num ensaio controlado os desenvolvedores ficaram 19% mais lentos achando que estavam 20% mais rápidos.
Nada disso diz para não usar. Diz para separar o que é protótipo do que é produção, e para medir o tempo em vez de confiar na sensação.
O próximo passo, se você nunca construiu nada assim, é escolher uma tarefa pequena e descartável: uma calculadora que capta lead, um painel que lê uma planilha. O aprendizado vem do que quebra, e é melhor que quebre em algo que ninguém depende.
