これがバイブコーディングに対する私の感じです。 私が試みるプロジェクトで、何らかの複雑なプロジェクトは、すぐに進歩します。物事は素晴らしく、超大国のように感じます。そうしたら。。。複雑さが増すと、物事は停止します。 私が作れると思うのは、この「バイブゾーン」に該当するプロジェクトだけです。 プロトタイプ、UI、製品など、シンプルで複雑さの少ないものはすべて、そのゾーンにぴったりと収まります。概念の証明、相互作用、そのようなもの。ツールは、そのスロットに収まるものを作ることができます。 だがしかし。 その複雑さの曲線が増すにつれて、すべてが粉々に崩れていきます。そして問題は、優れた製品設計プロセスには複雑さが増していることです。基本的なプロトタイプは、インタラクション、トランジション、優れたアフォーダンス、ホバー状態、何かを正しくリアルに感じさせる 1000 の小さなディテールを重ねるとすぐに、優れたプロトタイプに変わります。 バイブコーディングの利点は、動きが速く、物事をうまくやり遂げることができ、すべての作業をAIに任せることができることです。問題は、必要な複雑さが加わるとすぐに勢いを失うことです。やり直しを続け、コードを書き直し、無関係なものに影響を与え、他の問題を引き起こします。 しかし、その複雑さが加わると、すべてのバイブコーディングセッションは、すぐにモグラたたきのバグバッシングセッションに変わります。 これに対する解決策はわかりません。従来のプロトタイピングでは、複製、複雑さの追加、フレーム/シーンの作成、微調整、フォークなどが解決策となります。 しかし、バイブコーディングでは、1つの小さなプロンプトが文字通りすべてを破壊する可能性があります。私は、すぐに卵の殻の上を歩くことになる段階があります - それが暴走してすべてを壊さないように、文脈を与えすぎたり少なすぎたりしないようにしています。 これにはいくつかの例外があります。@cursorと@framer。 私はCursorで大きな進歩を遂げることができ、それを狭い文脈を与え、それが行う編集を承認する必要があります。これは正しいワークフローのように感じます。問題は、ビジュアル環境ではなくIDEであるため、それが作っているものが見えないことです。はい、ローカルビルドを作成したり、ブラウザを更新したりすることができます。しかし、視覚的な側面はコーディング体験から完全に失われます。これは開発者ツールです。 Framer は、ページ上の 1 つのコンポーネント内での狭い更新しか許可していないため、これを正しく行っています。 はい、一度に 1 つのことしか実行できないため制限がありますが、少なくともページ全体をゼロから作成し、プロンプト インターフェイスを通じてすべてを管理しようとはしていません。 これらは正しいアプローチのように思えます。 @Cursor: AI に編集を許可しますが、ユーザーがそれらの編集を承認し、コンテキストで表示できるようにします。 @Framer: AI が 1 つのファイルまたはコンポーネントのみを狭く編集できるようにして、複雑さを最小限に抑え、壊滅的な編集を減らします。 @Figma、@Lovable、@Bolt、@V0 などのツールがクールなプロトタイプを作成できると楽観的ですが、基本的なインタラクション プロトタイプ以上のことを行うとなると、壁にぶつかり続けます。彼らはIMOを少なくする必要があります。 これらのツールが、Cursor や Framer と同じ行にあるコントロールをさらに追加できることを願っています。また、これはチャート生成の方法と似ていること@Basedash付け加えておきます。しかし、私たちは通常の意味でのバイブツールではないので、類似点を描くのは少し難しいです。