Vibe coding virou uma daquelas expressões que entram na área de TI pela porta da frente e, em duas semanas, já estão em call de produto, pitch de startup e discussão de LinkedIn.
A ideia parece simples: você descreve o que quer, a IA escreve o código, você ajusta a rota por prompt e o produto anda. Para protótipo, ferramenta interna pequena e experimento pessoal, isso pode ser ótimo. O problema começa quando essa mesma lógica é vendida como substituta direta de engenharia.
Porque uma coisa é a IA gerar código. Outra bem diferente é alguém conseguir responder: isso está correto, seguro, sustentável e compatível com o resto do sistema?
O ponto não é demonizar a IA
O melhor argumento contra o uso irresponsável de IA no código não vem de quem odeia IA. Vem justamente de quem está usando bastante.
Um texto recente no Dev.to, bastante comentado, separa três situações que muita gente mistura como se fossem a mesma coisa: vibe coding, código gerado por IA com revisão humana e desenvolvimento assistido por IA. A diferença parece pequena, mas muda tudo.
No vibe coding puro, a pessoa descreve o resultado e aceita a saída sem entender ou revisar de verdade. No código gerado com revisão, a IA pode até escrever quase tudo, mas alguém lê, recusa, ajusta a direção e assume a responsabilidade. No desenvolvimento assistido, a IA entra como acelerador: sugere, completa, explica, ajuda a enxergar caso de borda, mas não dirige sozinha.
Essa distinção é importante porque o problema não é usar IA para programar. O problema é chamar qualquer coisa que compila de engenharia.
Onde a IA brilha de verdade
Tem muito ganho real aqui. Gerar boilerplate, criar CRUD básico, montar componente repetitivo, escrever validação comum, sugerir teste inicial, explicar erro chato e acelerar scaffolding são usos excelentes.
Outro relato no Dev.to foi além: o autor passou 30 dias deixando a IA escrever 100% do código de uma aplicação real, com autenticação, billing, dashboard e API pública. O resultado não foi “IA inútil” nem “dev acabou”. Foi mais interessante: o começo voou, especialmente em projeto greenfield, mas os problemas apareceram quando o sistema deixou de ser um conjunto de arquivos soltos e virou produto.
Esse é o ponto que muita propaganda pula. A IA costuma ser muito boa no trecho local. Ela entende bem o arquivo aberto, o padrão óbvio, a função parecida com mil exemplos públicos. Só que produto real não vive só no arquivo aberto.
O que quebra é o contexto
O primeiro risco é o drift de arquitetura. A IA cria um helper novo porque não percebeu que já existia outro. Reimplementa uma checagem de permissão que deveria passar pelo middleware. Gera um tipo parecido, mas não igual, ao tipo usado no resto do projeto. Nada disso parece dramático no pull request isolado. O estrago aparece quando a base começa a ficar cheia de soluções paralelas.
O segundo risco é o código plausível. Aquele que parece certo, passa no caminho feliz e só falha em cenário que ninguém testou. Esse tipo de erro é pior do que um crash óbvio, porque dá confiança falsa.
O terceiro risco é operacional. Sistema de produção tem log, fila, concorrência, cache, permissão, dado legado, deploy, rollback, custo de nuvem e cliente esperando. Quando algo quebra nesse ambiente, não basta pedir para a IA “melhorar a vibe”. Alguém precisa saber investigar.
O benchmark brasileiro aponta a mesma direção
A GeekHunter publicou um texto sobre os limites do vibe coding com uma leitura parecida: IA acelera muito a criação, mas não substitui visão de arquitetura, segurança, performance e governança técnica.
Essa parte é especialmente importante para times no Brasil, onde muita empresa já está pressionando área técnica a “entregar mais com IA” antes de entender o custo de manter aquilo depois. Se o incentivo vira só velocidade, a IA pode acabar acelerando também o débito técnico.
Não é muito diferente de copiar solução do Stack Overflow sem entender. A diferença é que agora a cópia vem personalizada, confiante e em volume industrial.
Quando vibe coding faz sentido
Para experimento, protótipo, automação pessoal e ferramenta descartável, vibe coding pode ser uma delícia. Você valida uma ideia rápido, aprende uma API, monta uma tela, testa um fluxo e segue a vida.
Também pode ser útil para profissionais experientes que sabem ler o que está sendo gerado. Nesse caso, o nome talvez nem seja vibe coding. É uso de IA como braço extra, com uma pessoa técnica conduzindo.
O limite aparece quando o código mexe com dinheiro, dado de usuário, permissão, contrato, operação crítica ou reputação da empresa. Aí não dá para terceirizar o julgamento junto com a digitação.
Um checklist simples antes de confiar
Se a IA gerou uma parte importante do código, vale passar por algumas perguntas antes de mandar para produção:
- eu entendo por que essa solução funciona?
- ela reaproveita os padrões do projeto ou inventa outro caminho?
- os testes cobrem erro, permissão, limite e caso estranho?
- o código lida bem com dados inválidos ou entrada maliciosa?
- alguém conseguiria debugar isso daqui a três meses?
- se der problema em produção, eu sei por onde começar?
Se a resposta honesta for “não sei”, o ganho de velocidade talvez tenha virado dívida disfarçada.
A habilidade que ficou mais valiosa
O paradoxo é que quanto melhor a IA escreve código, mais importante fica saber revisar código.
Antes, muito tempo do dev ia embora digitando a solução. Agora, parte desse tempo migra para especificar melhor, avaliar saída, enxergar risco, testar comportamento, manter coerência e decidir o que não deve ser aceito. Isso não é menos engenharia. É engenharia em outro ponto do fluxo.
Quem só aprende a pedir código pode até ganhar velocidade no começo. Quem aprende a dirigir, revisar e limitar a IA tende a ganhar algo mais útil: alavancagem sem entregar o volante.
No fim, vibe coding não precisa ser vilão. Ele só não deveria usar crachá de engenharia quando ninguém está fazendo a parte de engenharia.
