Vibe coding em 2026: a ressaca chegou, e quem paga a conta

Em janeiro de 2025, vibe coding parecia magia. Protótipo em 3 horas. Sistema “funcional” em uma semana. Custos zero de desenvolvimento.

Em junho de 2026, a conta chegou.

Não chegou pra todo mundo ao mesmo tempo. Chegou silenciosamente, da forma que dívida técnica sempre chega — no bug que ninguém consegue explicar, no cliente que reclamou que viu dado que não era dele, no dev júnior que saiu e levou o “conhecimento” do sistema junto.

Esse post é pra quem está vivendo esse momento. Ou pra quem quer não viver.

Em 2026, a Cloud Security Alliance documentou que vulnerabilidades CVE em código gerado por IA subiram de 6 (janeiro) para 15 (fevereiro) e 35 (março) — escalada exponencial em 90 dias. Empresas que entregaram software com vibe coding sem revisão profissional estão pagando esse débito agora, em bugs críticos, vazamento de dados por RLS ausente e custos descontrolados. O plano de mitigação em 3 fases (auditoria de segurança, refactor crítico e migração estratégica) cabe em 8 a 12 semanas. Em 20 a 25% dos casos a resposta honesta é “tá ok, segura por mais 6 meses” — mas isso só aparece depois de auditar.

O que mudou em 2026: a escalada de CVE em código IA gerado

Vamos a dados concretos antes de qualquer opinião.

A Cloud Security Alliance publicou em 2026 uma research note documentando a curva de vulnerabilidades em código gerado por IA. Os números são diretos:

• Janeiro de 2026: 6 CVEs registrados em código IA gerado
• Fevereiro de 2026: 15 CVEs
• Março de 2026: 35 CVEs

Escalada de 6 para 35 em 90 dias. Não é pico pontual — é tendência com aceleração.

Mas o que explica? Duas coisas aconteceram em paralelo:

Primeiro, o volume de código IA gerado em produção explodiu. O que em 2024 era experimento vira rotina em 2025. O que em 2025 era protótipo vira “sistema oficial” em 2026. Mais código em produção, mais superfície de ataque — e os vulnerabilidades que estavam escondidas em volume baixo ficam visíveis quando o sistema começa a processar carga e caso-limite real.

Segundo, a maturidade de análise das ferramentas de segurança alcançou o código IA gerado. Ferramentas SAST (Static Application Security Testing) — análise estática de segurança — passaram 2025 aprendendo a identificar padrões específicos de código gerado por LLM. Os CVEs de março/2026 em parte são vulnerabilidades que existiam desde janeiro, mas que as ferramentas só aprenderam a detectar recentemente.

Isso é bom e ruim ao mesmo tempo. Bom porque você pode auditar. Ruim porque significa que o sistema que “funcionava” pode ter estado exposto por meses sem ninguém saber.

O Salesforce Ben “2026: Year of Technical Debt” documenta o mesmo padrão no ecossistema Salesforce: organizações que adotaram desenvolvimento IA-assistido sem governança de código em 2024-2025 estão gastando 2026 pagando essa dívida — em reescritas, em auditorias, em incidentes de segurança.

E o Vexlint documentou cases de startups onde o padrão se repetiu: sistemas vibe-codados funcionam por 60 a 90 dias, quebram quando o volume sobe ou o edge case aparece, e o custo de corrigir supera o custo de ter feito certo desde o início.

O problema não é que IA gera código ruim. O problema é que IA gera código sem contexto de segurança, sem arquitetura de isolamento e sem manutenção planejada. Na mão de casa de software competente, esses três elementos são humanos. Na mão de leigo em produção real, eles simplesmente não existem.

5 sinais de que sua empresa está pagando a ressaca

Como saber se você está na lista? Cinco sinais que aparecem com frequência crescente em 2026 em sistemas vibe-codados:

Sinal 1 — Bug que ninguém consegue ler

O sintoma é específico: erro em produção, dev abre o código para corrigir, e o arquivo é incompreensível. Não porque é complexo — mas porque foi gerado por IA em padrões esotéricos que nenhum humano revisou nem aprovou.

Por que acontece: LLMs geram código que funciona no caminho feliz usando padrões que estavam no dataset de treino — às vezes padrões obscuros, às vezes idiomas desatualizados de framework, às vezes abstrações que a IA “achou que ficava elegante” mas que nenhum sênior teria escrito. Sem revisão humana de arquitetura, o código funciona mas ninguém entende. Quando o bug aparece, o dev passa mais tempo decifrando o que o código faz do que consertando.

O sinal mais grave dessa variante: o dev júnior que “construiu o sistema com IA” saiu da empresa. E o código foi junto — não no sentido físico, mas no sentido de que ninguém mais sabe por que aquela função existe ou o que aquela lógica de negócio representa.

Sinal 2 — Cliente viu dado que não era dele

Esse é o mais crítico. E é também o mais silencioso — porque o cliente pode ter visto e nunca ter avisado. Ou pode ter avisado uma vez e a mensagem ficou no WhatsApp pessoal de um funcionário que saiu.

Por que acontece: ferramentas como Lovable e Bolt geram CRUD básico sem RLS (Row Level Security — política de segurança em nível de banco de dados que garante que o cliente A nunca veja dado do cliente B). O protótipo “funciona” porque em demo só tem um cliente de teste. Em produção com múltiplos clientes, qualquer URL previsível ou query mal formulada expõe dado de outro cliente.

RLS (Row Level Security) é política configurada diretamente no banco de dados (como Postgres/Supabase) que filtra resultados automaticamente por tenant — cada usuário recebe apenas os dados da própria empresa, independente da query que o front enviar. Sem RLS, a segurança depende inteiramente do código da aplicação não cometer erros. IA gerou o código da aplicação sem garantir essa camada — você tem um sistema com segurança por convenção, não por política.

Violação de LGPD por dado exposto sem consentimento: multa de até 2% do faturamento anual, limitado a R$ 50 milhões por infração.

Sinal 3 — Custo de cloud explodindo sem explicação

Você estava pagando R$ 800/mês em infra. Virou R$ 3.200 sem nenhuma mudança visível na operação.

Por que acontece: código vibe-codado não tem controle de loop, não tem cache de resposta, não tem limite de requisição por usuário. Quando o volume sobe, o código chama APIs externas em loop, consulta banco sem índice, processa o mesmo dado repetidamente. Sem observabilidade — sem sistema de monitoramento que te diga o que está rodando e quanto custa — o custo explode silencioso.

Um agente de IA mal configurado pode fazer 50 chamadas onde 1 bastaria. Uma consulta sem índice pode varrer 100.000 linhas do banco pra retornar 10 resultados. Multiplicado por 200 usuários simultâneos, a conta aparece na fatura de cloud.

Esse sinal por si só não necessariamente implica vulnerabilidade de segurança — mas implica código não otimizado que escala mal. E código que escala mal geralmente é código que também não foi auditado em segurança.

Sinal 4 — Dependência abandonada no package

O sistema funciona hoje. Mas quando você (ou um dev) roda npm audit ou pnpm audit, aparecem pacotes com CVE ativo — alguns com severidade HIGH ou CRITICAL.

Por que acontece: LLMs treinam com dados até uma data de corte. Em 2025, modelos populares ainda tinham conhecimento de 2023 como referência base. Isso significa que packages escolhidos pela IA em prompts de vibe coding podiam já estar desatualizados ou abandonados no momento em que o código foi gerado.

Pacote abandonado não recebe patch de segurança. CVE ativo nesse pacote é vetor de ataque aberto. Em sistema de produção sem rotina de atualização de dependências, esses vetores acumulam silenciosamente.

Dependência abandonada é package open-source que não recebe commits há mais de 12 meses e não tem mantenedor ativo. Ferramentas como npm audit e Snyk identificam CVEs ativos nessas dependências. A correção exige avaliar se há alternativa compatível — nem sempre é troca simples.

Sinal 5 — Nenhum dev consegue dar manutenção

O sistema funciona, mas cada mudança é cirurgia. Adicionar um campo novo quebra três coisas não relacionadas. Corrigir um bug faz aparecer outro em lugar diferente. Dev estima “2 horas de ajuste” e entrega em 3 dias.

Por que acontece: vibe coding sem arquitetura gera código altamente acoplado. Funções fazem mais de uma coisa, componentes de front acessam banco diretamente, lógica de negócio fica misturada com lógica de exibição, não há separação de responsabilidades. Cada mudança é imprevisível porque não há estrutura que isole o impacto.

Esse é o sinal de “migração impossível” — onde não dá pra extrair o código pra refactor parcial. Tudo está misturado de forma que qualquer mudança é reescrever tudo.

Por que isso aconteceu (sem demonizar IA)

Vamos ser diretos sobre o que aconteceu — sem demonizar ferramenta e sem eximir responsabilidade.

Lovable, Bolt, Cursor e Claude Code são ferramentas técnicas reais. Profissionais sérios usam essas ferramentas e entregam sistemas sólidos. O problema não está na ferramenta.

O problema está na crença de que a ferramenta dispensa quem a dirige.

Pra entender a analogia: uma furadeira profissional na mão de um marceneiro experiente faz móvel preciso. A mesma furadeira na mão de quem nunca trabalhou com madeira faz buraco no lugar errado. A furadeira não é o problema.

Vibe coding na mão de leigo entregou protótipo em 3 horas que funcionava no caminho feliz, com dados de teste, sem usuário simultâneo, sem edge case. Esse protótipo foi pra produção com clientes reais, dados reais, carga real. A furadeira fez o buraco — mas no lugar errado, no ângulo errado, sem a profundidade certa.

A ressaca de 2026 não é fracasso de IA. É fracasso de gestão de expectativa sobre o que IA faz e não faz sem direção humana competente.

A Adrion usa Claude Code há 12 meses. A diferença está em quem dirige

Quero ser explícito sobre isso porque é relevante: a Adrion usa Claude Code e Cursor em projetos de cliente há mais de 12 meses. O ContaClara — nossa plataforma SaaS de gestão de faturas telecom — foi construído com essa stack. Partes do código bruto foram aceleradas em 60 a 70% com IA.

O resultado: sistemas que levavam 30 a 90 dias levam 3 a 12 dias úteis. Isso é real.

Mas há 4 coisas que continuam humanas em todo projeto que a Adrion entrega:

1. Arquitetura de banco e RLS. Quem define o schema do banco, as políticas de Row Level Security, os índices e a estratégia de dados é o sênior — não a IA. A IA escreve o SQL depois que a decisão humana foi tomada.

2. Mapeamento de regra de negócio. A regra da Joana — aquela regra invisível que mora na cabeça de um funcionário e que “todo mundo sabe mas ninguém documentou” — só aparece na conversa com o cliente. A IA não descobre. O sênior senta, pergunta, mapeia, traduz em lógica antes de codar.

3. Revisão de segurança. Cada entrega passa por pnpm audit, análise de dependências, validação de RLS, e revisão de fallback de erro. A IA gerou o código — humano validou a segurança.

4. Manutenção contínua. Quando a API muda, quando o edge case aparece, quando o cliente reclama — humano entra, diagnostica, corrige, faz deploy. A IA não mantém sistema — acelera humano que mantém.

Ferramenta poderosa na mão de quem sabe dirigir é multiplicador. Na mão de quem não sabe dirigir é passivo com prazo de validade de 60 a 90 dias.

Plano de mitigação em 3 fases

Se você identificou um ou mais dos 5 sinais, o caminho é este. Adaptável a diferentes tamanhos de problema — não precisa necessariamente concluir as 3 fases.

Fase 1 — Auditoria de segurança (semanas 1-2, 8 a 16 horas)

Objetivo: mapear o que existe, o que está exposto e o que é urgente.

O que cobre:

• SAST (Static Application Security Testing): rodar Semgrep ou Snyk no repositório. Identifica CVEs em dependências, padrões de código inseguro e injeções conhecidas. Resultado: lista priorizada de vulnerabilidades por severidade
• RLS check: auditar cada tabela do banco que contém dado de cliente. Verificar se há política de Row Level Security testada por tenant. Sem RLS = exposição imediata se dois clientes usarem o sistema simultaneamente
• Revisão LGPD: mapear quais dados sensíveis são coletados (CPF, CNPJ, dado financeiro, dado de saúde), onde ficam armazenados e qual é a política de retenção e exclusão
• Auditoria de dependências: identificar packages com CVE ativo e packages abandonados (sem commit há 12+ meses)

Resultado da Fase 1: diagnóstico com 3 categorias — crítico (corrigir imediatamente), alto (corrigir em 30 dias), médio (corrigir em 90 dias). E a decisão estratégica: refactor incremental ou reescrita.

Em 20 a 25% dos casos, o resultado da Fase 1 é “sistema está ok para os próximos 6 meses com esses ajustes pontuais”. Isso acontece quando o sistema tem escopo limitado, não toca dado sensível ou já foi parcialmente auditado. Nesses casos, Fase 2 e 3 não são necessárias agora.

Fase 2 — Refactor crítico (semanas 3-6, 24 a 48 horas)

Objetivo: fechar os vetores de ataque críticos sem necessariamente reescrever tudo.

O que cobre:

• Auth robusta: trocar autenticação vibe-codada por biblioteca auditada com rate limit, MFA opcional e recuperação de senha com token de validade curta
• RLS em produção: implementar políticas de Row Level Security nas tabelas críticas, testar com cenários de múltiplos tenants
• Validação de entrada: adicionar schema validation (Zod ou equivalente) em todos os endpoints que recebem dado externo
• Atualização de dependências críticas: resolver CVEs de severidade HIGH e CRITICAL identificados na Fase 1
• Observabilidade básica: adicionar Sentry ou equivalente com alerta por SMS/Telegram para erros críticos em produção

Esse refactor não reescreve o sistema. Cobre as camadas de segurança que estavam ausentes. O código de lógica de negócio pode ser aproveitado — mesmo que não seja o código mais elegante do mundo.

Fase 3 — Migração estratégica ou refit (semanas 7-12)

Objetivo: decisão de longo prazo baseada nos dados das fases 1 e 2.

Dois caminhos possíveis:

Caminho A — Refit incremental: sistema com boa lógica de negócio mas arquitetura problemática. Refatorar módulo por módulo, adicionando camadas de abstração, separando responsabilidades, melhorando testabilidade. O sistema continua funcionando enquanto melhora. Prazo: 2 a 4 meses dependendo do escopo.

Caminho B — Reescrita estratégica: sistema com código incompreensível, altamente acoplado ou com dívida técnica maior que o custo de reescrever. Migrar dados do sistema atual pra sistema novo construído com arquitetura real. O sistema vibe-codado funciona em paralelo durante a transição. Prazo: 6 a 12 semanas dependendo do escopo.

A decisão entre A e B sai da Fase 1. Não tem resposta certa universal.

Como evitar entrar de novo (para os próximos projetos)

Se você vai encommendar sistema novo — seja internamente com dev usando IA ou externamente com casa de software — cinco perguntas que protegem:

1. Quem é responsável pela arquitetura de banco e RLS? Se a resposta for “a IA define”, esse projeto vai ter o mesmo problema em 6 a 12 meses.

2. Tem auditoria de dependências no processo de entrega? pnpm audit ou npm audit clean antes de qualquer push em produção é padrão mínimo. Se a casa de software não menciona isso, pergunte.

3. Como é feita a manutenção quando a API parceira muda versão? Se a resposta for vaga (“a gente olha quando aparecer”), não tem processo de manutenção — só reação a incidente.

4. O código vai pra repositório do meu CNPJ desde o dia 1? Código preso em conta do dev ou em plataforma proprietária (como projeto Lovable vinculado ao email do dev júnior) é risco de perda imediata se a relação terminar.

5. Qual é o processo de teste antes de ir pra produção? Sistema sem testes automatizados (ou pelo menos teste manual documentado de cenários críticos) vai pra produção no caminho feliz — e quebra no caminho real.

O que NÃO é solução

Algumas “saídas” que aparecem com frequência e que não resolvem o problema:

Voltar pra planilha. Não é solução — é regressão. O problema não é que você usou tecnologia. É que usou sem governança. Planilha com dado de cliente exposta em Google Drive tem os mesmos problemas de LGPD que sistema mal arquitetado.

Parar de usar IA. Também não é solução. IA na mão de profissional competente é vantagem competitiva real. Eliminar a ferramenta porque foi mal usada é como eliminar internet porque recebeu phishing.

Contratar dev júnior mais o ChatGPT. A combinação júnior + IA gera exatamente o problema documentado nesse post — código que funciona na demo e quebra em produção. O problema não era júnior sem IA. O problema é ausência de sênior dirigindo arquitetura, segurança e integração.

Esperar o problema piorar. Débito técnico tem juros. CVE ativo em dependência hoje pode ser vetor de exploit em 30 dias. Dado de cliente exposto por RLS ausente já pode ter sido acessado — você só não sabe ainda.

Onde isso vai chegar

A segunda metade de 2026 vai aumentar a pressão em dois fronts.

LGPD ganhou dentes. A ANPD passou 2024 e 2025 construindo jurisprudência — 2026 é o ano em que as multas começam a aparecer em tamanho real. Sistema com dado de cliente sem proteção adequada é risco concreto, não teórico.

O mercado vai diferenciar. Empresa com sistema estável, auditado e mantido vai ter vantagem competitiva crescente sobre empresa com sistema instável que quebra em hora ruim. Cliente B2B percebe quando o sistema do fornecedor é confiável. E percebe quando não é.

Vibe coding não vai sumir — vai se profissionalizar. A diferença entre 2025 e 2028 não vai ser se as ferramentas são boas. Vai ser se quem as usa sabe dirigir.

Próximo passo

Se você leu esse post e reconheceu um ou mais dos 5 sinais no seu sistema atual, o passo mais útil que posso sugerir é um diagnóstico honesto de 15 minutos.

Não pra vender reescrita — em 20 a 25% dos casos a resposta vai ser “tá ok, ajusta esse ponto aqui e segura mais 6 meses”. Mas sem auditoria, essa resposta honesta não é possível.

Manda “ressaca” no WhatsApp da Adrion. 15 minutos pra avaliar o seu caso.

Posts que aprofundam o tema:

• Vibe coding mata software de PME? Não — mata o software ruim — a lógica de por que ferramenta sem arquitetura gera passivo (D14)
• Lovable, Bolt, Cursor, Replit: qual cabe em qual caso — critério honesto por perfil de uso (D38)
• Casa pequena de software vs agência grande: critério honesto — quem contratar pra resolver o problema (D12)
• Como mapear a regra da Joana antes do orçamento — por que regra de negócio vem antes de qualquer ferramenta (D13)

Lucas Américo dos Reis é fundador do Grupo Adrion. Atua em arquitetura de sistemas e telecom corporativo desde 2008. Usa Claude Code e Cursor em produção há mais de 12 meses nos projetos da Adrion Sistemas. LinkedIn