7,499 文字
こんにちは、私はYCのパートナーのトムです。この1ヶ月間、いくつかのサイドプロジェクトでバイブコーディング（AIを使った直感的なコーディング）を試してきました。それが驚くほど優れているだけでなく、工夫して最良の実践方法を取り入れることで、明らかに上達できる技術だということがわかりました。このビデオでは、バイブコーディングで優れた結果を得るための方法をいくつか紹介したいと思います。
これは1、2年前のプロンプトエンジニアリングのようなもので、人々は毎週新しい発見をして、ソーシャルメディアに投稿していました。最良のテクニックは、プロのソフトウェアエンジニアが使うテクニックと同じです。「それはバイブコーディングではなく、単なるソフトウェアエンジニアリングではないか」と言う人もいますが、それは見当違いだと思います。私たちはこれらのツールを使って最良の結果を得ようとしているのです。
YCのスプリングバッチが数週間前に始まったところです。バイブコーディングについてのアドバイスをする前に、創業者たちが今日のAIツールを最大限に活用するために使っているヒントを聞いてみましょう。
AIが実装できなかったり、デバッグできなかったりして行き詰まり、同じことを繰り返している場合、LLMのウェブサイト、文字通りUIに行って、コードを貼り付けて同じ質問をすると、なぜかIDEでは到達できなかった結果が得られることがあります。そうすれば問題を解決できます。
例えば、同じプロジェクトでCursorとWindsurfの両方を同時に使うといいでしょう。Cursorはもう少し速いので、フロントエンドやフルスタック的な作業、フロントエンドとバックエンドのリンクなどに使えます。Windsurfはもう少し長く考えます。以前は「このエージェントを構築して」とか「このプロンプトを修正して」と入力しながら、スマホでスクロールしていました。Windsurfが考えている間に、Cursorに行ってフロントエンドの更新を始めることができます。
時には両方を同時に読み込んで、同じコンテキストを持たせることもあります。フロントエンドを更新しようとしている場合、そのファイルのスタイルでスタイリングするように指示し、両方でEnterキーを押します。すると、同じフロントエンドの少し異なるバージョンが両方から提案されるので、好きな方を選ぶことができます。
私のアドバイスは、AIを別の種類のプログラミング言語と考え、バイブコーディングを新しいタイプのプログラミング言語と考えることです。コードではなく言語でプログラミングするため、良い結果を得るためには、必要なコンテキストや情報を非常に詳細に提供する必要があります。
私は通常、逆方向からバイブコーディングを始めます。まずテストケースから始めるのです。テストケースは手作業で作成し、LLMは使いません。それが完了すると、コードを生成するためにLLMが従うべき強力なガードルールができます。そうすれば、LLMは自由にコードを生成でき、テストケースに緑のフラグが表示されれば、仕事は完了です。コードベースを細かく管理する必要はなく、コードのモジュール性を概観するだけでよいのです。
何を構築しようとしているのかの範囲と実際のアーキテクチャを構築するために、純粋なLLMに非常に多くの時間を費やすことが非常に重要だと思います。それをCursorや他のコーディングツールに任せる前に、コードベースで自由に実行させて、実際には機能しないものを作らせないようにします。構築しようとしているものの実際の目標を理解していることを確認してください。
LLMが質問に答える際に、袋小路に入っていないかどうかを本当に監視することをお勧めします。コードを何度も再生成して怪しげに見え、うまく解決できていないと気づいた場合、常にエラーメッセージをコピー＆ペーストしている自分に気づいたら、それは何かがおかしくなっているのかもしれません。一歩引いてLLMに「一歩引いて、なぜ失敗しているのかを調べてみましょう。LLMが解決できるだけの十分なコンテキストを提供していないのか、それとも単に運が悪くて要求を実行できないのか」と促すべきです。
ここでの包括的なテーマは、LLMに優れたプロのソフトウェア開発者が使用するプロセスに従わせることです。それでは、私が見てきた最高のバイブコーディングのアドバイスをいくつか詳しく見ていきましょう。
まず、どこから始めればいいでしょうか。もし以前にコードを書いたことがなければ、RepletやLovableのようなツールを使うといいでしょう。使いやすいビジュアルインターフェースを提供してくれ、新しいUIを直接コードで試すのに最適な方法です。多くのプロダクトマネージャーやデザイナーは、Figmaのようなものでモックアップをデザインするのではなく、新しいアイデアの実装を直接コードで行うようになっています。とても早いからです。
しかし、私がこれを試したとき、UIには感心したものの、純粋なUI変更ではなく、バックエンドのロジックをより正確に修正したい場合に、Lovableのようなツールはうまくいかなくなりました。ここでボタンを変更すると、バックエンドのロジックが奇妙に変わってしまうのです。
以前にコードを書いたことがあるなら、私のように少し錆びているとしても、おそらくWindsurf、Cursor、Claude Codeのようなツールに直接飛び込むことができるでしょう。
使いたいツールを選んだら、最初のステップはコードを書き始めることではありません。代わりに、LLMと協力して包括的な計画を作成し、それをプロジェクトフォルダ内のマークダウンファイルに入れ、常に参照することをお勧めします。これはAIと一緒に開発し、プロジェクトを実装する際に段階的に進んでいく計画で、全体を一度に実装しようとするのではありません。
この計画の最初のドラフトを作成した後、好きではない部分を削除します。特定の機能を「実施しない・複雑すぎる」と明示的にマークしたり、「後で検討するアイデア」のセクションを保持して、LLMに「これは検討したが、今は範囲外だ」と伝えるといいでしょう。
計画ができたら、LLMと協力してセクションごとに実装していきます。「今はセクション2だけをやろう」と明示的に言います。それが機能することを確認し、テストを実行し、コミットします。次にAIに計画に戻ってもらい、セクション2を完了としてマークします。
特に複雑な場合、モデルが製品全体を一度に実装することを期待すべきではないでしょう。私はこれを一つずつ行い、各ステップの実装が機能していることを確認し、重要なのはGitにコミットすることです。そうすれば、次のステップで何か問題があっても元に戻すことができます。
ただし、このアドバイスは今後2、3ヶ月で変わるかもしれません。モデルは非常に急速に改善されているため、近い将来どうなるかを言うのは難しいです。
次のヒントは、バージョン管理を使用することです。バージョン管理はあなたの味方です。Gitを徹底的に使いましょう。ツールには元に戻す機能がありますが、まだ信頼していないので、新機能を始める前に常にGitがクリーンな状態であることを確認します。そうすれば、AIが迷子になった場合に、既知の動作バージョンに戻すことができます。
うまくいかない場合は「git reset –hard HEAD」を恐れずに使い、もう一度やり直してください。AIに複数回プロンプトを出して何かを動作させようとすると、根本原因を本当に理解するのではなく、悪いコードの層が積み重なっていってしまいます。4、5、6回と異なるプロンプトを試して、ようやく解決策を見つけた場合、その解決策だけを取り出し、git resetしてから、クリーンなコードベースに対してその解決策をAIに与え、層の重なったクラフトなしでクリーンな解決策を実装するといいでしょう。
次にすべきことは、テストを書くか、LLMにテストを書いてもらうことです。彼らはこれが得意ですが、しばしば非常に低レベルなユニットテストをデフォルトで書きます。私はこれらのテストを超高レベルに保つことを好みます。基本的に、誰かがサイトやアプリをクリックして進む様子をシミュレートし、機能がエンドツーエンドで動作していることを確認したいのです。関数を単位ベースでテストするのではなく、高レベルの統合テストを書いてから次の機能に移るようにしてください。
LLMは無関係なロジックに不必要な変更を加える悪い癖があります。あちらのものを修正するように指示すると、こちらのロジックを全く理由もなく変更してしまうのです。これらのテストスイートを実施することで、LLMが無駄な変更をしたときに早期に発見でき、git resetして再開することができます。
LLMはコーディングだけではないことを覚えておいてください。サイドプロジェクトを構築する際、私はコーディング以外の多くの作業にLLMを使用しています。例えば、Claude Sonnet 3.7に私のDNSサーバーの設定（いつも嫌だった作業）や、コマンドラインツールを通じたHerokuホスティングの設定をしてもらいました。それは私のDevOpsエンジニアとなり、進捗を10倍速くしました。
また、サイトのファビコン（ブラウザの上部に表示される小さなアイコン）を作成するためにChat GPTを使用し、次にClaudeがそのイメージを取り、異なるプラットフォーム全体でファビコンに必要な6つの異なるサイズとフォーマットにリサイズするための使い捨てスクリプトを書きました。AIは今や私のデザイナーでもあります。
では、バグ修正について見ていきましょう。バグに遭遇したときに最初にすることは、エラーメッセージをそのままLLMにコピー＆ペーストすることです。サーバーのログファイルやブラウザのJavaScriptコンソールからのものかもしれません。多くの場合、このエラーメッセージだけでAIが問題を特定して修正するのに十分です。何が問題なのか、何が間違っていると思うのかを説明する必要さえありません。単にエラーメッセージだけで十分です。
これは非常に強力なので、すぐに主要なコーディングツールがすべて、人間がコピー＆ペーストしなくてもこれらのエラーを取り込めるようになると思います。考えてみれば、私たちの価値がコピー＆ペーストマシンであるというのは少し奇妙ですよね。思考はLLMに任せているのに、このコピー＆ペーストは窓から出ていくでしょう。LLMツールはログを監視したり、ヘッドレスブラウザを起動してJavaScriptのエラーを検査したりできるようになるでしょう。
より複雑なバグでは、コードを書く前に3〜4つの考えられる原因をLLMに考えてもらうことができます。バグ修正の各試みが失敗した後、私はgit resetして再開します。再び、層と層のクラストを蓄積しないためです。リセットせずに複数回バグ修正を試みないでください。LLMは単により多くのクラップの層を追加するだけです。git resetして再開し、ログを追加します。ログは味方です。疑わしい場合、機能していない場合は、モデルを切り替えてみてください。Claude Sonnet 3.7かもしれないし、OpenAIのモデルの一つかもしれないし、Geminiかもしれません。異なるモデルが他のモデルが失敗するところで成功することがよくあります。
最終的に厄介なバグの原因を見つけた場合、すべての変更をリセットし、LLMに綺麗なコードベースでその特定のバグを修正するための非常に具体的な指示を与えることをお勧めします。これにより、ジャンクコードの層が蓄積するのを避けることができます。
次のヒントは、LLMのための指示を書くことです。これらの指示を、Cursorルール、Windsurfルール、Clawマークダウンファイルなど、各ツールによって命名規則が少し異なりますが、そこに入れてください。AIコーディングエージェントに何百行もの指示を書いた創業者を知っていますが、それによって彼らははるかに効果的になっています。これらの指示ファイルに何を入れるべきかについてはオンラインで多くのアドバイスがあります。自分で見つけてみてください。
ドキュメントについて話しましょう。これらのエージェントをオンラインのウェブドキュメントに向けることは、まだ少しパッチ状態だと思います。MCPサーバーを使用してこのドキュメントにアクセスすることを提案する人もいますが、一部の人にはうまくいくものの、私には大げさに思えます。私はしばしば、特定のAPIセットのドキュメントをすべてダウンロードし、作業フォルダのサブディレクトリに置いて、LLMがローカルでアクセスできるようにします。そして指示の中で「これを実装する前にドキュメントを読んでください」と言うと、しばしばはるかに正確になります。
覚えておくべき注意点として、LLMを教師として使用できます。特にコーディング言語にあまり詳しくない人は、何かを実装してからAIにその実装を一行ずつ説明してもらうことができます。新しい技術を学ぶのに素晴らしい方法です。以前私たちがやっていたように、Stack Overflowをスクロールするよりもずっと良いです。
では、より複雑な機能を見ていきましょう。AIに通常信頼するよりも複雑な新しい機能に取り組んでいる場合、完全にクリーンなコードベースで独立したプロジェクトとして行うことをお勧めします。既存のプロジェクトの複雑さなしに小さな参照実装を動作させるか、誰かが書いてGitHubに投稿した参照実装をダウンロードします。次に、その実装をLLMに指示し、それに従いながら大きなコードベース内でそれを再実装するよう伝えます。これは驚くほどうまくいきます。
小さなファイルとモジュール性は味方です。これは人間のコーダーにも当てはまります。LLMが一貫した外部インターフェースを持つ明確なAPI境界内で作業できる、より小さいモジュラーやサービスベースのアーキテクチャへの移行が見られるかもしれません。巨大な依存関係を持つ巨大なモノレポではなく、これらは人間とLLMの両方にとって難しいのです。一箇所の変更がコードベースの別の部分に影響するかどうかが明確ではありません。したがって、一貫した外部APIを持つこの現代的なアーキテクチャがあれば、テストがまだ通過する限り、内部を変更できます。
正しいテキストスタックの選択に関する注意点です。私はRuby on Railsでプロジェクトの一部を構築することを選びました。主に専門の開発者だった頃から馴染みがあったからですが、特にRuby on Railsコードを書いている時のAIのパフォーマンスに驚かされました。これはRailsが20年前のフレームワークで、多くの確立された慣例があるためだと思います。多くのRailsコードベースは非常に似ており、経験豊富なRuby on Rails開発者には、特定の機能がどこに属すべきか、または特定の結果を達成するための正しいRailsの方法が明白です。これは、オンラインにRailsコードベースのかなり一貫した高品質のトレーニングデータがたくさんあることを意味します。
他の友人は、RustやElixirのような言語では、オンラインにそれほど多くのトレーニングデータがないため、あまり成功していません。しかし、それもすぐに変わるかもしれません。
次のアドバイスはスクリーンショットを使用することです。最近はほとんどのコーディングエージェントにスクリーンショットをコピー＆ペーストできます。これは、UI実装のバグを示したり、プロジェクトで使用したい別のサイトからデザインのインスピレーションを取り入れたりするのに非常に役立ちます。
音声は、これらのツールとやり取りするもう一つの本当にクールな方法です。私はYC企業のAquaを使用しています。基本的に、コンピュータに向かって話すだけで、Aquaが私が言っていることをツールに転写します。私は現在、WindinsurfとClawde Codeを頻繁に切り替えていますが、Aquaを使えば、効果的に毎分140語の指示を入力できます。これは私がタイプできる速度の約2倍です。AIは文法や句読点の小さなミスに非常に寛容なので、転写が完璧でなくても正直なところ問題ありません。実際、この講演全体をAquaで書きました。
頻繁にリファクタリングすることを忘れないでください。コードが動作し、重要なことにテストが実装されたら、テストが回帰をキャッチしてくれることを知って、自由にリファクタリングできます。LLMにコードベースの中で繰り返しが多い部分や、リファクタリングの良い候補になりそうな部分を特定してもらうこともできます。これも、プロのソフトウェア開発者なら誰でも従うヒントです。数千行の長いファイルを持たず、小さくモジュール化されたものにしておくと、人間とLLMの両方が何が起こっているのかを理解しやすくなります。
最後に、実験を続けてください。この分野の最先端は週ごとに変わっているようです。私は新しいモデルのリリースごとに試して、それぞれの異なるシナリオでどちらがより良いパフォーマンスを発揮するかを確認しています。例えば、デバッグ、長期計画の立案、機能の実装、またはリファクタリングに優れているものもあります。現時点では、Geminiはコードベース全体のインデックス作成と実装計画の作成に最適なようで、Sonnet 3.7は私にとって少なくとも、コード変更を実際に実装するための主要な候補のように思えます。
数日前にGPT 4.1を試しましたが、正直なところそれほど感心しませんでした。質問が多すぎて、実装を間違える回数も多すぎました。しかし、来週また試してみると、また状況が変わっていると思います。
視聴いただきありがとうございます。これらのモデルを最大限に活用するためのヒントやコツがあれば、ぜひコメント欄で共有してください。
コメント