Vibe-Coding: a promessa e os limites
Estamos muito otimistas com vibe-coding. Mas acoplamento de backend, queima de tokens e erros de alucinação que se acumulam são reais. Aqui estão 5 problemas que seguimos enfrentando em produção.
Também disponível em: EN | 日本語
Eu sou o Ivan, cofundador/CEO da Prompt.Build. Antes disso, fomos a BeyondRisk AI-6 construindo sistemas corporativos de IA. Adotamos ferramentas de vibe-coding cedo para ganhar velocidade. Estou muito otimista - e acho que ainda estamos só no começo do que é possível. 🚀 Este post registra as dores que vemos quando times de verdade tentam colocar apps em produção com vibe-coding. Sem “soluções” aqui; no próximo post eu compartilho como estamos tentando atacar esses pontos.
O que o vibe-coding acerta (por que estamos otimistas)✨
Vibe-coding - dizer para uma IA o que você quer e deixar ela construir - acelera muito o frontend. Você sai do zero para uma interface “de verdade” numa única sessão: páginas aparecem, navegação funciona, formulários e tabelas surgem, e o design fica consistente sem brigar por detalhes.
Também encurta o caminho de ideia → tela. Em vez de tickets, wireframes e repasses, você descreve o que precisa e já vê na hora. Esse ciclo rápido te faz experimentar mais: testar dois layouts, trocar componentes, ajustar o copy - antes de gastar dias de engenharia.
E não é mais só frontend. A maioria das plataformas de vibe-coding já vem com um backend pronto - muitas via Supabase (gerenciado ou OSS) - então você ganha auth, Postgres, RLS, storage e um SDK redondinho já no dia 1. Isso faz com que demos e ferramentas internas fiquem “reais” de ponta a ponta, não só cascas clicáveis.
✅ Em resumo: vibe-coding brilha em velocidade, iteração e entendimento compartilhado - e, cada vez mais, em te levar rápido a um protótipo full-stack funcional.
Mas quando você sai da camada de UI, o “vibe” muda.
Os 5 problemas que seguimos vendo em produção ⚠️
1) Velocidade do vibe-coding vs lacunas no backend 🔧
É verdade: hoje a maioria das plataformas de vibe-coding já entrega um backend pronto (muitas com Supabase - auth, Postgres, RLS, storage, functions). Então o problema não é “não ter backend”. É a fiação entre a UI que muda rápido e os contratos do backend quando entra lógica de verdade.
Onde vemos a dor em produção:
🔍 Deriva silenciosa (UI vs API).
Detalhinhos estouram tudo depois: customer_id vs customerId, UI espera 200 mas a API retorna 204, ou a lista muda de { data: [] } para só []. Um ajuste rápido no backend pode fazer a tela ler os campos errados (id vs user_id) sem erro explícito.🧩 Telas saem de sincronia.
Você corrige “Editar Cliente”, mas “Pedidos” continua no shape antigo. Sem uma fonte única da verdade, cada tela deriva um pouquinho do seu jeito.🗄️ Alterações de schema não chegam em todo lugar.
Renomear coluna ou apertar um enum num ponto e, em outros, tudo segue no antigo - a menos que migrations saiam juntas e o pipeline pegue. A própria recomendação do Supabase bate na tecla de migrations + CI para evitar exatamente essa classe de erro.🌗 Diferenças entre staging e prod.
Keys, base URLs, buckets de storage ou políticas não batem. No preview funciona; em prod dá 401/403/404. Clássico “no meu branch funcionou”.🔌 Bordas de workflow são frágeis (jobs, webhooks, filas).
A UI pode dizer “Aprovar → Notificar → Conciliar”, mas conectar serverless functions, cron jobs e assinaturas de webhooks (Stripe, Slack, GitHub) é frágil. Rate limits, retries e idempotência não se resolvem só com prompt.
Freqüentemente os problemas aparecem quando o projeto tem 3–5 integrações externas (pagamentos, comunicação, identidade, storage, analytics). Isso já é o suficiente para iniciar deriva.
✅ Bottom line: entregar um backend já não é o gargalo; coordenar UI ↔ API ↔ contratos de dados é. Quanto mais rápido a UI muda, mais fácil endpoints, schemas e políticas saírem de compasso - especialmente quando as integrações passam do CRUD (pagamentos, audit, APIs de terceiros, jobs em background).
2) Acoplamento ao Supabase 🧩 e por que “exportar & continuar” ainda não é código realmente seu
Hoje muita plataforma de vibe-coding pluga no Supabase (gerenciado ou OSS) para ter um backend dia-1: Postgres + Auth + RLS + Storage + Edge/Functions + Realtime. É um ganho enorme - login, tabelas, políticas e arquivos em horas, não semanas, e demos ficam reais de ponta a ponta.
Nossa visão:
O “verdadeiro” vibe-coding deveria gerar código que é seu - front-end e back-end.
Quando o backend vive dentro de um provider, você não “possui” totalmente os primitivos; você fica preso à forma como aquele provider implementa (shape de auth/sessão, estilo de políticas RLS, extensões SQL, caminhos/ACLs de storage, canais de Realtime, semântica do SDK).
Então, mesmo que você exporte de uma plataforma (Lovable/Bolt/Replit) e continue no Claude Code/Cursor/Codex ou outro assistente, normalmente está exportando o frontend em volta de um backend no formato do provider. Não é ruim - é o custo natural de acelerar em cima de um stack ótimo - mas é apego, não independência.
Onde isso aparece:
Trabalho de portabilidade lá na frente. Migrar para Postgres “vanilla”/RDS/Aurora ou outro backend exige remapear políticas, auth/sessão, semântica de storage e chamadas do SDK.
Ops/observabilidade ficam no formato do provider. Incidentes, logs, métricas, cotas e runbooks seguem os padrões do provider; trocar implica reaprender e refazer tooling.
Teto de customização. Nem sempre dá para alterar internals de auth/queue/storage como você faria se fossem gerados no seu repositório/infra.
Não somos “anti-Supabase” - somos pró-propriedade. É um backend excelente para começar rápido. Só damos o alerta do acoplamento cedo para o time planejar portabilidade e rotas de saída - ou optar por gerar/possuir mais do backend quando isso passar a importar.
Prática: use Supabase com confiança para velocidade, e mantenha saídas de emergência:
Trate auth e dados como interfaces (fronteira fina de auth + camada de acesso a dados).
Envolva storage/webhooks/filas atrás das suas functions para poder trocar URLs/assinaturas/providers.
Se propriedade é crítica, mire um caminho onde o fluxo de vibe-coding possa emitir os primitivos de backend como código/infra que você pode editar, revisar e redeployar em qualquer lugar.
3) Queima de tokens no loop de depuração 🔥💸
Mesmo com controles de custo mais novos como prompt caching (OpenAI, Anthropic), o gasto de tokens durante a depuração iterativa ainda é difícil de prever. O cache dá desconto no contexto repetido, mas os loops reais incluem retries, tool calls e edições não-locais que reenviam contextos grandes - então dois “ajustes pequenos” podem variar 10–50× em tokens dependendo do que o modelo resolve tocar e de quanto contexto é recarregado.
🔥 Por que a queima continua hoje:
Edições não determinísticas. Um prompt pequeno às vezes dispara reescritas mais amplas em arquivos/tipos adjacentes, forçando reprocessar contextos maiores no próximo passo. (Vendors mitigam com caching/créditos, mas não eliminam diffs largos.)
Thrash de retry/tools. Rate limits, mismatches de schema ou re-planejamento de tools re-streamam o mesmo (ou maior) contexto. Cache ajuda mas não cobre todos os caminhos nem todo cache miss.
Sinais de preço refletem a variância. Plataformas migram para pricing por uso/esforço ou por faixas de tokens justamente porque a carga oscila muito entre “uma tacada só” e “várias passagens exploratórias”. Usuários relatam estourar pools de tokens/créditos mais rápido que o esperado.
🤷♂️ Onde a incerteza dói:
Não dá para estimar com confiança o custo por correção - mudanças “parecidas” podem abrir leques bem diferentes.
Você paga só para confirmar “não mudou mais nada”, porque a verificação também re-consome contexto.
Times sofrem para orçar a fase de build porque o gasto acompanha a quantidade e a amplitude das regenerações, não apenas o número de features.
✅ Em resumo: a dor não é só custo - é falta de transparência e previsibilidade. Mesmo com descontos de cache, falta uma unidade estável de trabalho para estimar “quanto custa arrumar isso?” durante a iteração ativa.
4) Planos mensais não combinam com a forma como construímos 🗓️⏱️
A maioria das plataformas vende planos mensais com limite de tokens. A maioria dos times não constrói o mês inteiro. Inscrevem, codam forte por 5–10 dias, entregam demo, exportam para um assistente de código (Cursor, Claude Code, etc.) e param. O usuário não quer “calendário” - quer uma forma previsível de pagar por um bloco de trabalho.
🧠 Por que isso atrapalha:
Você paga por tempo ocioso. Depois da semana intensa, o resto do mês fica parado.
Orçamento vira bagunça. Um ajuste pequeno pode consumir mais tokens que o previsto; custo por tarefa não é claro.
Unidade errada de valor. Você é forçado a comprar tempo (um mês) em vez de trabalho (tentativas de build, rodadas de regen, um resultado implantável).
Trocas de contexto. Depois de exportar para assistentes de código, você ainda está pagando um plano que não usa.
✅ O que o usuário realmente quer:
Pagar por uma janela de build, não por um mês - ex.: passes de 3–7 dias.
Unidades claras de trabalho (ex.: N regenerações, M verificações de contrato, um build implantável).
Sem penalidade por pausar. Parar, voltar depois e retomar de onde parou.
“Builders não pensam em meses. Pensam em sprints - ‘faz essa feature funcionar e pausa’. O preço deveria refletir isso: pagar por um foco de build, não por uma folha de calendário.”
✅ Em resumo: o usuário precisa de pricing previsível e alinhado à tarefa - pagar pelo trabalho feito em rajadas curtas e depois pausar. Mensal + tokens faz projetos simples parecerem caros e difíceis de planejar.
5) Erros de alucinação que se acumulam: por que pequenos deslizes viram bola de neve 🌀
Prompting em múltiplas etapas pode amplificar erros pequenos. Modelos raramente se autocorregem de forma confiável sem feedback externo; em muitos casos, “self-correction” até degrada a qualidade. Em cenários de múltiplos turnos, erros tendem a se acumular conforme o contexto muda e a não-deterministicidade introduz novas inconsistências.
🧪 Por que isso acontece hoje:
Limites da autocorreção. Estudos mostram que autocorreção intrínseca (o modelo se consertar a partir da própria saída) é pouco confiável e pode piorar o raciocínio.
Não-determinismo entre execuções. Mesmo com configurações “determinísticas”, saídas variam; então um fix no passo N pode criar um novo desencontro no passo N+1.
Deriva em contextos longos. Quanto maior a cadeia de edições, mais deriva latente acumula e mais difícil fica detectar/reverter.
🧵 Como isso aparece no dia a dia:
Nomes, shapes e estados “quase” batem - mas nunca 100% - criando um mosaico frágil sob testes e migrations.
“Pedir de novo para corrigir” dispara efeitos colaterais em outro canto, e você gasta ciclos validando estabilidade em vez de entregar.
Depois de alguns dias, você está depurando a própria deriva, não a feature original.
“Um pequeno passo em falso pode virar cascata. Se sua única ferramenta é ‘pedir de novo’, você acaba perseguindo o último erro do modelo em vez de corrigir a causa real.”
✅ Em resumo: alucinação acumulada não é exceção - é comportamento conhecido de loops multi-turno e auto-refináveis. Sem uma fonte externa da verdade (contratos, testes, verificações), “só prompta de novo” costuma espalhar o erro em vez de selá-lo.
Uma nota especial: “fluxos agentic orientados por especificação” são necessários, mas não bastam 📐
Estamos vendo uma nova leva de IDEs agentic orientadas por specs / “fábricas de software”. Exemplos: Amazon Kiro, 8090.ai (a “Software Factory” do Chamath) e o Spec Kit do GitHub. A tendência é certa: adicionar estrutura - PRDs, specs, tarefas - dentro do loop.
No que concordamos:
Fluxos orientados por specs são necessários. Reduzem caos, dão plano para agentes e diminuem desencontros óbvios.
Realidade:
Eles não apagam alucinação nem não-determinismo - especialmente conforme o app cresce ou quando você edita dia após dia. Loops de autocorreção muitas vezes não convergem, contextos longos derivam, e pequenos fixes podem continuar criando inconsistências. Estrutura ajuda; não encerra o problema.
Como fazemos (e o que aprendemos):
Na Prompt.Build, também rodamos fluxos agentic orientados por spec (PRD → tarefas → contratos → código). Isso reduz mismatch. Mas, em escala, você ainda vê erros acumulados e deriva de contexto se não adicionar guardrails.
“Specs são necessárias, não suficientes. Elas apontam o modelo na direção certa; os guardrails impedem que ele derive quando o app cresce e as edições se acumulam.”
✅ Em resumo:
Specs + agentes são o próximo passo certo - mas não bastam sozinhos. Na Prompt.Build, vamos além de fluxos orientados por specs com verificações e guardrails de portabilidade para manter UI/API/schema em compasso e segurar a deriva antes de chegar à produção. Vou detalhar como no próximo post.
FAQ rápido❓
O que é vibe-coding?
Descrever para a IA o que você quer e ela construir a maior parte do app - especialmente as telas - bem rápido.Vibe-coding é bom?
Sim para velocidade, demos e prototipagem. Fica puxado quando a UI e o backend param de concordar.Quais os contras?
Pequenos desencontros se acumulam (nomes, shapes de dados, status codes), correções podem queimar muitos tokens e você pode ficar preso a um provider de backend.Vibe-coding é “de graça”?
Não. Você paga por tokens. Um ajuste pequeno pode disparar uma regen ampla e custar mais do que esperava.Qual ferramenta é “a melhor”?
Escolha a que deixa exportar código de verdade e rodar em outro lugar depois. Portabilidade importa mais que o logo.Vibe-coding vai substituir programadores?
Não. Pessoas ainda decidem o modelo de dados, regras de segurança, como implantar e o que é “pronto”.O que é “deriva de contrato”?
Quando UI e API param de bater - uma espera customerId, a outra manda customer_id; uma retorna 200, a outra espera 204. Parece tudo bem até quebrar.Por que os tokens disparam na depuração?
Uma mudança pequena pode fazer a IA reescrever arquivos próximos e reenviar contextos grandes em tool calls. Duas correções parecidas podem custar bem diferente.Por que planos mensais não encaixam no jeito que a gente trabalha?
A maioria dos times trabalha em rajadas curtas (poucos dias), não o mês inteiro. Querem pagar por janela de build ou por bloco claro de trabalho - não por um mês de calendário.O que são “erros de alucinação acumulados”?
Um errinho de IA leva a outro “fix”, que muda outra coisa, e os erros viram bola de neve.Fluxos agentic orientados por spec são suficientes?
Ajudam muito, mas não sozinhos. Você ainda precisa de checks para manter tudo alinhado.Como evitar lock-in de backend?
Trate auth e dados como peças plugáveis. Não espalhe chamadas específicas do provider por todo lado; concentre numa camada para poder trocar depois.
Por que estou escrevendo isso (e o que vem depois) 🚀
Fundamos a Prompt.Build porque adoramos o que o vibe-coding destravou - e porque batemos nas mesmas paredes depois do frontend. No próximo post, vou mostrar como vamos além de fluxos agentic por especificação com uma camada única de contrato verificável por máquina, migrations atômicas e testes sensíveis a contrato - para que os builds fiquem reprodutíveis, portáveis e rápidos sem desperdiçar tokens.
Se você já bateu em alguma dessas, quero ouvir - deixa um comentário abaixo ou responde este e-mail (eu leio todos). E, se quiser o próximo capítulo, assina para cair direto na sua caixa. 🔔
— Ivan, co-founder/CEO, Prompt.Build
https://prompt.build