9,488 文字
最近、私はバイブコーディングに夢中になっています。これは基本的にAIエージェントにコーディングをしてもらうことで、実際に自分でコードを書くことはほとんどありません。実際、まったく書いていないと言ってもいいでしょう。今回は、バイブコーディングを最大限に活用するために学んだことをすべてお伝えします。さっそく始めましょう。
まず、バイブコーディングや実質的にはエージェントコーディングと呼ばれるものについて簡単に説明します。これはCursorやWindsurfでエージェントベースのコーディングを使うことです。ここに「エージェントに質問して編集する」機能があります。これはコードを書き始めてTabキーを押すとその部分を補完するというものではなく、文字通りAIにアプリケーション全体を最初から最後まで書いてもらおうとするものです。これは少し難しく、確かにいくつかの制限があります。
まず私の環境設定ですが、CursorかWindsurfを使い、ほぼ独占的にClaude 3.7モデル、主に「thinking」バージョンを使用しています。ここではClaude 3.7 Sonnet thinkingを使っています。CursorやWindsurfでは、好きなモデルを設定できます。Cursorの設定に行くと、CursorまたはWindsurfが直接提供する定義済みのモデルリストがあり、下部にモデルを追加することもできます。カスタムモデルを追加する方法は、この「OpenAI API キー」を設定することです。これをオンにしてキーを追加し、ベースURLを上書きできますが、一度しかできないため、実質的にOpenAI以外のAPIサービスは1つしか持てません。しかし問題ありません。ここでGrokを使用し、Grokキーを入力しています。Grokは OpenAI APIの標準に合わせてフォーマットされているので、そのまま動作します。
どのモデルを選ぶにしても、エージェント機能で使用する場合は、エージェント的な振る舞いや関数呼び出し、ツール呼び出しをしっかりサポートしているものを選ぶことが重要です。ほとんどのモデルはそうではありませんが、Claude 3.7 thinkingはサポートしています。
まず最初にすべきことは、非常に具体的な仕様書を書くことです。つまり、構築したいものについて詳細な説明を書くということです。実際にはGrok 3を使用して「Twitterクローンとなるアプリケーションの仕様書を書いて、できるだけ具体的に。バックエンドにはPythonを使用します」と入力します。Enterを押すと、AIが技術仕様だけでなく、その操作方法や動作方法なども書いてくれます。ここではデータベーススキーマも記述されているのがわかります。これは本当に完全な仕様書で、APIエンドポイントなども含まれています。
完成したら、それをすべて取ってCursorに貼り付けます。その方法を見せましょう。新しいCursorウィンドウを開き、右上の「AIペインを切り替え」をクリックします。チャットウィンドウが開きます。最新バージョンのCursorであれば、エージェントがデフォルトになっているはずです。私はモデルとしてClaude 3.7 Sonnet thinkingを使用しています。
重要なのは、ここで仕様書を貼り付けることですが、その前にもう一つ重要なことがあります。特にコードベースが大きくなるにつれて重要になってくるのが、CursorルールまたはWindsurfルールです。両方のIDEがルールをサポートしています。ルールは基本的に、AIやエージェントに対して、どのようにコードを書いてほしいか、どのような技術を使用すべきか、どのようなワークフローを使用したいかを伝える方法です。
これは私にとって大きな発見でした。というのも、何かを構築しようとすると、仕様書にない技術を使って構築し、他のものが壊れることがよくありました。バグがあってそれを修正しようとすると、別の技術を使おうとするのです。良い例としては、すべてにSQLデータベースを使いたかったのですが、SQLデータベースに問題があるたびに、エージェントはJSONファイル保存に切り替えて修正しようとしました。これは非常に迷惑でした。動作していると思っていたのに、データベースに何も表示されないなどの問題が発生したからです。
実際のプロジェクトに戻り、ルールがどこにあるかをお見せします。Cursorの設定で、下のルールに進みます。ユーザー固有のルール（任意のプロジェクト用のルール）を持つことができますが、プロジェクトルールに追加するのが好きです。新しいルールを追加すると、本質的にこのcursorフォルダが作成され、その中にrulesフォルダができます。これらのMDCファイルはすべてルールで、AIが作業するためのシステムメッセージのように参照することができます。
それでは、私のコーディング設定を見てみましょう。これは自然言語で書かれた説明です。異なるファイルを自動添付することもできますが、私はそれを使用していません。コーディングパターンの設定を見ていきましょう。なぜこれらを追加したのか、それぞれについて説明します。時間の節約になるはずです。これらはAIコーディングエージェントがうまく機能しない傾向を反映しています。
「常にシンプルなソリューションを好む」これは説明不要でしょう。「コードの重複はできるだけ避ける」これは、同様のコードや機能をすでに持っているコードベースの他の領域をチェックすることを意味します。新しい機能を追加したり、古い機能を修正しようとしたりすると、そのコードがすでに存在しないと思って、コードを重複させることがよくありました。だから今は明示的に「どこでもチェックして、このコードがすでに存在しないか確認し、もし存在するなら新しいコードを追加するのではなく、それを修正する」と言っています。
もう一つ苦労したのは、AIエージェントが開発、テスト、本番環境の分割についての理解が不十分だったことです。これは私にとって非常に大きな学びでした。変更を加え、テストを書くと、テストが開発環境に影響し、本番環境がローカルのものを使おうとするなど、混乱が生じました。そこで「あなたがすることすべてについて、開発、テスト、本番環境を分けたいと考慮してください」と指示しています。
別の問題は「要求された変更のみを行い、十分に理解され、要求された変更に関連していると確信できる変更のみを行う」ということです。変更を要求すると、コードの一部、機能の一部を変更するだけなのに、ほかの3つのものが理由もなく壊れることがありました。他のコードに触れようとしていただけだったので、「要求したことだけに集中するように」と強調しています。
もう一度言いますが、「要求したことだけに集中し、新しいものを導入しないでください」。「問題やバグを修正する場合、既存の実装のすべてのオプションを使い果たさずに、新しいパターンや技術を導入しないでください。最終的にそれを行う場合は、古い実装を後で削除して、重複したロジックを持たないようにしてください」。これも問題でした。何かが一つの方法で行われていて、完璧に機能していなかった場合、「これを修正して」と言うと、それを修正するのではなく、新しいコードだと思って全く別の方法で書き直すことがありました。これで修正されると良いのですが。
「コードベースを非常にきれいで整理された状態に保つ」。私はよくコードの整理されていない状態を見つけることがありました。「可能であればスクリプトやファイルの作成を避ける。特にスクリプトが一度だけ実行される可能性が高い場合」。エージェントがテストをしているとき、APIエンドポイントやページが壊れている場合、それをテストするためのスクリプトを書くことがありましたが、それはいいのですが、そのスクリプトをコードベースに残したままにして、二度と使われない可能性が高い一回限りのスクリプトがたくさんあるような状態になっていました。だから、スクリプトを書いてそのまま実行するか、スクリプトが終わったらファイルを削除するようにしてほしいのです。
次は明らかなことですが、「200〜300行を超えるファイルは避け、その時点でリファクタリングする」。これは通常、固定のルールとしては適切ではないかもしれませんが、AIにとっては適切だと思います。非常に大きなファイルをよく見つけ、リファクタリングを依頼すると、気づいた時にはリファクタリングがすべてのテストを壊してしまい、時間がかかってしまうことがありました。だから先手を打って、サイズが制限に近づいたらすぐにコードをリファクタリングするようにしています。
また、モックデータをたくさん使っていることにも気づきました。これは基本的にバックアップの偽のデータを持つということですが、開発や本番環境ではうまく機能しません。例えば、記事をスクレイピングするように依頼して、何らかの理由でスクレイピングが失敗した場合、エラーをキャッチしてモックデータに頼り、すべてが機能していると考えますが、実際には機能していません。私が本当に望んでいたのは、データを適切にスクレイピングすることでした。常にモックデータを使用していて、それは非常にフラストレーションでした。そこで明示的に「開発や本番環境でモックデータを使用しないでください。テスト環境でのみ使用してください」と言いました。そしてさらに「開発や本番環境に影響するコードにスタブや偽のデータパターンを追加しないでください」と重ねて言いました。
次に、私のenvファイルを上書きしていることに気づきました。APIキーを頻繁に取得する必要があったので、「それをしないでください」と言いました。
もう一つのルールは、私の技術スタックです。もっと詳細にすることもできましたが、これはあなたの技術スタックです。なぜなら、SQLが機能しない場合、ファイル内のJSONストアに切り替えるだけで、それは私が望んでいなかったからです。だから「バックエンドはPython、フロントエンドはHTML、JS、データベースはSQL、JSONファイルストレージは絶対に使わない、開発、テスト、本番環境には別々のデータベースを使用する」と言いました。また、「検索にはElasticsearchを使用し、ホスト版を使用する」としています。Elasticsearchについて話すと、ローカルで実行したいと思われることがありましたが、ホスト版だけを使用したかったのです。そしてPythonのテストについても言及しています。
次に私のコーディングワークフローの設定です。ここには重複する情報もありますが、より多くのガイダンスを提供することを目指しています。「タスクに関連するコードの領域に集中し、タスクに関連しないコードに触れないでください」。明らかに、これについて多くの問題に遭遇しました。「すべての主要な機能に対して徹底的なテストを書く」。私はこれを手動で行っていました。コードを書いてもらい、「そのテストを書いて」と言うことがありましたが、時々忘れることがありました。だから今はすべての主要な機能に対してテストを書くべきです。「明示的に指示されない限り、機能が正常に動作することを示した後、その機能の動作パターンやアーキテクチャに大きな変更を加えることを避ける」。「この問題を修正して」と言うと、修正するために基本的に元のパターンを捨てて、他のパターンや技術を使って最初から書き直すことがありました。私はそれを望んでいませんでした。すでにあるものを修正してほしかったのです。「常にコード変更によって影響を受ける可能性のある他のメソッドやコード領域について考えてください」。
これらがルールです。もっと追加することもできますし、適切だと思うだけの指示を与えることができます。これは進める上で本当に役立つでしょう。
さて、完全な仕様書をGrokで作成しました。私がするのは、明らかにそれを確認し、Grokやその他のAIと協力してそれが本当に望むものであることを確認し、適切な変更を加え、すべてをコピーしてここに貼り付けることです。それですべて準備完了です。
すべてハイライトして、ウィンドウに貼り付けて「この仕様に基づいて構築してください」と言いましょう。それを見てみましょう。進んでいきますが、見守る必要はないでしょう。しばらくすると何が起きるか見せますが、その間にもう少しベストプラクティスをお見せします。
既存のコードに戻りますが、注目すべきは右側のパネルです。これはあなたが与えているすべてのコンテキストです。これは重要です。なぜなら、ある時点でコンテキストが多すぎると、パフォーマンスが低下し始めるからです。会話がどれくらい長くなるか、新しいチャットを始める前にどれくらいコンテキストを与えるかに非常に注意する必要があります。ここで濃い灰色で「より良い結果を得るために新しいチャットを開始する」と表示されています。これは試行錯誤で理解していく必要があります。新しいチャットを始めるとコンテキストが失われます。一部のコンテキストを新しいチャットウィンドウに移動することはできますが、それは面倒です。できるだけ多くのコンテキストを与えたいですが、多すぎるとパフォーマンスが低下し始めるので、これをいじってみてください。
新しいチャットを始めます。もう一度クリックします。最初にすることはワークフロー設定を挿入することですが、毎回すべてのルールを入れたいので、「私のスタック」と「コーディング設定」をクリックします。これで3つのルールのコンテキストが得られました。自動的に行うかどうかはわかりませんが、これら3つのファイルを手動で挿入する必要があるようです。
次の提案はエージェントへの要求を非常に狭く保つことです。小さなことを修正したり、小さな機能を追加したりして、できるだけテストをするようにします。テストを書かせてください。テストは別物です。私が見つけたのはエンドツーエンドのテストが最もうまくいくということです。ユニットテストではなく、実際にクリックして利用者としてあなたがやることを試行するテストです。
毎回何かを書いたら、テストを実行して、テストがパスすれば素晴らしいし、パスしなければテストを修正させることを覚えておいてください。しかし、テストの修正は注意が必要です。時にはテストを本番環境に影響を与える方法で修正することがあります。実際には単にテストの失敗に対処するだけでよい場合もあります。常に注意を払う必要がありますが、自分でコードを書いたり手動で調整したりする必要はありません。テストがパスすることを確認し、統合テストで確認するか、単にアプリに自分で行ってその機能を自分でテストしてください。
ここを見ると、あらゆるものに対するたくさんのテストがあります。もう一つの提案は、人気のあるスタックを使用することです。何か新しい技術を使用している場合、AIはおそらくそのコーディング言語やスタックへの露出がそれほど多くないため、うまく機能しないでしょう。そのため、本当に一般的なスタックを選ぶことをお勧めします。私はPython、フロントエンドのHTMLとJavaScriptが好きで、非常にシンプルに保ち、データベースにはSQL、検索にはElasticsearchを使いますが、非常に人気のある技術スタックを選べば、AIが調べるためのドキュメントがたくさんあります。
実際のチャットがどのように見えるか例を示しましょう。これは以前構築した機能です。「タグの最大長を20文字に制限し、すでにこのためのコードがないことを確認し、実装後にテストを書いてください」と指示しています。明らかに何度も何度もコード方法を強調していますが、それは害にはなりません。
送信すると始まります。最初に考え、その思考プロセスを読むことができるのは本当に素晴らしいことです。次にツール呼び出しがあります。「ディレクトリのリスト」「ファイルの読み取り」「ファイルの検索」など、利用可能なツールがたくさんあります。MCPサーバーを使用して外部ツールを提供することもできますが、それは別の問題です。実際にはまだコードでそれを使用していませんが、もう少し試す必要があります。別の動画のためにそれを取っておきます。
ここですべてが起こっているのが見えます。実際にクリックして掘り下げ、エージェントがあなたのコードベースとどのように動作するかを理解することができます。下にスクロールします。ファイルを読み込み、「コードベースの分析に基づいて、これが見つかりました」と言い、何をするかを教えてくれます。
実行には3つの設定があります。完全に手動で行うことができます。つまり、ファイルに影響を与える可能性のある変更や実行を行うたびに、毎回手動で承認する必要があります。私はYOLOモードを使用しています。文字通りYOLOモードと呼ばれ、それはすべてを自動実行するということです。もちろんリスキーです。なぜならGitHubにプッシュしたり、本番環境にデプロイしたりするからです。実際に本番レベルのコードベースがあり、人々がそれを使用している場合、それはお勧めしませんが、最初からバイブコーディングをする場合は問題ありません。また、中間的なものもあります。「Auto」と呼ばれていると思いますが、それは自動的に行うものと承認を求めるコマンドを決定するということです。
変更が加えられ、テストが実行されているのが見えます。すべてのテストがパスしています。すべてのテストのうち1つのテストが失敗しました。失敗したテストを修正する必要があります。なぜ失敗したのかを調べて、コードを変更し始めています。ここでもっとモックリポジトリがあります。それは本当に私をイライラさせました。だから開発や本番でモックやスタブデータを使わないように5回も言及したのです。
続行して、すべてのテストがパスしました。素晴らしい。最後に変更されたすべての内容の要約が表示され、そのまま続行しました。しかし、続行すればするほど、コンテキストウィンドウが肥大化していくことを覚えておいてください。意味があるときには頻繁に新しいチャットを始めたいと思うでしょう。これは非常に規範的なルールではありませんが、自分に最適なものを見つける必要があります。
私は本当にエージェントに物事をしてもらうことに非常に依存するようになりました。「このコードをコミットして、良い説明を書いて、Herokuにデプロイして」と言うと、それをやってくれました。本当に問題はありませんでした。ただ、これらすべてはかなり遅いです。今の時点で少し甘やかされていると感じています。これらのものが遅いと言っていますが、実際には私が書けるよりもはるかに短い時間でもっと多くのコードを書いているからです。しかし、送信するコマンドごとに、2分から時には15分までかかることがあります。反復サイクルが終わるまで待ちます。テストを行い、物事を試し、テストを実行し、テストが失敗すると修正し、動作を確認します。その意味では少し遅いです。
その解決策の一つは、異なるCursorウィンドウを開いて、異なるブランチで操作させることです。同時に2つのブランチを進めることができ、それを複数回行うこともできます。つまり、同時に多くの異なるブランチで作業し、最後にそれらをすべてマージすることができます。
時々、Claude 3.7 thinkingとClaude 3.7 regular（非thinking）を行き来することがあります。thinkingがうまく機能する傾向がありますが、少し遅いです。また、時々「コードをリファクタリングして」と言うこともあります。「最も長いファイルを見つけてリファクタリングするが、リスクの低いリファクタリングを行う」などの指示を与えます。そうすると、パターンのリファクタリングではなく、コードをもう少しきれいに、もう少し整理されたものにするだけです。パターンをリファクタリングすると、あまりにも多くのものが壊れるからです。
変更を加えるのが非常に難しい段階に達しました。変更を加えると、それを正しく行うために、バグを修正するためにとても多くの反復が必要でした。もし前もってこれらすべてのことを知っていたら、もっと先に進むことができたでしょう。非常に中毒性があることを認めざるを得ません。別のことをしている時に、コマンドを書いて、この機能を構築して、離れて、それが働くのを見て、10分後に戻ってきて、それが機能したかどうかを確認します。反復して、離れて、戻ってくるということができます。ほぼ非同期で行うことができるもので、あなたは別のことをしながら、コマンドを次々と与えることができます。
私が望んでいたことの一つは、これを私の電話で利用できることです。Repetにはこのようなものがありますが、そのコーディングエージェントはあまり好きではありません。使うのがもう少し難しいです。本当に、電話で使える完全にホストされたバージョンがあればいいと思います。エージェントのようなものを使用すると、正当なコーディングがはるかに実現可能になります。電話で何かを入力するのは非常に簡単で、それを見て反復することができ、フルスクリーン、キーボード、マウスを必要としません。モバイルコーディングの可能性の世界が開かれつつあります。
最後にいくつかの提案です。頻繁にコミットしてください。頻繁にコミットすることをお勧めします。変更を加えるたびにコミットしていることを確認してください。修正不可能な状態になった場合でも、いつでもロールバックできます。そのもう一つのバージョンとして、チャット履歴を見ることができます。以前のチャットにロールバックできます。これをクリックするだけで「ダークモードを追加しました」とあります。一番上までスクロールして「チェックポイントを復元」と言えば、コードをロールバックしてくれます。Gitだけでなく、Cursor自体やWindsurf自体に組み込まれたバージョン管理もあります。
これらはすべて、異なるアプリケーションやゲームのバイブコーディングについて、約100〜150時間かけて学んだベストプラクティスです。とても楽しかったです。これらのツールがもっと良くなることを待ち望んでいます。これが今までで最悪の状態であり、現在経験しているこれらの問題や私が経験している問題は、将来的には対処しやすくなるでしょう。
バイブコーディングを楽しんでください。何か素晴らしいものを構築するために、コーディングについてほとんど知る必要はありません。皆さんにも構築することをお勧めします。この動画が気に入ったら、いいねとチャンネル登録を検討してください。次回の動画でお会いしましょう。
コメント