僕は Prompt.Build の共同創業者/CEO、Ivan です。以前は BeyondRisk AI-6 としてエンタープライズ向けのAIシステムを作っていました。スピード重視で、早い段階から vibe-coding系のツールを取り入れてきました。すごく強気——そして、まだまだ始まったばかりだとも思っています。🚀 この投稿は、vibe-coding で本当にプロダクションまで持っていこうとした時に現場のチームが直面する痛みを記録したものです。今回は解決策は書きません。次回、僕らのアプローチを共有します。

Also available in: EN | PT-BR

Vibe-coding が得意なこと（僕らが強気な理由）✨

Vibe-coding（やりたいことをAIに伝えて作らせるやり方）は フロントエンドを圧倒的に速く します。ゼロからでも1セッションで“それっぽい”アプリに届く。ページが立ち上がり、ナビゲーションが動き、フォームやテーブルが並び、長い議論なしに見た目も揃う。

さらに idea → screen の距離が短い。チケットやワイヤーや引き継ぎの前に、「こうしたい」を伝えてすぐ見える。だから試行回数が増える。レイアウトを2案試す、コンポーネントを差し替える、コピーをいじる——エンジニアリングの工数を飲み込む前に。

しかも今はフロント専用でもない。多くの vibe-coding プラットフォームは ready-made backend を一緒に配線します。たとえば Supabase（managed/OSS）。auth / Postgres / RLS / storage / 使いやすい SDK が Day 1 から揃う。つまり、デモや社内ツールがクリックだけの殻ではなく、端から端まで“本物っぽい” 体験になる。

✅ 要点: 速度・反復・共有理解 に強く、しかも 動くフルスタックのプロトタイプ まで持っていきやすい。

ただし UI層を越えたところ から雰囲気が変わります。

本番で何度も直面する5つの問題 ⚠️

1) Vibe-coding の速さ vs バックエンドの“すき間”🔧

いまどき多くのプラットフォームは Supabase 等で backend 付き です（auth / Postgres / RLS / storage / functions）。なので課題は「バックエンドがない」ではありません。高速で変わるUI と、バックエンドの契約（contracts） を“本当のロジック”が出てきた瞬間から どう噛み合わせるか。

現場で起きがちな痛み:

• 🔍 サイレントドリフト(UI vs API).
  customer_id vs customerId、UIは 200 を期待しているのに API は 204、配列の形が { data: [] } → []。バックエンドの軽い修正で、画面が id vs user_id を取り違えても目に見えるエラーは出ない。

• 🧩 画面の非同期化
  「編集」画面は直したのに「一覧」は古いデータ形のまま。単一のソース・オブ・トゥルース がないと、画面ごとに微妙にズレる。

• 🗄️スキーマ変更が行き渡らない
  カラム名変更や enum の締め付けを一カ所でやっても、他のページ/関数は旧仕様のまま。migrations を束ねて流し、pipeline で検知 しない限り起きがち。Supabase 公式も “migrations + CI” を強く推奨。

• 🌗 staging と prod の差
  keys / base URL / storage の bucket / policy が一致していない。preview ではOK→本番で 401/403/404。いわゆる「手元では動いた」案件。

• 🔌 ワークフローの縁が脆い（jobs / webhooks / queues）
  画面上は「Approve → Notify → Reconcile」でも、serverless functions / cron / webhook 署名（Stripe, Slack, GitHub） の配線は脆い。rate limit / retry / idempotency は prompt だけでは担保できない。

外部連携が 3〜5個（決済・コミュニケーション・ID・ストレージ・分析）に到達したあたりから、ドリフトが始まりやすい。

✅ 要点: いまは backend の有無 ではなく、UI ↔ API ↔ data contracts の同期 がボトルネック。UIの回転が速いほど endpoint / schema / policy はズレやすい。特に CRUD を越えた payments / audit logs / 3rd-party APIs / background jobs が増えるほど。

2) Supabase への結合 🧩 —— “export & continue” でも完全に自分のコードとは言い切れない理由

多くの vibe-coding プラットフォームは Supabase（managed/OSS）で Day 1 backend を用意します。Postgres + Auth + RLS + Storage + Edge/Functions + Realtime。ログイン/テーブル/ポリシー/ファイルまで数時間で。端から端まで“本物”。

バックエンドが provider の中 にあると、primitives を完全には所有できない。つまり auth/session の shape、RLS policy の流儀、SQL拡張、storage の path/ACL、Realtime の channel、SDK の挙動 に縛られる。

だから Lovable / Bolt / Replit からエクスポートして Claude Code / Cursor / Codex 等で続けるとしても、多くの場合それは provider 仕様の backend を中心に据えた frontend コードのエクスポート。悪いことではない（速さの代償）が、independence ではなく attachment。

表に出る場面:

• ポータビリティの工事 が後ろに回る。Postgres vanilla / RDS / Aurora などへ動かす際、policy / auth/session / storage semantics / SDK 呼び出し の張り替えが必要。

• Ops / observability は provider 仕様のまま。incidents / logs / metrics / quotas / runbooks がその流儀に依存。乗り換えは 再学習とツール替え を伴う。

• カスタマイズの天井。auth / queue / storage の内部に手を入れたい時、自分のリポ/インフラで生成されている場合の自由度 には届かないことがある。

僕らは “反Supabase” ではなく “プロオーナーシップ”。Supabase は 最速の立ち上げ として素晴らしい。ただ、結合 の事実は早めに見積もり、出口 と 移行戦略 を設計しておく。あるいは必要になった時に backend 側も自分のコードとして生成 できる道を確保しておく。

実務的には：速さのために Supabase は遠慮なく使う。ただし 逃げ道（escape hatch） を持つ。

• auth / data をインターフェース化（薄い auth 境界 + data access layer）。

• storage / webhooks / queues は自分の functions でラップして、URL / 署名 / provider を差し替え可能に。

• 所有権が重要 なら、backend primitives をコード/インフラとして出力 し、編集/レビュー/再デプロイ がどこでもできる流れを狙う。

3) デバッグ中のトークン消費が膨らむ 🔥💸

OpenAI / Anthropic の prompt caching のような制御が出てきても、反復デバッグ中のトークン支出 はまだ読みにくい。キャッシュ は同一文脈に割引を効かせるが、実際のループは retry / tool calls / 非局所的な編集 を含み、大きなコンテキストの再送 を誘発する。結果、“小さな修正” 同士でも 10〜50× の差が出ることがある。

🔥 なぜ今も燃え続けるか:

• 非決定的な編集。小さな指示で周辺ファイル/型まで広く書き換え、次パスでより大きな文脈を再処理させる（キャッシュやクレジットは効くが wide diff をなくしきれない）。

• retry / tool の空回り。rate limit / schema mismatch / tool の replanning で同じ（あるいはより大きな）文脈を再ストリーム。cache miss も起きる。

• 価格シグナル 自体がばらつきを反映。usage/effort ベース や token tiers に各社が寄るのは、実際の負荷が「一発で決まる」と「探索的に何度も回す」を大きく揺れるから。

🤷‍♂️ どこが痛いか:

• 修正1件あたりのコスト を読めない。見た目が似た変更でも拡散の仕方は全然違う。

• “他に影響ない” を確認するだけ でもコンテキスト再消費で課金が走る。

• ビルド予算 が立てにくい。支出は 再生成の回数と広がり に追随し、機能数 とは比例しない。

✅ 要点: 痛みは 金額 だけでなく 予見可能性の欠如。キャッシュ割引があっても、「この修正はいくら？」を見積れる安定した単位 が開発者側にない。

4) 月額サブスクは僕らの作り方に合わない🗓️⏱️

多くのプラットフォームは 月額＋トークン上限。でも多くのチームは 月中ずっと作らない。登録して 5〜10日 集中的にビルド、デモを出し、Cursor / Claude Code などのAIコードアシスタントにエクスポートして、一旦止める。ユーザーが欲しいのは カレンダーではなく、まとまった作業単位に対する予測可能な支払い。

🧠 何が辛いか:

• 遊んでいる期間にも支払う。集中週が終わると残りは未使用

• 見積りが散らかる。小さな修正でも想定以上にトークンを食うことがある。タスク単価 が不明瞭

• 価値の単位がズレている。買っているのは 時間（1ヶ月） であって 仕事（ビルド試行/再生成回数/デプロイ可能な成果） ではない。

• コンテキスト切替。アシスタントにエクスポートした後も、使っていないサブスクに課金される。

✅ ユーザーが本当に欲しいもの:

• 月ではなく“ビルド期間”に課金（例：3〜7日パス）。

• 明確な作業単位（例：N regenerations / M contract checks / デプロイ可能な1ビルド）。

• ペナルティなしで一時停止。止めて、後で戻って、続きから再開。

「ビルダーは 月 ではなく スプリント で考える。『この機能を動かして、いったん止める』。料金も“集中ビルドに払う” 形 であるべき。」

✅ 要点: タスクに沿った予測可能な課金 が必要。短期集中→一時停止 の流れに合わせる。月額＋トークン は小規模案件でも割高・不透明に感じさせがち。

5) “誤りの積み重なり”——小さなLLMミスが雪だるま化する理由 🌀

マルチステップのプロンプト は 小さな誤りを増幅 しがち。外部からのフィードバック なしに 自己修正（self-correction） に頼るのは安定せず、むしろ質を落とすことも。マルチターン では、文脈の変動 と 非決定性 が新たな不整合を生み、誤りが累積 する。

🧪 いま起きる理由:

• 自己修正の限界。モデル自身の出力だけを手掛かりに直す手法は信頼性が低く、推論を悪化 させるケースも。

• 実行間の非決定性。温度を下げても出力は揺れる。Nステップ目の修正 が N+1 で別のズレを作る。

• 長文脈のドリフト。編集チェーンが伸びるほど 潜在的なドリフト が溜まり、検出・巻き戻しが難しくなる。

🧵 現場感としては:

• 名前/shape/state が“ほぼ”合っているのに 完全一致しない。テストやマイグレーションに脆いモザイクができる。

• “もう一回お願い” が別の副作用を生み、安定性確認 に時間を溶かす。

• 数日たつと、元の機能ではなく ドリフトそのもの をデバッグしている。

「小さな一手の誤り が連鎖する。“もう一度頼む” しか武器がない と、直したい根本 ではなく モデルの直前のミス を追いかけ続けることになる。」

✅ 要点: 複数ターンの自己改善ループ では珍事ではなく既知の挙動。contracts / tests / verification pass といった 外部のソース・オブ・トゥルース がなければ、“もう一回プロンプト” は誤りを 広げがち。

A special note: “Spec-driven agentic flows” は必要だが、それだけでは足りない 📐

最近は spec-driven な agentic IDE / “software factory” が増えています。例：Amazon Kiro, 8090.ai（Chamath の “Software Factory”）、GitHub Spec Kit。方向性は正しい。PRD / spec / task といった 構造 をループに足すこと。

同意点:
spec-driven は必要。カオスを減らし、エージェントに 計画 を与え、明白なミスマッチを減らす。

現実チェック:
それでも hallucination / non-determinism は消えない。アプリが大きくなるほど、日々の編集ほど、自己修正ループが収束しない、長文脈がドリフト する、小さな修正が別の不整合 を産む、は普通に起きる。構造は助けになるが終点ではない。

僕らのやり方（学び）:
Prompt.Build でも PRD → tasks → contracts → code の spec-driven agentic flow を回しています。これは ミスマッチを減らす。ただ、スケール すると 誤りの累積 と 文脈ドリフト は依然として出る。だから guardrails が要る。

「Specs は必要条件、十分条件ではない。 進むべき方向を示すが、アプリが大きくなり編集が積み上がる時に ドリフトを防ぐのは guardrails だ。」

✅ 要点:
specs + agents は正しい次の一歩。ただし それだけでは足りない。Prompt.Build では verification と portability guardrails を組み合わせ、UI/API/schema を同期 させ、ドリフトを本番前に止める。詳細は次回に。

Quick FAQ ❓

1. vibe-coding とは？
   やりたいことをAIに伝え、特に画面まわり を高速に作ってもらうやり方。
   

2. vibe-coding は有効ですか？
   スピード/デモ/プロトタイピング には最適。ただし 画面とバックエンドの整合 が崩れると難しくなる。
   

3. デメリットは？
   名前 / データshape / ステータスコード の小さな不一致が積み重なる。修正でトークンが想定以上に燃える。特定のbackend provider に縛られる ことも。
   

4. vibe-coding は無料ですか？
   NO。トークン課金。小さな修正でも 広い再生成 が走り 高くつく ことがある。
   

5. どのツールが「ベスト」ですか？
   本当のコードとしてエクスポート でき、他環境で動かせる ものを。Portability > ロゴ。
   

6. vibe-coding はプログラマを置き換えますか？
   置き換えない。データモデル/セキュリティ/デプロイ/完成の定義 は人が決める。
   

7. 「contract drift（契約のズレ）」とは？
   UI と API の期待がズレる。UI は customerId を期待、API は customer_id を返す。200 vs 204。見た目は動いていても、ある日壊れる。
   

8. デバッグ中にトークン消費が跳ね上がるのはなぜですか？
   小変更が 周辺ファイルの書き換え と 大きな文脈再送（tool calls） を誘発。似た修正でも コストは大きくブレる。
   

9. 月額プランが作り方に合わないのはなぜですか？
   多くのチームは 短期集中 で作る。欲しいのは ビルドウィンドウ/作業単位の課金 であって、月 ではない。
   

10. 誤りの積み重なり（compounded hallucination）」とは？
    小さなAIの誤り が次の“修正”を呼び、別の場所が変わり、やがて 雪だるま になる。
    

11. Spec-driven のエージェントフローだけで十分ですか？
    助けにはなる が それだけでは足りない。整合性を守るチェック が必要。
    

12. バックエンドのロックインを避けるには？
    auth と data をプラガブルに。provider固有の呼び出し を全体にばら撒かず、層に閉じ込める。

なぜこれを書いているのか（この先の話）🚀

僕らが Prompt.Build を立ち上げたのは、vibe-coding が開いた可能性を愛しているから——そして フロントの後ろ側で同じ壁 に何度も当たったから。次回は、spec-driven を越えて machine-checkable な単一の契約レイヤ、atomic migrations、contract-aware tests をどう組み合わせ、再現性/可搬性/スピード を保ちながら 無駄なトークンを燃やさない かを共有します。

ここに挙げた課題に心当たりがあれば、ぜひあなたの経験も聞かせてください。下に コメント を残すか、このメールに 返信 してください（全部目を通しています）。フォローアップを受け取りたい方は Subscribe をどうぞ。🔔

— Ivan, co-founder/CEO, Prompt.Build
https://prompt.build

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.

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❓

1. 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.
   

2. Vibe-coding é bom?
   Sim para velocidade, demos e prototipagem. Fica puxado quando a UI e o backend param de concordar.
   

3. 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.
   

4. 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.
   

5. 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.
   

6. Vibe-coding vai substituir programadores?
   Não. Pessoas ainda decidem o modelo de dados, regras de segurança, como implantar e o que é “pronto”.
   

7. 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.
   

8. 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.
   

9. 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.
   

10. 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.
    

11. Fluxos agentic orientados por spec são suficientes?
    Ajudam muito, mas não sozinhos. Você ainda precisa de checks para manter tudo alinhado.
    

12. 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

I’m Ivan, co-founder/CEO of Prompt.Build. Before this, we were BeyondRisk AI-6 building enterprise AI systems. We adopted vibe-coding tools early to move faster. I’m very bullish - and I think we’re still at the very beginning of what’s possible. 🚀 This post documents the pains we keep hitting when real teams try to ship production apps with vibe-coding. No fixes in this post; I’ll share how we attempt to tackle them in my next post.

Also available in: 日本語 | PT-BR

What vibe-coding gets right (why we’re bullish) ✨

Vibe-coding - telling an AI what you want and letting it build - makes frontends fast. You can go from nothing to a real-looking app in one session: pages show up, navigation works, forms and tables appear, and the design looks consistent without long debates.

It also shrinks the path from idea → screen. Instead of tickets, wireframes, and handoffs, you describe what you need and see it right away. That quick loop makes you try more: test two layouts, swap components, tweak the copy before you spend days of engineering time.

And it’s no longer frontend-only. Most modern vibe-coding platforms wire in a ready backend - often via Supabase (managed or OSS) - so you can get auth, Postgres, row-level security, storage, and a clean SDK up on day one. That means demos and internal tools can feel “real” end-to-end, not just clickable shells.

✅ Bottom line: vibe-coding shines at speed, iteration, and shared understanding - and increasingly, at getting you to a functioning full-stack prototype demo quickly.

But once you leave the UI layer, the vibe changes.

The 5 problems we keep hitting in production ⚠️

1) Vibe-coding speed vs backend gaps 🔧

It’s true: most vibe-coding platforms now ship with a ready backend (often Supabase - auth, Postgres, RLS, storage, functions). So the issue isn’t “no backend.” It’s the wiring between the fast-changing UI and the backend contracts once real logic appears.

Where we keep seeing production pain:

• 🔍 Silent drift (UI vs API).
  Tiny differences blow things up later: customer_id vs customerId, UI expects 200 but the API returns 204, or a list changes from { data: [] } to just []. A quick backend tweak can make the screen read the wrong fields (id vs user_id) without an obvious error.

• 🧩 Screens fall out of sync.
  You fix “Edit Customer,” but “Orders” still uses the old data shape. Without one source of truth, each screen drifts a bit in its own way.

• 🗄️ Schema changes don’t land everywhere.
  Rename a column or tighten an enum for one place, and other pages/functions keep the old version - unless migrations ship together and the pipeline catches it. Supabase’s own guidance pushes migrations + CI to avoid exactly this class of errors.

• 🌗 Staging vs prod differences.
  Keys, base URLs, storage buckets, or policy switches aren’t the same. Preview works; prod throws 401/403/404. Classic “it worked on my branch” fire drill.

• 🔌 Workflow edges are brittle (jobs, webhooks, queues).
  The UI can say “Approve → Notify → Reconcile,” but wiring serverless functions, cron jobs, and webhook signatures (Stripe, Slack, GitHub) is brittle. Rate limits, retries, and idempotency aren’t handled by a prompt.

We often see issues happening once a project has 3-5 external integrations (payments, comms, identity, storage, analytics). That’s enough to trigger drift.

✅ Bottom line: shipping a backend isn’t the blocker anymore; coordinating UI ↔ API ↔ data contracts is. The faster the UI iterates, the easier it is for endpoints, schemas, and policies to fall out of sync - especially as integrations grow beyond CRUD (payments, audit logs, third-party APIs, background jobs).

2) Supabase coupling 🧩 and why “export & continue” still isn’t code you truly own

Most modern vibe-coding platforms wire into Supabase (managed or OSS) for a day-one backend: Postgres + Auth + RLS + Storage + Edge/Functions + Realtime. That’s a huge win - login, tables, policies, and files in hours, not weeks, and demos feel real end-to-end.

When the backend lives inside a provider, you don’t fully “own” the primitives; you bind to how that provider implements them (auth/session shape, RLS policy style, SQL extensions, storage paths & ACLs, Realtime channels, client SDK semantics).

So even if you export from a platform (Lovable/Bolt/Replit) and continue in Claude Code/Cursor/Codex or another assistant, you’re typically exporting front-end code around a provider-shaped backend. That’s not bad - it’s the natural cost of moving fast on a great stack - but it’s attachment, not independence.

Where this shows up:

• Portability work later. Moving to vanilla Postgres/RDS/Aurora or a different backend means remapping policies, auth/session handling, storage semantics, and SDK calls.

• Ops/observability stay provider-shaped. Incidents, logs, metrics, quotas, and runbooks follow the provider’s patterns; swapping means retraining and re-tooling.

• Customization ceiling. You can’t always modify the underlying auth/queue/storage internals the way you would if they were generated into your repo/infra.

We’re not anti-Supabase - we’re pro-ownership. It’s an excellent fast-start backend. We just call the coupling early so teams can plan portability and exit paths - or decide to generate/own more of the backend code when it matters.

Practical take: use Supabase confidently for speed, and keep escape hatches:

• Treat auth and data as interfaces (thin auth boundary + data-access layer).

• Wrap storage/webhooks/queues behind your functions so URLs/signatures/providers can change.

• If ownership is critical, target a path where your vibe-coding flow can emit the backend primitives as code/infrastructure you can edit, review, and redeploy anywhere.

3) Token-burn during the debugging loop 🔥💸

Even with newer cost controls like prompt caching from OpenAI and Anthropic, token spend during iterative debugging is still hard to predict. Caching discounts repeat context, but real-world loops still include retries, tool calls, and non-local edits that re-send large context - so two “tiny fixes” can differ by 10–50× in tokens depending on what the model decides to touch and how often context is reloaded.

🔥 Why the burn persists today:

• Non-deterministic edits. A small prompt often triggers broader rewrites across adjacent files or types, forcing larger contexts to be re-processed on the next pass. (Vendors mitigate with caching/credits, but they don’t eliminate wide diffs.)

• Retry/tool thrash. Rate limits, schema mismatches, or tool re-plans re-stream the same (or larger) context. Caching helps but doesn’t cover every path or cache miss.

• Pricing signals reflect the variance. Platforms are shifting to usage/effort-based or token-tier pricing precisely because workload can swing widely between “one and done” and “multiple exploratory passes.” Users frequently report blowing through token or credit pools faster than expected.

🤷‍♂️ Where the uncertainty bites:

• You can’t reliably forecast cost per fix - the same-looking change can fan out unpredictably.

• You pay just to confirm “nothing else changed,” since verification itself re-consumes context.

• Teams struggle to budget the build phase because spend tracks the number and breadth of regeneration rounds, not just feature count.

✅ Bottom line: the pain isn’t only expense - it’s lack of transparency and predictability. Even with caching discounts, developers lack a stable unit of work to estimate “how much will this fix cost?” during active iteration.

4) Monthly subscription plans don’t match how we build 🗓️⏱️

Most platforms sell monthly plans with token limits. Most teams don’t build all month. They sign up, build hard for 5–10 days, ship a demo, export to an AI code assistant (Cursor, Claude Code, etc.), and stop. Users don’t want a calendar - they want a predictable way to pay for a chunk of work.

🧠 Why this hurts users:

• You pay for idle time. After the push week, the rest of the month sits unused.

• Budgeting is messy. A small fix can eat more tokens than expected; cost per task isn’t clear.

• Wrong unit of value. You’re forced to buy time (a month) instead of work (build attempts, regen rounds, a deployable outcome).

• Context switches. After exporting to code assistants, you’re still paying for a plan you don’t need.

✅ What users actually want:

• Pay for a build window, not a month - e.g., 3–7 day passes.

• Clear units of work (e.g., N regenerations, M contract checks, one deployable build).

• No penalty for pausing. Stop, come back later, pick up where you left off.

“Builders don’t think in months. They think in sprints - ‘get this feature working, then pause.’ Pricing should match that: pay for a focused build, not for a calendar page.”

✅ Bottom line: users need predictable, task-aligned pricing - pay for the work you do in short bursts, then pause. Monthly + tokens makes simple projects feel expensive and hard to plan.

5) Compounded Hallucination Errors: Why Small LLM Mistakes Snowball 🌀

Multi-step prompting can amplify small mistakes. LLMs often fail to reliably self-correct without external feedback; in many cases, “self-correction” loops can even degrade the answer quality. In multi-turn settings, errors tend to compound as context shifts and non-determinism introduces fresh inconsistencies.

🧪 Why this happens today:

• Self-correction limits. Studies show intrinsic self-correction (model fixes itself from its own output) is unreliable and can worsen reasoning.

• Non-determinism between runs. Even “deterministic” settings yield variable outputs across attempts, so a fix in step N may introduce a new discrepancy in step N+1.

• Long-context drift. The longer the edit chain, the more latent drift accumulates and the harder it is to detect or reverse it.

🧵 What it feels like for teams:

• Names, shapes, and states keep almost matching - but not quite - creating a patchwork that’s brittle under tests and migrations.

• “Re-ask to fix” triggers new side effects elsewhere, so you burn cycles verifying stability instead of shipping.

• After a few days, you’re debugging the drift itself, not the original feature.

“One small wrong turn can cascade. If your only tool is ‘ask again,’ you can end up chasing the model’s last mistake instead of fixing the real one.”

✅ Bottom line: compounding hallucination isn’t a rare edge case - it’s a known behavior of multi-turn, self-refining loops. Without an external source of truth (contracts, tests, verification passes), “just prompt again” often spreads the error instead of sealing it.

A special note: “Spec-driven agentic flows” are necessary, but not enough 📐

We’re seeing a new wave of spec-driven, agentic IDEs / “software factories.” Examples include Amazon Kiro, 8090.ai (Chamath’s “Software Factory”), and GitHub’s Spec Kit. The trend is right: add structure - PRDs, specs, tasks - into the loop.

What we agree with:
Spec-driven flows are necessary. They cut chaos, give agents a plan, and reduce obvious mismatches.

Reality check:
They don’t erase hallucinations or non-determinism—especially as apps grow or when you’re editing day after day. Self-correction loops often don’t converge, long contexts drift, and small fixes can still create new inconsistencies. Structure helps; it doesn’t end the problem.

How we do it (and what we’ve learned):
At Prompt.Build, we also run spec-driven agentic flows (PRD → tasks → contracts → code). This reduces mismatch. But at scale, you still see compounded hallucination errors and context drift unless you add guardrails.

“Specs are necessary, not sufficient. They point the model in the right direction; guardrails keep it from drifting when the app gets big and the edits pile up.”

✅ Bottom line:
Spec-driven agents are the right next step - but not enough on their own. At Prompt.Build, we go beyond spec-driven flows with verification and portability guardrails to keep UI/API/schema in lockstep and stop drift before it reaches prod. I’ll break down how we do this in my next post.

Quick FAQ ❓

1. What is vibe-coding?
   Using AI to describe what you want and having the tool build most of the app for you - especially the screens - very quickly.
   

2. Is vibe-coding good?
   Yes for speed and quick demos and prototyping. It gets tricky when the screens and the backend stop agreeing with each other.
   

3. What are the downsides?
   Little mismatches pile up (names, data shapes, status codes), fixes can burn a lot of tokens, and you can get tied to one backend provider.
   

4. Is vibe-coding free?
   No. You pay for tokens. A tiny fix can trigger a big re-generation and cost more than you expect.
   

5. Which tool is “best”?
   Pick the one that lets you export real code and run it elsewhere later. Portability matters more than the logo.
   

6. Will vibe-coding replace programmers?
   No. People still decide the data model, security rules, how things are deployed, and what “done” looks like.
   

7. What is “contract drift”?
   When your UI and API stop matching - one expects customerId, the other sends customer_id; one returns 200, the other expects 204. Things look fine until they break.
   

8. Why do tokens spike while debugging?
   A small change can make the AI rewrite nearby files and re-send large context in tool calls. Two similar fixes can cost very different amounts.
   

9. Why don’t monthly plans fit how people build?
   Most teams work in short bursts (a few days), not all month. They want to pay for a build window or a clear chunk of work - not for a calendar month.
   

10. What are “compounded hallucination errors”?
    A tiny AI mistake leads to another “fix,” which changes something else, and the errors snowball over time.
    

11. Are spec-driven agent flows enough?
    They help a lot, but not by themselves. You still need checks to keep things aligned.
    

12. How do I avoid backend lock-in?
    Treat your auth and data like plug-in parts. Don’t scatter provider-specific calls everywhere; keep them in one place so you can move later.

Why I’m writing this (and what’s next) 🚀

We founded Prompt.Build because we love what vibe-coding unlocked - and we kept hitting the same walls after the frontend. In my next post, I’ll share how we go beyond spec-driven agentic flows with a single, machine-checkable contract layer, atomic migrations, and contract-aware tests - so builds stay reproducible, portable, and fast without wasting tokens.

If you’ve hit any of these issues, I’d love to hear your story - leave a comment below or just reply to this email (I read every one). And if you want the follow-up, subscribe so it lands in your inbox. 🔔

— Ivan, co-founder/CEO, Prompt.Build
https://prompt.build