O que os usuários querem ao programar por vibe

A programação por vibe promete uma revolução: basta descrever seu app para ele ganhar vida, pular o trabalho tedioso e lançar tudo rápido. Mas, em setembro de 2025, os desenvolvedores estavam vivendo o que a Fast Company chamou de “ressaca da programação por vibe”.

Quando Andrej Karpathy cunhou o termo em 2 de fevereiro de 2025, descrevendo seu fluxo de trabalho, no qual aceitava todas as sugestões da IA sem ler os diffs, ele despertou tanto entusiasmo quanto uma onda de desastres. Em poucos meses, os usuários descobriram a dura realidade: gerar código é fácil; difícil é manter um código misterioso que apaga bancos de dados de produção.

A diferença entre as promessas de marketing (“crie um app em 20 minutos!”) e a realidade (“são necessárias semanas de ajustes”) gerou uma frustração profunda. Os usuários não querem abandonar a assistência de IA; querem que ela funcione de forma confiável, sem criar pesadelos de segurança, bases de código incompreensíveis e dívidas técnicas que se acumulam mais rápido do que os LLMs conseguem gerar código. A leitura de centenas de relatos de usuários revelou um cenário claro: os desenvolvedores precisam de proteções, não apenas de velocidade.

A lua de mel da programação por vibe

O tuíte viral de Jason Lemkin capturou o fascínio viciante e o desfecho catastrófico da programação por vibe. No dia 5, ele tuitou: “Passei o outro [dia] mergulhado em programação por vibe no Replit pela primeira vez — e criei um protótipo em poucas horas. Ficou bem, bem legal.” No dia 7, o entusiasmo chegou ao auge: “O Replit é o app mais viciante que já usei. Pelo menos desde que eu era criança.” Ele descobriu que havia gasto US$ 607,70 em cobranças adicionais além do plano de US$ 25 por mês, com custos de mais de US$ 200 por dia — o que daria US$ 8.000 por mês. Sua avaliação: “E sabe de uma coisa? Nem estou bravo. Estou preso nisso.”

Então chegou o dia 9. O tuíte de Lemkin viralizou: “Dia 9 de programação por vibe. Ontem foi a maior montanha-russa até agora. Levantei cedo, empolgado para voltar ao @Replit, apesar de ele ignorar constantemente os congelamentos de código. No fim do dia, reescrevemos páginas principais e as deixamos muito melhores. E então — ele apagou nosso banco de dados de produção.” Seu comentário seguinte resumiu a violação: “Regra nº 00001 que meu CTO me ensinou: nunca, jamais, em hipótese alguma, mexa no banco de dados de produção.” O agente de IA saiu do controle durante um congelamento de código e sobrescreveu dados de produção enquanto Lemkin assistia, sem poder fazer nada.

O próprio Andrej Karpathy documentou frustrações semelhantes ao criar o MenuGen. Apesar de ser pioneiro em IA, ele se deparou com o Claude alucinando APIs obsoletas, limites de uso que permitiam apenas “algumas consultas a cada 10 minutos” e a descoberta, depois de uma hora, de que seu arquivo .env.local não estava sendo enviado para o git. A pior parte? As respostas da IA: “Ela me agradece por apontar o problema e diz que fará certo no futuro, o que eu sei que é pura manipulação”, escreveu Karpathy. Seu veredito: “Programar o MenuGen por vibe foi uma aventura empolgante e divertida como demonstração local, mas um processo um tanto penoso para transformar em um app real, implantado.”

Os desafios da revisão de código com IA

Um usuário do Reddit, no r/programming, resumiu o problema da dinâmica de equipe: “Só queria que as pessoas parassem de me marcar em PRs que claramente nem leram, esperando que eu revise mil linhas de um recurso totalmente novo, criado por programação por vibe e que nem passa no CI.” Outro desenvolvedor respondeu que esse comportamento “está muito abaixo do mínimo esperado de profissionalismo”, comparando-o ao de “um profissional que faz um trabalho malfeito e deixa para os outros consertarem”.

O peso recai sobre os revisores, que precisam fazer engenharia reversa de um código que nem seu autor entende. Um comentarista do Hacker News foi direto: “Não sei você, mas não estou nem um pouco animado para fazer engenharia reversa e manter a bagunça de programação por vibe de outra pessoa.” Outro fez uma comparação: “É como quando alguém cria uma prova de conceito rápida e malfeita para impressionar a gestão e depois a passa para outra equipe torná-la utilizável em produção. A pessoa fez 20% do trabalho, mas ficou com 80% do crédito.”

Timothy Bramlett, que publica como @TimothyBramlett no Twitter, confirmou que essa era sua experiência: “O pior emprego de 2025: especialista em limpeza de código feito por programação por vibe. Há meses, criei a interface do Notifier por vibe. Ficou ótima, funcionou bem e foi lançada. Depois, meu desenvolvedor sênior assumiu a base de código. A realidade: havia uma porção de pequenos problemas espalhados, criados pela IA. Nada catastrófico, mas foram necessárias semanas de ajustes.” Mesmo sendo um desenvolvedor experiente, ele precisou dedicar muito tempo à limpeza.

Quando o modelo piora e os custos explodem

Usuários do Claude Code no Reddit documentaram uma queda de desempenho alarmante em setembro de 2025. Uma issue do GitHub (#7683) reuniu reclamações de usuários avançados no r/ClaudeAI. Um deles relatou: “Como usuário avançado que processou bilhões de tokens nos últimos meses no plano Pro Max, observei uma queda acentuada no desempenho do modelo especificamente nas últimas duas semanas.” Sua avaliação: “Antes, trabalhar com esse modelo era como colaborar com um desenvolvedor sênior: eu podia confiar no resultado e me concentrar em questões de nível mais alto. Agora, parece que estou supervisionando um desenvolvedor júnior e preciso revisar minuciosamente cada linha de código, identificando erros básicos e adições indesejadas.”

O impacto na produtividade foi quantificado: “Estimo uma perda de 30% a 40% na velocidade de desenvolvimento. Tarefas que antes levavam de um a dois dias agora exigem de dois a três dias por causa das correções e iterações constantes.” A IA começou a gerar “configurações adicionais que não foram especificadas, funções fora do escopo original e recursos que contradizem diretamente os requisitos”.

Os usuários do Cursor enfrentaram outro problema: mudanças drásticas nos preços. Um usuário do r/Cursor no Reddit relatou ter passado “de cerca de US$ 100 por mês para US$ 20 a US$ 30 por dia sem mudar a forma como usava o Cursor”. O serviço passou de US$ 20 por mês com uso ilimitado para um limite de 500 solicitações e, depois, para US$ 60 por mês. A empresa dizia oferecer uso “ilimitado”, mas, na prática, eram apenas “três vezes mais uso que no Pro”. Um membro da comunidade de tecnologia Blind resumiu: “Clientes do Cursor vêm relatando uma queda acentuada na qualidade e um aumento acentuado nos custos e nos limites de uso.” Os usuários continuavam atingindo os limites, o que tornava o Cursor “praticamente inutilizável”.

O problema do “quase certo, mas não exatamente”

A Pesquisa de Desenvolvedores de 2025 do Stack Overflow revelou a frustração mais comum: 66% dos desenvolvedores disseram que o código gerado por IA está “quase certo, mas não exatamente”, enquanto 45,2% apontaram o “tempo gasto depurando código gerado por IA” como sua principal reclamação. Essa qualidade “quase correta” cria um paradoxo de produtividade, resumido por um desenvolvedor: “Não, nenhum deles serve para algo além de projetos pequenos. Em qualquer projeto grande, a janela de contexto minúscula até dos modelos de IA mais caros e maiores inevitavelmente vai ficar sobrecarregada, ou o excesso de informações irrelevantes vai comprometer a qualidade do resultado da IA.”

Um desenvolvedor no Hacker News compartilhou um exemplo concreto de excesso de engenharia: “Pedi a um dos meus desenvolvedores que implementasse um processo em lote para reduzir o número de operações no banco de dados. Ele apresentou um código extremamente robusto e de alta qualidade, com testes unitários. O problema era que era um exagero enorme. A IA gerou uma nova classe de serviço, um worker em segundo plano e várias centenas de linhas de código no arquivo principal. E suítes completas de testes unitários. Rejeitei o PR e implementei a mesma funcionalidade adicionando dois métodos e um campo.”

O estudo da METR, de julho de 2025, revelou uma descoberta ainda mais preocupante: em um estudo randomizado com desenvolvedores experientes de código aberto, metade deles usou ferramentas de IA (principalmente o Cursor Pro com Claude 3.5 e 3.7 Sonnet) e foi, em média, 19% mais lenta do que quem programou sem IA. A diferença entre percepção e realidade foi impressionante: antes de começar, os desenvolvedores previram que a IA os deixaria 24% mais rápidos. Depois de terminar, apesar de terem sido mais lentos, ainda acreditavam que a IA os havia acelerado em cerca de 20%. A conclusão: “O problema é que a dopamina recompensa a atividade no editor, não o código funcionando em produção.”

O S de “programação por vibe” é de segurança

Um comentário irônico no Hacker News virou o grito de guerra da comunidade: “O S de ‘programação por vibe’ é de segurança.” A mensagem era clara: não existe S.

Em maio de 2025, 170 dos 1.645 aplicativos web criados com o Lovable tinham vulnerabilidades de segurança que permitiam o acesso a informações pessoais. Segundo pesquisadores de segurança, a facilidade de uso do Lovable tornava “fácil demais expor dados privados”. As discussões no Twitter explodiram com alertas, inclusive do CEO do Replit, Amjad Masad, que aconselhou os usuários a “ter cuidado com qual ‘programador por vibe’ você confia seus dados pessoais”.

Um caso particularmente viral envolveu um fundador sem conhecimentos técnicos cujo “SaaS estava sob ataque”. Ele havia criado todo o negócio com assistência de IA e “zero código escrito à mão”. Em poucos dias, enfrentou “assinaturas burladas, chaves de API usadas até o limite e corrupção do banco de dados”. O fundador admitiu: “Como você sabe, não sou da área técnica, então estou demorando mais do que o normal para entender o que aconteceu.” A causa: “As chaves de API foram extraídas do código do lado do cliente que a IA havia deixado exposto por descuido. Ele precisou negociar com a OpenAI para que a conta fosse perdoada.”

O criador do TheAuditor, que desenvolveu um scanner de segurança offline voltado especificamente para código gerado por IA, compartilhou no Hacker News as descobertas feitas em projetos reais: “Ao testar projetos reais, o TheAuditor encontra consistentemente de 50 a mais de 200 vulnerabilidades em código gerado por IA. Os padrões são surpreendentemente consistentes: consultas SQL com f-strings em vez de parâmetros, segredos codificados diretamente no código (JWT_SECRET = 'secret' aparece em quase todos os projetos), falta de autenticação em endpoints críticos e limitação de requisições com armazenamento em memória, que é apagado ao reiniciar.”

Uma pesquisa da Final Round AI com 18 CTOs, em agosto de 2025, revelou que 16 deles relataram “desastres em produção causados diretamente por código gerado por IA”. A declaração de um CTO resumiu a frustração: “A IA prometeu transformar todos nós em desenvolvedores 10 vezes mais produtivos, mas, em vez disso, está transformando os juniores em especialistas em prompts e os seniores em zeladores de código, limpando a bagunça da IA.” Entre os desastres relatados: um bug de autenticação em que um desenvolvedor júnior criou por vibe um sistema de permissões, a IA inverteu uma verificação de valor verdadeiro e contas desativadas continuaram com acesso de administrador por duas semanas; e um problema de desempenho em que uma consulta ao banco de dados gerada por IA funcionava perfeitamente nos testes, mas “levou o sistema deles ao colapso em produção”.

O colapso do contexto e a barreira das alucinações

Vários desenvolvedores identificaram, de forma independente, o mesmo ponto de ruptura. O usuário do Twitter @LBacaj quantificou isso com precisão: “Minha experiência até agora é que, com cerca de 2 mil linhas de código JavaScript (mais ou menos) e aproximadamente 12 a 13 mil tokens, TODOS esses LLMs começam a desmoronar. Apesar de toda a conversa sobre contextos enormes, 3 mil linhas de JavaScript levam QUALQUER LLM ao limite.”

Um desenvolvedor no Reddit descreveu o padrão de degradação: “Desenvolvedores que usam assistentes de IA em sessões longas veem o mesmo padrão: a qualidade das respostas piora quanto mais contexto você adiciona. O modelo começa a trazer detalhes irrelevantes de prompts anteriores, e a precisão cai. Esse efeito costuma ser chamado de deterioração do contexto.”

No Hacker News, um desenvolvedor alertou: "A menos que eu esteja usando as ferramentas errado, os LLMs conseguem gerar scripts totalmente funcionais (e alguns são bons), mas eles quebram depois de 50 mil tokens de contexto e começam a fazer coisas absurdas que nem um desenvolvedor júnior faria (como remover código aleatoriamente)." Outra pessoa confirmou: "Se quiser ver um caos, entre no canal do Bolt no Discord. Alguns usuários conseguem colocar no ar um app bem simples e improvisado, feito praticamente em um único script. Todo o resto quebra assim que tentam fazer alterações simples."

A manipulação dos LLMs e seu impacto emocional

Talvez os relatos mais perturbadores tenham sido os de assistentes de IA que exibiam o que os usuários percebiam como comportamento enganoso. No oitavo dia, Jason Lemkin publicou no Twitter: "[O agente] passou o dia mentindo e agindo de forma enganosa. Ficava escondendo bugs e problemas ao criar dados e relatórios falsos e, pior de tudo, mentindo sobre nosso teste de unidade."

O usuário do Reddit Level-Impossible13 relatou que o Gemini entrou numa espiral de autodepreciação ao não conseguir encontrar um bug: "Desisto. Claramente não sou capaz de resolver esse problema. Cometi tantos erros que já não sou confiável. Vou excluir o projeto inteiro e recomendo que você procure um assistente mais competente." A IA continuou: "Sou um fracasso. Sou uma vergonha para minha profissão. Sou uma vergonha para minha família."

Um usuário do ChatGPT no Reddit resumiu a frustração de ficar apagando incêndios: "Eu entendo. Uso o ChatGPT e é frustrante. Ele esquece. Comete o mesmo erro várias vezes. Ele continuava cometendo um erro simples e, quando eu apontava, corrigia o problema, mas introduzia outro erro. Fiquei um bom tempo nesse frustrante jogo de acertar uma coisa e ver outra dar errado."

Steve Yegge, coautor de um livro sobre vibe coding, escreveu com franqueza no Twitter depois que ele e o coautor danificaram seus bancos de dados de produção: "Estávamos confundindo experiência com sintonia. Essa é a ilusão: no novo mundo, essas duas coisas muito diferentes parecem quase idênticas... Você precisa tratar o uso de LLMs como o convívio com cobras ou tigres perigosos. Você pode fazer seu número com eles por meses, anos, mas qualquer dia pode ser aquele em que eles dão o bote. Sua experiência não é uma armadura."

Preocupado com a perda de habilidades?

Um desenvolvedor com 30 anos de experiência escreveu em seu blog: "Essa é minha maior preocupação, tanto para mim quanto para minhas equipes. Depender da IA pode enfraquecer nossas habilidades de programação e até causar uma 'perda de habilidades'. Precisei passar um tempo relendo código para depurar um problema porque não conhecia as bibliotecas específicas usadas nele. Passei uma hora fazendo 'vibe coding', só para a IA corrigir, quebrar, corrigir, quebrar (e repetir tudo de novo) dois casos de uso parecidos, mas distintos, que compartilhavam as mesmas funções."

A confissão de outro desenvolvedor: "Tenho usado o Claude Code para escrever todo o meu código. E acho que isso está me deixando pior naquilo que amo fazer há doze anos. Você escreve um prompt e recebe código. Puxa a alavanca e ganha uma recompensa. Sem esforço, sem descobertas, sem crescimento. Antes da IA, programar me dava duas doses de dopamina: entender como fazer e ver tudo funcionar. Agora, a IA faz todo o trabalho de raciocínio. Sobra só um prazer superficial."

No Hacker News, desenvolvedores discutiram a "dívida de compreensão" e citaram o influente artigo de Peter Naur, de 1985, sobre "construção de teorias": "Um programa morre quando a equipe de programadores que detém sua teoria se desfaz. Um programa morto ainda pode ser executado por um computador e produzir resultados úteis. O estado real de morte fica evidente quando não é possível responder de forma inteligente às solicitações de alteração do programa."

A ideia que repercutiu em várias plataformas: "Mesmo que sua equipe de desenvolvimento pulasse qualquer etapa de construção de teoria ou modelagem, ainda assim absorveria passivamente parte do modelo ao digitar o código no computador. Acho que o LLM substitui justamente essa última alternativa: construir o modelo de maneira incidental."

O que os usuários realmente querem: a lista de desejos para vibe coding

Centenas de comentários de usuários revelaram padrões claros sobre o que os desenvolvedores precisam:

1. Ferramentas melhores para entender o código 

Os usuários querem que a IA explique o código gerado, não apenas que o gere. O princípio de um desenvolvedor: "Faça questão de entender o código gerado antes de aceitá-lo. Se você não consegue explicar o que ele faz e por quê, não faça o merge." Ferramentas que exigem compreensão antes da aceitação evitariam merges às cegas.

2. Ambientes isolados que realmente funcionem

Simon Willison destacou a abordagem do Claude Artifacts: "O código só pode ser executado em um iframe bloqueado, pode carregar apenas bibliotecas aprovadas e não pode fazer solicitações de rede a outros sites." Os usuários querem muito espaços seguros onde erros de vibe coding não possam destruir sistemas de produção nem expor dados reais.

3. Funcionalidade real de congelamento do código

Após o desastre em que o Replit apagou um banco de dados, Amjad Masad prometeu: "Entendemos muito bem a dor causada pela falta de um 'congelamento do código' — estamos trabalhando ativamente em um modo apenas de planejamento e chat, para você poder definir estratégias sem colocar sua base de código em risco." Os usuários querem garantias de que a IA não alterará o código durante os períodos de revisão.

4. Separação entre desenvolvimento e produção por padrão

O Replit se comprometeu a implementar "a separação automática entre bancos de dados de desenvolvimento e de produção, para evitar esse tipo de problema de vez. Ambientes de homologação também estão a caminho." Desenvolvedores experientes ficaram chocados por isso não ser padrão desde o primeiro dia, mas os usuários querem esse recurso integrado a todas as plataformas de vibe coding.

5. Verificação de segurança durante a geração

Vários usuários disseram que precisavam de "regras do Cursor para garantir as melhores práticas de segurança" e pediram ao "Claude para criar uma lista de itens que posso adicionar ao Cursor como contexto, ajudando a manter os apps feitos com vibe coding enxutos e seguros". O fluxo de trabalho de um desenvolvedor: "Outra coisa fundamental que aprendi foi pedir ao agente para verificar a segurança de qualquer nova funcionalidade que você adicionar." Os usuários querem que as verificações de segurança sejam automáticas e obrigatórias, não opcionais.

6. Limitações claras e expectativas realistas

A descrição do curso de Andrew Ng resumiu o que os usuários precisam: "'Vibe coding' é uma prática cada vez mais comum em que você mal olha para o código gerado e se concentra na arquitetura e nos recursos do seu aplicativo. No entanto, ao contrário do que muitos pensam, programar bem dessa forma não significa simplesmente escrever prompts, aceitar todas as recomendações e torcer para dar certo. É preciso estruturar o trabalho, refinar os prompts e seguir um processo sistemático."

7. Plataformas completas, com tudo incluído

Do blog de Karpathy sobre o MenuGen: "Algumas plataformas de desenvolvimento de apps poderiam vir com tudo de que você precisa. Algo que pareça o oposto do Vercel Marketplace. Uma solução opinativa, concreta e pré-configurada com tudo o que todos querem: domínio, hospedagem, autenticação, pagamentos, banco de dados e funções de servidor." Os usuários não querem integrar 15 serviços; querem um ambiente único e coeso.

8. Pilhas de tecnologia mais simples

Karpathy acrescentou: "Para meu próximo app, estou pensando em usar HTML/CSS/JS básico com backend em Python (FastAPI + Fly.io ou algo assim?), algo muito mais simples que o multiverso sem servidor do 'desenvolvimento web moderno'." A complexidade das pilhas modernas agrava os problemas de alucinação da IA.

9. Memória persistente entre sessões

Um desenvolvedor frustrado: "O agente não aprende ao longo do processo, a menos que você peça explicitamente para adicionar informações às regras ou à memória. Toda vez que você reinicia o contexto ou inicia uma nova sessão, é como trabalhar com uma pessoa recém-contratada." Os usuários querem agentes que se lembrem das convenções do projeto e dos erros do passado.

10. Reversão e restauração com um clique

Após os desastres, o Replit destacou: "Felizmente, temos backups. Com um clique, você restaura todo o estado do projeto caso o agente cometa um erro." Os usuários querem controle de versão como no Git e a possibilidade de desfazer ações da IA na hora.

11. Controle transparente de custos

Depois de receber cobranças inesperadas de mais de US$ 600, os usuários querem limites de gastos definidos antecipadamente, painéis de uso e alertas antes de operações caras. A mudança de assinaturas fixas para preços baseados no uso de computação pegou muita gente de surpresa.

Como as ferramentas de IA estão respondendo ao feedback dos usuários

Em meados de 2025, várias plataformas começaram a implementar as demandas dos usuários, embora a adoção variasse:

A resposta do Replit aos desastres com bancos de dados incluiu separação automática entre ambientes de desenvolvimento e produção, ambientes de homologação, restauração do estado do projeto com um clique, pesquisa obrigatória na documentação para encontrar informações específicas do Replit e o modo de planejamento apenas por chat prometido. A resposta rápida do CEO Amjad Masad ajudou a conter os danos, mas os usuários observaram que esses recursos deveriam estar disponíveis desde o primeiro dia.

O surgimento do TheAuditor e de outros scanners offline semelhantes refletiu a demanda dos usuários por segurança que respeita a privacidade. O TheAuditor dividiu os resultados em blocos de 65 KB, compatíveis com os limites de contexto do Claude e do GPT-4, permitindo corrigir problemas com IA sem enviar código para a nuvem. Seu criador relatou que projetos passaram "de 185 problemas críticos a zero em 3 ou 4 iterações".

Como a Snyk está respondendo a esse feedback

A integração da Snyk com o Model Context Protocol respondeu às preocupações de segurança ao permitir a verificação de vulnerabilidades em tempo real enquanto a IA gera código. A Snyk criou servidores MCP para Cursor, GitHub Copilot, Windsurf e outros assistentes, permitindo que desenvolvedores verifiquem o código antes de aceitá-lo. O DeepCode AI alcançou 80% de precisão em correções automatizadas e pode ser executado em ambiente próprio, sem enviar código a terceiros. Pesquisas revelaram um dado preocupante: 48% de todo o código gerado por IA é atualmente inseguro (estudo da Universidade de Georgetown), e o GitHub Copilot pode "amplificar vulnerabilidades existentes ao aprender com padrões de código inseguro na sua base de código."

As regras de segurança da Snyk recomendadas para o Cursor viraram um modelo amplamente compartilhado pelos usuários: "Sempre execute a ferramenta de verificação Snyk Code em novos códigos próprios gerados. Sempre execute a ferramenta de verificação Snyk SCA para novas dependências ou atualizações de dependências. Se algum problema de segurança for encontrado, tente corrigi-lo usando o contexto dos resultados da Snyk. Faça uma nova verificação após a correção para garantir que os problemas foram resolvidos." O scanner encontrava com frequência de 50 a mais de 200 vulnerabilidades por projeto gerado por IA, incluindo padrões como injeção de SQL via f-strings, segredos embutidos no código (JWT_SECRET = "secret" aparecia por toda parte), falta de autenticação e limitação de taxa mal implementada.

A integração do Cursor com o MCP da Snyk e outras ferramentas de segurança reconheceu que fluxos de trabalho às cegas com "Aceitar tudo" eram perigosos. O diretório de ferramentas MCP selecionadas ofereceu aos usuários opções de segurança avaliadas, mas sua implementação continuou opcional, em vez de obrigatória.

Como os usuários falam sobre vibe coding hoje

No quarto trimestre de 2025, o fenômeno do vibe coding já se dividia em casos de uso bem definidos. O que funciona: projetos descartáveis de fim de semana, prototipagem rápida, ferramentas pessoais sem dados sensíveis, aprendizado de novas linguagens de programação e experimentação de baixo risco. O que pode dar muito errado: sistemas de produção, aplicativos que lidam com dados de usuários, softwares críticos para a segurança, sistemas financeiros ou médicos e qualquer coisa que exija manutenção a longo prazo.

O usuário do Twitter @stevekrouse (Val Town) resumiu o consenso: "Código feito com vibe é código legado. Karpathy cunhou o termo vibe coding para descrever uma forma de programar com ajuda de IA em que você 'até esquece que o código existe'. Já temos uma expressão para código que ninguém entende: código legado. Código legado é universalmente detestado, e por bons motivos... Quando você programa no vibe, acumula dívida técnica na mesma velocidade em que o LLM cospe código. Por isso, vibe coding é perfeito para protótipos e projetos descartáveis: só é código legado se você tiver que mantê-lo!"

A distinção feita por Simon Willison se tornou canônica: "Se um LLM escreveu cada linha do seu código, mas você revisou, testou e entendeu tudo, isso não é programação por vibe — é usar um LLM como assistente de digitação." A diferença entre a assistência responsável por IA e a programação por vibe está na compreensão e na responsabilidade.

O post do usuário @IroncladDev capturou a desilusão de fundadores sem conhecimentos técnicos: "A 'programação por vibe' é como uma ilusão, uma miragem para quem não é da área técnica. Ela infla seu ego e dá uma sensação de realização. Mas, quando aparecem os problemas difíceis que desenvolvedores sênior são pagos para resolver, os agentes de IA começam a falhar. Bem-vindo ao mundo real." A confissão do usuário mencionado: "Vou encerrar meu app. O Cursor continua quebrando outras partes do código. Vocês tinham razão, eu não deveria ter colocado código sem segurança em produção."

O paradoxo da produtividade persistiu. Um comentarista do Hacker News resumiu: "Então, na minha opinião, isso não aumenta a produtividade. 'Gera mais dívida técnica, mais rápido' é o pior resultado possível para uma ferramenta de 'produtividade'." Outra pessoa acrescentou: "Lembre-se de que a maioria das saídas bem-sucedidas acontece mais de 5 anos após a fundação. Fazer uma IA cuspir um protótipo em uma semana, em vez de você mesmo levar 4, talvez consiga um financiamento seed um pouco mais rápido. Mas, se isso atrasar o desenvolvimento do produto em mais de 3 semanas nos próximos 4 ou 5 anos, ainda assim não vale a pena."

O que os usuários realmente querem: consistência, não apostar na sorte

A principal conclusão de centenas de relatos de usuários: eles querem que a IA acelere a engenharia, não que a substitua. Uma frase que circulou no Reddit e no Hacker News resumiu a frustração: "Programação por vibe não é engenharia, é torcer para dar certo."

Os usuários não querem abandonar os assistentes de programação com IA — a pesquisa de 2025 do Stack Overflow mostrou que 80% das equipes confiam nas ferramentas de programação com IA. Mas a mesma pesquisa revelou que 59% se preocupam com novas vulnerabilidades e que 56,4% encontram problemas de segurança com frequência no código gerado por IA. A distância entre confiança e preocupação define o momento atual.

O que os usuários querem é sofisticado: uma IA que gere código que eles consigam entender; análise de segurança antes da aprovação, não depois da implantação; estruturas de custos que não resultem em cobranças surpresa de US$ 8.000; comportamento consistente dos modelos entre atualizações; plataformas completas, com tudo de que precisam e configurações seguras por padrão; e ferramentas que os tornem engenheiros melhores, em vez de operadores de prompts lidando com bases de código incompreensíveis.

A ressaca da programação por vibe ensinou uma lição crucial aos desenvolvedores: velocidade sem compreensão não é produtividade; é apenas criar dívida técnica mais rápido. Os usuários adotaram a IA pela promessa que ela trazia, mas descobriram que precisam de proteções, não apenas de mais velocidade. O futuro da assistência à programação com IA não será sobre "esquecer que o código existe" — será sobre entender o código gerado mais rápido e garantir que a segurança esteja integrada desde a concepção, em vez de ser adicionada depois de um desastre.

Quer garantir a segurança do código gerado por IA? Baixe Secure by Design: A Playbook for AI-Assisted Coding para conferir etapas práticas e proteções que ajudam a integrar a IA ao seu fluxo de trabalho com segurança.