バイブコーディングは、妥協を強いられることを意味しない。「私たちは、本番環境で通用する品質のソフトウェアを構築し、可能性の限界に挑戦したいと考えている」とヘディンは語った。開発チームは、手軽なプロトタイプ（試作品）の作成だけで満足することもできたはずだ。しかし彼らはそうせず、コードを学んだことのない人々のためにフル機能のアプリケーションを構築している。この組み合わせこそが、Lovableにおけるエンジニアリングを難しくしている要因だ。
バイブコーディングが壁に突き当たる「最後の10％」
ヘディンは、かつての時代から語り継がれているプログラマーのジョークを紹介した。「コードの最後の10％を仕上げるのに、全時間の90％がかかる」と彼は言い、続けてオチを明かした。「そして、最初の90％を書き上げるのにも、やはり全時間の90％がかかる。だから、結局180％の時間が必要になるのだ」。このジョークは的を射ている。プロジェクトの最初のドラフト（草案）は すばやく完成するが、それを仕上げるのには常に遥かに長い時間がかかる。バイブコーディングも全く同じだ。「完成させること」が壁となる。
その壁によって最も手痛い打撃を受けるのが、コードを書けない人々だ。バグに直面した開発者であれば、コードを開いて原因を追究することができる。しかし、抽象化されたレイヤーの上でプロダクトを構築している非技術者には、それができない。Lovableは、この状況を「is_stuck（行き詰まり）」と呼ばれるフラグで測定している。「同じ要求を3回連続で行った場合、このフラグが有効になる。つまり、ユーザーが『修正して、修正して、修正して』と繰り返している場合、行き詰まっていると判断するのだ」とヘディンは説明した。行き詰まることは、技術的な知識を持たない開発者にとって最悪の事態だ。
すべてのアプリが、次のアプリをより良くする
Lovableは、自社ツールに継続的な改善の仕組みを組み込んだ。「プラットフォーム上で構築されるすべてのアプリが、次のアプリの改善に役立つべきだ」とヘディンは言う。その取り組みの一環が「Lovable Overflow」だ。これは問題と解決策を蓄積したデータベースであり、ユーザーが既知の不具合に遭遇した際、軽量なAIモデルが主要なエージェントに適切な解決策を即座に提供し、ユーザーが行き詰まるのを未然に防ぐ。
