Onde o vibe coding quebra: auth, backend e a parede dos 80% (com casos reais)

O login entra na demo com um clique e trava na primeira semana com usuário real. A tela continua igual, o fluxo parece pronto, mas a sessão de um usuário invade a do outro, o pagamento não confirma e o suporte recebe mensagens que nenhum prompt previu. Esse é o ponto em que o vibe coding costuma quebrar, não na interface, e sim em autenticação e backend, onde improviso vira incidente.

Este texto organiza o que os relatos documentaram sobre esse ponto de ruptura, com números, sintomas e um checklist para especificar login, sessão, permissões e cobrança fora do prompt. Para a conta completa do mês, com créditos, tokens e operação, comece por quanto custa vibe coding de verdade.

Auth passa na demo porque a demo testa quase nada do que importa. Um usuário, uma sessão, nenhuma concorrência, permissões simples e cobrança desligada ou simulada. Nessas condições, qualquer fluxo gerado parece correto. O problema aparece quando 500 pessoas tentam entrar ao mesmo tempo, quando dois logins disputam a mesma sessão e quando uma regra de permissão precisa barrar de verdade.

A análise de 12 projetos publicada em 17/fev/2026 descreve esse salto sem rodeio: auth que funcionava em ambiente controlado rompeu em produção, com sessões colidindo entre usuários, teste com 500 concorrentes expondo a falha e cerca de 2 semanas com o app parado até a correção (Future Humanism, 17/fev/2026). O dado financeiro fecha o argumento. O debug ficou na casa de US$15k, contra build inicial na casa de US$6k na mesma análise (Future Humanism, 17/fev/2026). Construir a tela de login saiu barato. Fazer o login aguentar gente de verdade custou o múltiplo.

A lição para quem planeja é direta. Demo valida se o fluxo é compreensível. Só carga com concorrência, expiração de sessão e troca de papel de usuário valida se a auth existe de fato. Tratar essas duas validações como a mesma etapa é o erro que gera as 2 semanas parado.

Quando o gerador recebe login, sessão e pagamento no mesmo pedido que cria telas, ele resolve cada parte do jeito que parece mais rápido naquele trecho. O resultado aparece depois, na auditoria: o mesmo app com três formas distintas de checar quem está logado e de confirmar pagamento.

O levantamento com 8 meses de acompanhamento e 6 builders encontrou exatamente esse quadro no Lovable, com middleware de auth e Stripe em 3 padrões distintos convivendo no mesmo ecossistema (socialanimal). Três padrões para a mesma responsabilidade significam três lugares para corrigir, três comportamentos para testar e três superfícies para falhar. Em demo com um usuário, a diferença não aparece. Com dinheiro envolvido e permissões por papel, cada padrão responde de um jeito e o suporte recebe o conflito.

A correção não passa por pedir mais telas ao gerador. Passa por definir um contrato único antes de gerar: onde a sessão mora, quanto tempo dura, quem pode ver o quê e como o Stripe confirma cada estado de assinatura. Sem esse contrato escrito fora do prompt, cada nova geração cria uma quarta variação do mesmo problema.

Bug de auth é o ralo mais fundo do vibe coding porque junta duas pressões. O contexto já está grande, com telas, rotas e integrações acumuladas, e cada tentativa de correção recarrega esse contexto inteiro. O modelo tenta, erra por pouco, recebe outro pedido parecido e tenta de novo no mesmo fio viciado.

Os relatos documentados em 13/mar/2026 dão a medida desse ralo: um bug de autenticação chegou a consumir 20M de tokens em tentativas acumuladas (brgrowthclub, 13/mar/2026). O mesmo conjunto de relatos registra o agravante operacional: deploys sem revisão publicaram ghost files no Netlify, arquivos que ninguém conferiu e que foram parar no ar (brgrowthclub, 13/mar/2026). Token queimado pesa no bolso. Arquivo não revisado no ar pesa na confiança.

O gráfico abaixo coloca o custo humano ao lado do custo de tokens. O build inicial de auth ficou na casa de US$6k, enquanto o debug em produção ficou na casa de US$15k, conforme a análise de 12 projetos (Future Humanism, 17/fev/2026).

A comparação com o teste do mesmo app ajuda a entender o mecanismo do desperdício, porque mostra o loop em outro contexto com números abertos. Veja os detalhes em Lovable vs Bolt vs v0 no mesmo app. O padrão se repete: construção inicial com custo contido, correção repetida com custo múltiplo, e nenhuma conferência antes de publicar.

A parede dos 80% é o momento em que o app parece quase pronto e para de avançar. Faltam poucos ajustes, cada pedido parece simples, mas cada resposta repete o defeito com redação diferente. O nome técnico que os relatos usam para esse giro é doom loop, o ciclo em que mais tentativas no mesmo fio geram mais contexto viciado e menos conserto.

O teste documentado no TabNews em 26/fev/2026 mediu esse momento: 211k tokens queimados em 3 correções sem consertar o defeito, contra 39k tokens na construção inicial, um múltiplo de 5.4x (TabNews, 26/fev/2026). O mesmo relato registra o detalhe comportamental que explica o múltiplo: nenhuma das ferramentas verificou o próprio trabalho antes de entregar (TabNews, 26/fev/2026). Sem etapa de conferência, o erro atravessa para o usuário, que paga outra rodada para apontar o óbvio.

Em auth, a parede dói mais porque o defeito não é visual. Tela quebrada todo mundo vê antes de publicar. Sessão que vaza de um usuário para outro só aparece com concorrência, e permissão que deixa passar a mais só aparece quando alguém explora. Por isso a regra dos relatos é interromper o fio ao primeiro sinal de repetição: congelar o escopo, abrir conversa nova só para o módulo de auth, revisar sessão e permissões fora do gerador e só então retomar com caso de teste definido.

Código gerado em volume passa em leitura rápida e falha em leitura de segurança. A interface renderiza, o fluxo anda, os testes manuais com um usuário passam. A camada profunda guarda duplicação, regra de negócio frágil e brecha que só aparece sob ataque ou sob carga.

A evidência de segurança vem de 470 pull requests analisados em dez/2025, com 2.74x mais vulnerabilidades em código com participação pesada de IA (CodeRabbit, dez/2025). Vulnerabilidade aqui não é detalhe de estilo. É porta aberta em auth, validação que falta no backend e permissão checada só no frontend. Cada item dessa lista vira incidente com usuário real, não apenas retrabalho.

A evidência de manutenção completa o quadro com a leitura em duas camadas. O levantamento publicado em 24/jun/2026 aponta duplicação de 8x em 2025, com a camada superficial que parece pronta e a camada profunda que cobra depois em correção e revisão (LavX, 24/jun/2026). Tradução prática: quanto mais código parecido espalhado pelo projeto, maior o contexto de cada correção e maior a chance de consertar num lugar e quebrar em outro. Auth duplicada em 3 padrões é o exemplo perfeito dessa camada profunda cobrando a conta.

Lock-in no vibe coding raramente é contrato formal. É auth amarrada ao provedor, regra de cobrança espalhada em funções geradas e dados sem exportação testada. Trocar de plataforma vira reescrever o núcleo, não apenas mover arquivos.

O levantamento com 8 meses e 6 builders coloca números nessa amarração, com custo de ejeção de um Bubble legado estimado entre US$50-200K (socialanimal). O mesmo levantamento detalha o ecossistema Supabase que acompanha builders como o Lovable, o que reforça o recado: validar com banco acoplado sai barato, sair depois com dados, auth e cobrança entrelaçados sai caro (socialanimal). A decisão de saída precisa entrar no plano no dia um, com exportação testada antes do primeiro usuário pagante.

Os sintomas que antecedem o estouro costumam aparecer nessa ordem. Login que funciona com um usuário e falha com dois logados ao mesmo tempo. Sessão que não expira quando deveria ou que expira no meio da compra. Permissão que depende só de esconder botão na tela. Cobrança que confirma no frontend sem conferir webhook. Correção que conserta um caso e reabre outro. Quando dois desses sinais aparecem na mesma semana, o projeto já encostou na parede.

O checklist mínimo antes de gerar auth cabe em uma página e evita a maior parte do prejuízo. Login: quais métodos entram, quais ficam de fora e como fica a recuperação de acesso. Sessão: onde mora, quanto dura, quando expira e como revogar. Permissões: quais papéis existem, quem vê o quê e onde a checagem acontece no backend, nunca só na tela. Cobrança: como o Stripe confirma cada estado, como tratar webhook atrasado e o que acontece quando o pagamento falha. Nada disso pertence a um pedido solto para gerar telas. Pertence a uma especificação curta, revisada por gente, que o gerador apenas implementa.

fluxo profissional do protótipo ao deploy

Por que login gerado por IA falha com vários usuários ao mesmo tempo?

Porque a demo testa com um usuário e sem concorrência. Com 500 concorrentes, colisões de sessão e permissões frouxas aparecem, com registro de 2 semanas com o app parado e debug na casa de US$15k contra build na casa de US$6k em análise de 12 projetos (Future Humanism, 17/fev/2026). A resposta é testar com concorrência antes de liberar, com sessão única por dispositivo e revogação definida.

O que fazer quando o app trava na parede dos 80%?

Pausar o fio atual. A medida documentada é de 211k tokens em 3 correções sem conserto contra 39k iniciais, ou 5.4x, sem nenhuma verificação antes de entregar (TabNews, 26/fev/2026). Isole o módulo de auth, revise sessão e permissões fora do gerador e retome com caso de teste fechado e escopo menor.

Como evitar lock-in em Supabase e Bubble desde o dia um?

Documentando saída antes da entrada. O custo de ejeção de um Bubble legado fica entre US$50-200K, conforme levantamento com 8 meses e 6 builders (socialanimal). Teste exportação de dados, mantenha auth e cobrança com contrato próprio e evite regra crítica espalhada em funções geradas.

O que especificar fora do prompt antes de gerar auth?

Login, sessão, permissões e cobrança, cada um com regra escrita e revisada. Login define métodos e recuperação. Sessão define moradia, duração e revogação. Permissões definem papéis com checagem no backend. Cobrança define confirmação via Stripe com tratamento de webhook. Sem isso, o gerador improvisa em 3 padrões distintos, como flagrado no Lovable (socialanimal), e o custo aparece em tokens e em incidente, com 20M num bug e ghost files no ar (brgrowthclub, 13/mar/2026).

A conta da auth gerada sem contrato é clara nos relatos. Demo que passa com um usuário, produção que trava com 500 concorrentes e 2 semanas parado, debug na casa de US$15k contra build na casa de US$6k (Future Humanism, 17/fev/2026). Middleware triplicado sem dono (socialanimal), 20M de tokens num bug com ghost files no ar (brgrowthclub, 13/mar/2026), parede dos 80% com 5.4x de repetição (TabNews, 26/fev/2026) e camada profunda com 2.74x mais vulnerabilidades (CodeRabbit, dez/2025) e 8x de duplicação (LavX, 24/jun/2026). Nenhum desses números condena o vibe coding. Todos condenam tratar backend como rascunho.

O próximo passo depende da dúvida que ficou. Para a conta do mês, volte ao pilar do cluster. Para custo por entrega entre ferramentas, avance para o comparativo. Para operar sem susto do protótipo ao deploy, avance para o fluxo profissional.

• Future Humanism, 17/fev/2026: 12 projetos com auth quebrando em produção, sessões colidindo, 500 concorrentes, 2 semanas parado, debug na casa de US$15k contra build na casa de US$6k.
• TabNews, zilvodev, 26/fev/2026: parede dos 80% e doom loop, 211k tokens em 3 correções sem conserto contra 39k iniciais (5.4x), nenhuma verificação antes de entregar.
• socialanimal, levantamento com 8 meses e 6 builders: middleware de auth e Stripe no Lovable em 3 padrões, lock-in Supabase e Bubble com ejeção entre US$50-200K.
• brgrowthclub, 13/mar/2026: 20M de tokens num bug de auth, ghost files no Netlify com deploy sem revisão.
• CodeRabbit, dez/2025: 470 PRs com 2.74x mais vulnerabilidades em código com participação pesada de IA.
• LavX, 24/jun/2026: duplicação 8x em 2025 com leitura dual-layer, camada superficial pronta e camada profunda que cobra depois.