O problema do vibe coding não tem nada a ver com IA

Uma demo funcional é o artefato mais perigoso do software. Passa no teste visual do stakeholder, roda no navegador, e se foi montada com alguns prompts e um assistente de IA, até parece profissional. O custo fica escondido sob a superfície — e só aparece quando os usuários reais chegam com escritas concorrentes, tráfego de produção e padrões de uso que nenhuma demo jamais antecipou. O verdadeiro problema do vibe coding não é a IA gerando o código. É a ausência de julgamento de engenharia revisando, moldando e assumindo a responsabilidade pelo que vai para produção.

O vibe coding disfarça fragilidade como produto finalizado

O termo surgiu no início de 2025 para descrever um fluxo de trabalho específico: dar um prompt a um assistente de IA, aceitar o que ele devolve com revisão mínima e repetir até que a aplicação pareça funcionar. Em poucos meses se tornou mainstream o suficiente para o Collins Dictionary elegê-lo como palavra do ano. A velocidade é real. A ilusão de completude que ele cria é ainda mais.

Para um observador não técnico, uma aplicação vibe-coded parece idêntica a uma construída por um time sênior de engenharia. Tem rotas, banco de dados, tela de login e uma URL de deploy. Mas o que existe por baixo costuma contar outra história: um schema de banco que colapsa com algumas centenas de registros, lógica de autenticação sem validação de inputs, chamadas de API que quebram sob tráfego concorrente, e zero logging, testes ou pipeline de deployment.

Percepção é o bug mais difícil de corrigir. A distância entre "funciona na minha máquina" e "funciona para mil usuários num sábado à noite" é onde a maioria dos projetos vibe-coded morre — silenciosamente, com custo alto, e sempre no pior momento possível.

Onde sistemas vibe-coded quebram em produção

Três categorias de falha explicam quase todo postmortem de vibe coding: segurança, escalabilidade e manutenibilidade. Cada uma potencializa as outras, e juntas formam um padrão que se repete com consistência notável entre times, stacks e indústrias.

Segurança: as vulnerabilidades que ninguém revisou

Entre 45% e 48% do código gerado por IA contém vulnerabilidades de segurança — um número que se manteve estável ao longo de auditorias independentes durante 2025 e 2026. Código co-escrito com IA introduz falhas de segurança a uma taxa aproximadamente 2.7 vezes maior que código escrito por humanos. Os padrões são previsíveis: API keys hardcoded enviadas ao cliente, validação de JWT pulada ou mal configurada, políticas de Row-Level Security que parecem corretas na superfície mas concedem acesso a todas as linhas da tabela.

O risco não é teórico. No início de 2026, uma aplicação vibe-coded construída sobre uma plataforma de IA popular expôs mais de 18.000 registros de usuários, incluindo contas de estudantes com prováveis menores de idade entre eles. A causa raiz foi uma política de RLS mal configurada — uma correção de cinco linhas que qualquer engenheiro experiente pegaria em code review, mas que ninguém revisou antes do deploy.

Quando segurança é tratada como algo que a IA vai resolver, a IA resolve do mesmo jeito que resolve todo o resto: estatisticamente, sem contexto e sem accountability.

Escalabilidade: a arquitetura que ninguém projetou

Assistentes de IA otimizam para o prompt imediato, não para o futuro do sistema. Produzem código que satisfaz o requisito atual sem consciência dos limites de conexão, planejamento de queries, estratégias de cache, nem da diferença de comportamento entre uma tabela com 50 linhas e uma com 500.000.

Schemas de banco gerados por prompts frequentemente não têm índices compostos, armazenam dados estruturados como blobs de JSON em colunas de texto e usam configurações padrão que esgotam o connection pool com tráfego moderado. A aplicação roda perfeitamente no ambiente de preview. Falha no primeiro pico de tráfego real — não com um erro claro, mas com uma cascata de timeouts de 30 segundos que se propaga por cada serviço que compartilha a mesma conexão com o banco.

O context drift agrava o problema. A maioria dos assistentes de IA perde coerência em codebases que passam de alguns milhares de linhas. Lá pelo arquivo sete ou oito, o modelo já esqueceu as decisões de arquitetura que tomou no arquivo dois. Novas sugestões contradizem as anteriores, e o sistema resultante se comporta menos como software projetado e mais como uma montagem acidental de fragmentos independentes.

Manutenibilidade: o código sem ownership

Uma aplicação vibe-coded tem uma propriedade incomum: a pessoa que colocou em produção não escreveu o código, e muitas vezes não entende ele por completo. Isso cria uma lacuna entre intenção e implementação que nenhuma quantidade de re-prompting consegue fechar depois.

Quando um bug aparece três meses depois, o engenheiro encarregado de resolver encontra convenções de nomes auto-geradas, padrões de arquitetura inconsistentes e fluxos de lógica que refletem a distribuição de treinamento do modelo em vez dos requisitos do domínio. Debugging vira arqueologia. Cada mudança introduz uma regressão porque as suposições implícitas no código nunca foram tornadas explícitas por um humano que as entendia.

Ownership não é um conceito de gestão — é um conceito de engenharia. Código sem dono é código que ninguém consegue modificar com segurança, e código que ninguém consegue modificar com segurança é código que apodrece.

A armadilha de velocidade que o vibe coding cria

Velocidade é a qualidade mais sedutora do vibe coding. Um protótipo funcional em horas. Uma feature por prompt. Um deploy antes do almoço. Mas a curva de aceleração é enganosa — parece exponencial no começo e bate numa parede lá pelo terceiro mês.

Times que constroem agressivamente com vibe coding reportam um padrão consistente: pela semana doze, a maior parte da capacidade do sprint é consumida não por features novas mas por regressões. Corrigir um componente gerado por IA quebra outro. O codebase cresceu além da janela de contexto do assistente, então novas sugestões entram em conflito com decisões que o modelo tomou em arquivos anteriores. O projeto chega no que alguns praticantes chamam de spaghetti point — o momento onde adicionar qualquer coisa nova custa mais do que recomeçar do zero.

A velocidade inicial nunca foi de graça. Foi emprestada contra tempo de engenharia futuro, e os juros compostos acumulam mais rápido do que qualquer um espera. Uma feature que levou trinta minutos de prompts pode levar uma semana inteira de debugging quando interage mal com o resto do sistema. Times que trataram a velocidade do primeiro mês como a linha de base descobrem, dolorosamente, que aquilo era a anomalia.

A IA é a ferramenta, não o problema

Nada disso é um argumento contra usar IA no desenvolvimento de software. Engenharia assistida por IA — onde um desenvolvedor usa IA para acelerar trabalho que entende, revisa e pelo qual se responsabiliza — é um multiplicador de produtividade genuíno. A distinção entre essa abordagem e o vibe coding importa muito mais do que as ferramentas específicas sendo usadas.

Um desenvolvedor que gera uma migration boilerplate com IA, depois revisa o SQL, adiciona o índice que faltava e testa o rollback, está praticando engenharia com ferramentas melhores. Um desenvolvedor que pede ao assistente "adiciona autenticação de usuários" e faz deploy do resultado sem ler, está praticando esperança com um teclado.

A IA produz rascunhos. A qualidade do produto final depende inteiramente do julgamento aplicado entre o rascunho e o deployment. Esse julgamento exige entender como um banco de dados se comporta sob carga, reconhecer padrões inseguros na lógica de autenticação e saber quando uma sugestão está sutilmente errada — habilidades que se desenvolvem ao longo de anos construindo, quebrando e consertando sistemas reais. A IA acelera as mãos. Não substitui a cabeça por trás delas.

Como é um desenvolvimento assistido por IA responsável

Sair do vibe coding para a engenharia assistida por IA com disciplina não significa abandonar a IA nem voltar a escrever cada linha na mão. Significa restaurar o julgamento de engenharia que o vibe coding pula.

• Revisar cada sugestão antes de aceitar. Não uma olhada rápida — uma revisão. Se você não consegue explicar o código gerado para um colega, não está pronto para colocar em produção.
• Ter ownership da arquitetura. A IA deveria implementar suas decisões de design, não tomá-las por você. Defina o schema, os limites dos serviços, a estratégia de tratamento de erros e o modelo de segurança antes do primeiro prompt.
• Testar o que importa. Testes automatizados pegam regressões antes dos usuários. Um projeto vibe-coded sem testes é um projeto que quebra silenciosamente uma vez atrás da outra.
• Adicionar logging e observabilidade desde o dia um. Se o comportamento da aplicação em produção é invisível, corrigir quando ela se comporta mal é chute. E ela vai se comportar mal.
• Tratar segurança como pré-requisito, não como feature. Validação de inputs, autenticação correta, armazenamento seguro de credenciais e políticas de autorização bem configuradas são a base de que tudo o mais depende. Nunca são uma melhoria para adicionar depois.

O que profissionais perguntam sobre vibe coding?

A linha entre vibe coding e engenharia assistida por IA gera perguntas práticas que aparecem repetidamente em times técnicos avaliando como incorporar IA aos seus fluxos de trabalho.

É aceitável usar vibe coding para protótipos descartáveis?

Para uma demo que nunca vai ver usuários reais nem lidar com dados reais, o vibe coding pode ser uma ferramenta de exploração útil. O risco começa quando o protótipo silenciosamente se gradua para produção sem ser reconstruído com práticas de engenharia adequadas. A postura mais segura é tratar protótipos vibe-coded como artefatos descartáveis — valiosos para validar ideias, nunca para entregar a usuários reais.

Scanners de segurança compensam as vulnerabilidades do vibe coding?

Scanners automatizados detectam padrões conhecidos: vulnerabilidades em dependências, vetores de injeção comuns, headers faltando. Não detectam falhas arquiteturais, políticas de autorização mal configuradas nem erros de lógica de negócio. Um scan limpo em uma aplicação vibe-coded não significa que a aplicação é segura. Significa que a cobertura do scanner tem limites que o codebase ainda não ultrapassou.

O vibe coding corrói o ownership da equipe ao longo do tempo?

A corrosão é gradual mas mensurável. Quando um time coloca em produção código que nenhum dos seus membros entende por completo de forma consistente, a capacidade coletiva de debugar, refatorar e estender o sistema se degrada mês a mês. Com o tempo, o time passa a depender da ferramenta de IA não só para construir features novas mas para entender as existentes — uma dependência que se quebra no momento em que a janela de contexto da ferramenta é excedida ou suas sugestões divergem das convenções implícitas do codebase.

Um ponto de vista oposto

Um argumento comum vai na direção contrária: velocidade de chegada ao mercado é tudo, e o vibe coding entrega isso. Em ambientes competitivos onde ser primeiro importa mais do que ser polido, entregar rápido e corrigir depois é uma estratégia racional. Dívida técnica é um trade-off aceitável quando a sobrevivência depende de alcançar usuários antes que o runway acabe.

O argumento se sustenta — até certo ponto. Para um founder solo validando uma hipótese com uma landing page e uma lista de espera, o trade-off pode fazer sentido. Mas desmorona no momento em que dados reais de usuários entram no sistema, no momento em que um segundo engenheiro se junta ao time, ou no momento em que a aplicação precisa lidar com sua 500a sessão concorrente. A velocidade que o vibe coding oferece na semana um se transforma na paralisia que trava o time na semana doze. Sobreviver exige entregar rápido, mas também exige entregar algo que continue funcionando quando os usuários realmente aparecerem.

O que vale a pena lembrar

• O vibe coding cria uma lacuna de percepção: aplicações parecem completas mas faltam as bases de engenharia que as mantêm rodando sob condições reais.
• Entre 45% e 48% do código gerado por IA vai para produção com vulnerabilidades de segurança, incluindo credenciais expostas, autorização mal configurada e validação de inputs ausente.
• A vantagem de velocidade inicial colapsa em questão de meses quando loops de regressão e dívida arquitetural consomem mais tempo do que o desenvolvimento de features novas.
• A IA é um multiplicador de engenharia legítimo quando combinada com revisão humana, ownership arquitetural e testes disciplinados.
• Código sem um dono humano — alguém que o entende e consegue modificá-lo com segurança — é código que eventualmente não pode mais ser mantido.
• Segurança, escalabilidade e observabilidade são pré-requisitos para produção, não features para adicionar depois do lançamento.

Conclusão

A conversa em torno do vibe coding costuma ser enquadrada como um debate sobre IA, mas no fundo é um debate sobre responsabilidade de engenharia. Ferramentas de IA estão melhorando num ritmo que vai fazer as limitações de hoje parecerem anedóticas dentro de alguns anos. O que não vai mudar é a necessidade de alguém entender o que vai para produção, assumir as consequências quando quebrar e tomar as decisões de arquitetura que determinam se um sistema sobrevive ao primeiro encontro real com usuários. A pergunta que vale a pena fazer não é se devemos usar IA — essa já foi respondida. A pergunta é se a pessoa apertando deploy entende o que está colocando no ar, e se está preparada para sustentar essa decisão quando a coisa apertar.