Anthropicの研究者が、「バイブコーディング」と呼ばれるAI主導のコード生成手法を本番環境で責任を持って実装する方法について解説している。従来のAI支援コーディングとは異なり、バイブコーディングはコードの存在を忘れて完全にAIに委ねる手法である。講演者は、AIの能力が指数関数的に向上する中で、この手法が今後必須となると主張し、22,000行の本番コード変更をClaude使って成功させた実例を紹介している。安全な実装のポイントとして、コアアーキテクチャではなくリーフノードでの実装、検証可能な設計、適切なテスト戦略などを挙げている。
バイブコーディングへの導入
皆さん、おはようございます。私は皆さんのお気に入りの話題、バイブコーディングについてお話しするために来ました。そして少し物議を醸すかもしれませんが、本番環境で責任を持ってバイブコーディングを行う方法についても触れていきます。
まずはバイブコーディングについて、そもそもこれが何なのかについて話していきましょう。まず自己紹介ですが、私はEricです。Anthropicでコーディングエージェントに焦点を当てた研究者をしています。私はBarry Zangと共に「効果的なエージェントの構築」の著者でもあり、この中でアプリケーションに関係なく、エージェントを作成するための最高の科学と最良の実践を皆さんに概説しました。これは私にとって非常に身近で大切な題材です。
実は昨年、私は職場へ自転車で向かう途中で手を骨折してしまい、2か月間ギプスをしていました。その2か月間、Claudeが私のコードをすべて書いてくれたんです。これを効果的に実現する方法を見つけ出すことは私にとって本当に重要で、幸運にもそれをうまく理解することができ、私の研究を通じてAnthropicの他の多くの製品やモデルにその知見を取り入れることができました。
バイブコーディングとは何か
まず、バイブコーディングとは何かについて話し始めましょう。多くの人がバイブコーディングをAIを使ってコードを生成することの広範囲な使用と混同しています。しかし、これは正確ではないと思います。多くの人がCursorやCopilotを使っていて、多くのAIを使い、多くのコードが自分で書くのではなくAIから来ています。しかし、そのようにモデルとの密接なフィードバックループの中にいる時、それは真のバイブコーディングではないと思います。
私がバイブコーディングと言う時、私たちはAndre Karpathyの定義に立ち返る必要があります。バイブコーディングとは、完全にバイブに身を委ね、指数関数を受け入れ、コードが存在することさえ忘れることです。ここで重要な部分は「コードが存在することさえ忘れる」ということです。
これが重要な理由は、バイブコーディングがエンジニアリング業界外の人々がコード生成に本当に興奮し始めた時だからです。CopilotやCursorは素晴らしかったのですが、主にエンジニア向けでした。しかし、コーディングの仕方を知らない人でも、バイブコーディングによって突然、アプリ全体を一人でコーディングしている自分を発見できるようになったのです。これは本当にエキサイティングなことであり、多くの人にとって大きな解放でした。
もちろん、これには多くの欠点がありました。初めてコーディングする人々が、実際に何をしているのか全く分からずにコーディングしていたのです。「ランダムなことが起こってる、APIキーの使用量を最大にしてる、人々がサブスクリプションを迂回してる、データベースにランダムなクソを作ってる」といった状況が見られました。これがバイブコーディングの起こり始めた欠点でした。
バイブコーディングの肯定的な側面として見られたのは、すべて本当に低いリスクのものでした。ビデオゲームを作ったり、楽しいサイドプロジェクトを作ったり、バグがあっても大丈夫なものでした。
なぜバイブコーディングを気にかけるべきか
では、実際の製品でやると非常にリスクが高そうで、最も成功した事例がこういったおもちゃの例や楽しいもので、リスクが非常に低いものだとすれば、なぜバイブコーディングを気にかけるべきなのでしょうか？
バイブコーディングを気にかけるべき理由は、指数関数にあります。AIができるタスクの長さは7か月ごとに倍になっています。現在は約1時間です。それで十分です。バイブコーディングは必要ありません。Cursorに作業してもらったり、Claude Codeに1時間かかる機能を書いてもらったりできます。そのコードをすべてレビューして、AIが多くのコードを書いている間も、まだ密接に関与することができます。
しかし、来年はどうなるでしょうか？その次の年はどうでしょうか？AIが一度に丸一日分の作業や丸一週間分の作業を生成できるほど強力になった時、もし私たちがまだロックステップで動く必要があるなら、それについていくことは不可能になるでしょう。
つまり、この指数関数を活用したいなら、責任を持ってこれに身を委ね、このタスクを活用する方法を見つけなければならないということです。私のお気に入りの類推は、コンパイラです。コンパイラの初期の頃、多くの開発者はそれらを本当に信頼していませんでした。コンパイラを使うかもしれませんが、それが出力するアセンブリを読んで、自分がアセンブリを書く方法と同じように見えるかを確認していたでしょう。しかし、それはスケールしません。
ある時点で、単純にシステムを信頼しなければならないほど大きなシステムで作業する必要が出てきます。しかし、問題はどうやって責任を持ってそれを行うかということです。今後数年間のソフトウェア業界全体への私の挑戦は、どうやって本番環境でバイブコーディングを行い、それを安全に行うかということです。
私の答えは、コードが存在することは忘れるが、製品が存在することは忘れない、ということです。
コンパイラとの類推
再びコンパイラの類推を考えてみましょう。私たちは皆、内部にアセンブリがあることを知っていますが、ほとんどの人はアセンブリが実際に何であるかを本当に考える必要がないでしょう。しかし、私たちはまだ、内部のアセンブリを理解することなく、良いソフトウェアを構築することができます。私たちはソフトウェアでも同じレベルに到達すると思います。
私が本当に強調したいことの一つは、これは新しい問題ではないということです。CTOは、自分自身が専門家でない分野の専門家をどうやって管理するのでしょうか？PMは、自分自身がその中に入ったすべてのコードを読むことができない時、エンジニアリング機能をどうやってレビューするのでしょうか？または、CEOは、自分自身が財務会計の専門家でない時、経理の仕事をどうやってチェックするのでしょうか？これらはすべて、何百年も何千年も存在してきた問題であり、私たちはそれらに対する解決策を持っています。
CTOは、内部の実装を理解していなくても、自分のために働く専門家のための受け入れテストを書くことができます。これらの受け入れテストが通り、作業が高品質であることを確認できます。プロダクトマネージャーは、エンジニアリングチームが構築した製品を使って、コードを書いていなくても期待通りに動作することを確認できます。
CEOは、自分が理解している重要な事実とデータのスライスをスポットチェックして、財務モデル全体の流れ方の専門家でなくても、全体的な財務モデルに対する信頼を築くことができます。
これらの例を考えると、自分自身が理解していない実装を管理することは、実際には文明と同じくらい古い問題です。世界中のすべてのマネージャーが実際にこれに既に対処しています。ただ、私たちソフトウェアエンジニアはこれに慣れていません。私たちは、スタックの全深度を理解する純粋な個人貢献者であることに慣れています。しかし、最も生産的になるためには、すべてのマネージャーが最も生産的になるために一部の詳細を手放す必要があるのと同じように、私たちもそれを手放す必要があります。
私たちソフトウェアエンジニアとして、内部で起こっているアセンブリ自体を理解するなどの詳細の一部を手放すように。安全で責任を持ちながらこれを行う方法は、実装を知らなくても検証できる抽象化レイヤーを見つけることです。
技術的負債という課題
今日、これに対して一つの注意点があります。それは技術的負債です。現在、コードを自分で読まずに技術的負債を測定したり検証したりする良い方法はありません。人生の他のほとんどのシステム、経理の例やPMなど、実装を知らずに気にかけていることを検証する方法があります。技術的負債は、実装自体の専門家でないと検証する良い方法が本当にない珍しいもののうちの一つだと思います。
つまり、現在私たちが検証する良い方法を持っていないものが一つあります。しかし、これはまったくできないということを意味するわけではありません。コーディングを活用できる場所について、非常にスマートで的を絞って、どこで注意すべきかを認識する必要があるということです。
私の答えは、コードベースのリーフノードに焦点を当てることです。つまり、何も依存しないコードの部分やシステムの部分です。それらは最終機能のようなものです。最終的なベルやホイッスルです。ここの白い部分のような、その下にあるブランチやトランクではなく。
ここで、オレンジの点がすべてこれらのリーフノードですが、このようなシステムがあるなら、これらのリーフノードに技術的負債があっても、正直なところ大丈夫です。なぜなら、他に何も依存しないからです。それらは変更される可能性は低いです。さらに何かがそれらの上に構築される可能性は低いです。
対して、ここの白い部分、システムのトランクと基礎となるブランチです。これがコアアーキテクチャであり、私たちエンジニアがまだ深く理解する必要があるものです。なぜなら、それが変更されるものだからです。それが他のものが構築される基盤であり、それらを保護し、拡張可能で理解可能で柔軟であることを確認することが非常に重要だからです。
ここで一つ言えることは、モデルは常に良くなっているので、この信頼がさらに下の方まで及ぶ世界になるかもしれません。拡張可能で技術的負債のないコードを書くためにモデルをますます信頼するようになるでしょう。Anthropic内でここ1、2週間でClaude 4モデルを使うことは本当にエキサイティングなことでした。3.7よりもはるかに多くの信頼を置いています。
これは変化していくと思いますし、スタックのますます多くの部分をこの方法で扱えるようになるでしょう。
バイブコーディングで成功する方法
バイブコーディングで成功する方法について話しましょう。私の主なアドバイスは、Claudeがあなたのために何ができるかを問うのではなく、あなたがClaudeのために何ができるかを問うことです。バイブコーディングをしている時、あなたは基本的にClaudeのプロダクトマネージャーとして行動しています。だから、プロダクトマネージャーのように考える必要があります。
あなたのチームの新しい従業員がこのタスクで成功するために、どのようなガイダンスやコンテキストが必要でしょうか？私たちはAIとの非常に短い往復チャットに慣れすぎていると思います。「この機能を作って」「このバグを直して」というような。しかし、人間の場合、もしそれが職場での初日で、「この機能を実装して」と言っただけなら、実際に成功することを期待する方法はありません。
コードベースのツアーを提供する必要があります。実際の要件と仕様と、理解する必要のある制約が何かを伝える必要があります。バイブコーディングをする時、その情報をClaudeに提供して、同じコンテキストをすべて持ち、成功するようにセットアップすることが私たちの責任になると思います。
Claudeと機能に取り組む時、私は15分から20分をかけて単一のプロンプトにガイダンスを収集し、その後Claudeに料理してもらうことがよくあります。その15分から20分は、私が手でプロンプトを書いているだけではありません。これはしばしば別の会話で、Claudeと行き来して話しています。コードベースを探索し、ファイルを探しています。
私たちは一緒に計画を立てています。それは、私が欲しいもの、変更する必要があるファイル、コードベースで従うべきパターンの本質を捉えます。その成果物、すべてのその情報を持ったら、新しいコンテキストでClaudeに渡すか、「この計画を実行しよう」と言います。すべてのその情報を収集する努力をした後、Claudeが何かを非常に良い方法で完了できる成功率が非常に高いのを典型的に見てきました。
ここでもう一つ言いたいのは、正しい質問をできる必要があるということです。私の講演のタイトルにもかかわらず、本番環境でのバイブコーディングはすべての人のためのものではないと思います。完全に非技術的な人がゼロから完全にビジネスを構築しようとすべきではないと思います。正しい質問をできないので、それは危険だと思います。そうする時、Claudeの効果的なプロダクトマネージャーになることができないので、成功しないでしょう。
実際の成功事例
私たちは最近、Claudeによって大きく書かれた22,000行の変更を本番の強化学習コードベースにマージしました。一体どうやって責任を持ってこれを行ったのでしょうか？これはGitHubのPRからの実際の差分のスクリーンショットです。
まず、Claudeのために何ができるかを問いました。これはマージした単一のプロンプトではありませんでした。要件を考え出し、Claudeをガイドし、システムがどうあるべきかを理解することに、まだ数日間の人間の作業が入りました。私たちはこの機能でClaudeのプロダクトマネージャーとしての役割を本当に受け入れました。
変更は主にコードベースのリーフノードに集中していて、近い将来にコードベースのこれらの部分が変更される必要があることを期待していなかったので、多少の技術的負債があっても大丈夫だと分かっていました。拡張可能であることが重要だと思った部分については、それらの部分の重い人間のレビューを行いました。
最後に、安定性のためのストレステストを慎重に設計しました。人間が非常に簡単に検証できる入力と出力を持つようにシステム全体を設計しました。これらの最後の2つの要素が私たちにできるようにしたのは、これらの検証可能なチェックポイントを作成することで、完全な基礎実装を理解したり読んだりすることなく、これが正しいことを確認できることでした。
私たちの最大の懸念は安定性でした。これらのストレステストを作成し、長時間実行することで、コードを読むことなく測定できました。設計したシステムの入力と出力に基づいて正確性を検証できました。基本的に、私たちはすべてのコードを読むことなく、理解可能で検証可能なシステムを設計しました。
最終的に、これらのことを組み合わせることで、コードベースに行う他の変更と同じくらい自信を持ってこの変更に臨むことができましたが、すべてを手で書いて、すべての行をレビューするのにかかる時間と努力のほんの一部で提供できました。
この本当にエキサイティングなことの一つは、1週間分の人間の時間を節約しただけでなく、これができることを知って、エンジニアリングについて、何ができるかについて違って考えるようになったことです。そして今、何かが2週間の代わりに1日の時間がかかる時、はるかに大きな機能とはるかに大きな変更を行うことができることに気づきました。
ソフトウェアの限界コストが低くなり、より多くのソフトウェアを消費し、構築できるようになったようなものです。これの本当にエキサイティングなことは、時間を節約しただけでなく、「2週間かかることをやろう。1日しかかからない」という感じになったことです。それがここでエキサイティングなことです。
責任あるバイブコーディングのまとめ
本番環境で責任を持ってバイブコーディングを行う方法についての最後の考えをお伝えします。ClaudeのPMになってください。Claudeがあなたのために何ができるかではなく、あなたがClaudeのために何ができるかを問ってください。
コアアーキテクチャや基盤システムではなく、リーフノードにバイブコーディングを集中させてください。技術的負債があっても、それが封じ込められ、重要な領域にないようにするためです。
検証可能性について考え、コードを自分で読むことなく、この変更が正しいかどうかをどうやって知ることができるかについて考えてください。
最後に、指数関数を覚えておいてください。今日バイブコーディングをしなくても大丈夫ですが、1年か2年後には、コードのすべての行を読むことや、コードのすべての行を書くことを自分自身に要求していると、大きな大きな不利になるでしょう。非常に大きな作業の塊をあなたのために生成できる最新のモデルの波を活用できなくなるでしょう。
この点で上手くならないと、ボトルネックになってしまいます。全体的に、これが責任ある本番環境でのバイブコーディングです。これは今後数年間、ソフトウェアエンジニアリング業界にとって最大の課題の一つになると思います。
質疑応答
以前は、構文の問題やライブラリ、コードのコンポーネント間の接続を扱うのに多くの時間を費やしていて、そのようにコーディングすることで学んでいました。しかし、今はどうやって学ぶのでしょうか？どうやってより良いコーダーになるのでしょうか？エージェントAIのより良いプロダクトマネージャーになるために、もっと知るにはどうすればいいのでしょうか？
これは本当に興味深い質問だと思いますし、これについて非常に心配すべき理由と非常に楽観的である理由があると思います。あなたが言ったように心配すべき理由は、私たちが苦闘や苦労の中にいないということです。実際にはそれで大丈夫だと思います。大学時代の教授の何人かが「今のコーダーは手でアセンブリを書いたことがないから、昔ほど良くない。何かを本当に速く実行する方法の痛みを本当に感じない」と言っていたのを会ったことがあります。
この積極的な側面は、これらのAIツールを使うことで、物事についてずっと速く学べることを発見したことです。Claudeとコーディングしている時、コードをレビューしていて、「Claudeよ、このライブラリは見たことがない。それについて教えて。それは何？なぜ他のものよりそれを選んだの？」と言うことがよくあります。いつもそこにいるペアプログラマーを持つこと。
変わることは、怠惰な人は学ばないということです。ただ滑り抜けるだけです。しかし、時間をかけて学びたいなら、すべてのこれらの素晴らしいリソースがあり、Claudeがあなたのためにバイブコーディングしたことを理解するのを助けてくれます。
もう一つ言いたいのは、プロジェクトがうまくいくものと、プロダクトマーケットフィットを得る機能と失敗するものとの高いレベルのことを学ぶために、ゴールに対してずっと多くのショットを取ることができるということです。システムエンジニアやアーキテクトは、コードベースで大きな変更を行い、それが良いアーキテクチャの決定だったかどうかを本当に理解するのに、しばしば2年のような時間がかかります。
その時間を6か月に短縮できるなら、自分の時間に投資し、学ぼうとしているエンジニアは、努力を続ける限り、同じカレンダー時間で4倍多くのレッスンから学ぶことができると思います。
事前計画プロセスに戻って、情報を与えすぎることと与えなすぎることのバランスは何でしょうか？完全な製品要求文書を与えているのでしょうか？実際にVIPコーディングに移る前に組み立てる標準化されたテンプレートのようなものはありますか？
それは気にかけていることに大きく依存すると思います。どうやってそれをするかを本当に気にしない場合、実装の詳細について全く話しません。最終的に何が欲しいか、これが私の要求、というだけです。コードベースをよく知っていて、この論理を実装するために使うべきクラスや、似たような機能の例を見てください、というようにもっと深く入る時もあります。最終的に何を気にかけているかによると思います。
私たちのモデルは過度に制約しない時に最善を尽くすと言いたいです。だから、非常に厳格なフォーマットや何かを作ることにあまり努力をかけないでください。ジュニアエンジニアとして、成功するために何を与えるかを考えればいいだけです。
効果とサイバーセキュリティのバランスはどう取るのでしょうか？数か月前に、バイブコーディングされたアプリのトップ10が非常に脆弱で、多くの重要な情報がリリースされた、というか、リリースされることが証明されたという報告がありました。それをやった人はプロのハッカーでもありませんでした。効果的でありながらもリーフノードレベルでも安全を保つ方法と、効果的であることのバランスはどう取るのでしょうか？何かが効果的でもセキュアでないことがあるからです。
それは素晴らしい質問で、すべてはClaudeのPMになり、何が危険で何が安全かを知り、どこで注意すべきかを知るのに十分なコンテキストを理解することの最初のポイントに帰結すると思います。バイブコーディングについて多くの報道を得るものは、全くコーディングする業務のない人々がこれらをやることです。それは良いです。ゲームには素晴らしいです。創造性のように、人々が創造できるようにするのには素晴らしいです。しかし、本番システムについては、Claudeを正しい方向に導くためにどのような質問をすべきかを知るのに十分知っている必要があります。
私たちの内部事例では、これは完全にオフラインのものでした。だから、セキュリティ問題が起こる可能性はないと非常に確信していました。私たちの場合、完全にオフラインで実行されるようなものです。
あなたが言っているのは、業務のない人々についてで、そんな風に言うべきではなかったかもしれませんが、重要なシステムの本番でバイブコーディングする業務のない人々について言います。しかし、数字を見ると、世界の人口の0.5%未満がソフトウェア開発者で、ソフトウェアはアイデアをスケールする素晴らしい方法です。
人々がAPIキーを漏洩させることなどに遭遇することを避けながら、人々がバイブコーディングしてソフトウェアを構築しやすくするために、製品はどう変わる必要があると思いますか？
それは本当に素晴らしい質問で、証明可能に正しいような製品やフレームワークがもっと出現するのを見るのが非常に楽しみです。つまり、重要なオフ部分、支払い部分があなたのために構築されていて、あなたがしなければならないのはUIレイヤーを埋めるだけのようなバックエンドシステムを人々が構築できると確信しています。
バイブコーディングして、基本的にコードを置くための良い穴埋めサンドボックスを提供します。そのようなものが存在する例がたくさんあると思います。最もシンプルな例は、Claude Artifactsのようなもので、ClaudeがClaude AI内でホストされるコードを書くのを助けてくれます。もちろん、それは非常に限定的なので安全です。オフはなく、支払いもありません。フロントエンドのみです。
しかし、ここで誰かがやるべき良いプロダクトアイデアかもしれませんが、フロントエンドで何が起ころうと安全だと分かっているバックエンドを持つ、証明可能に正しいホスティングシステムのようなものを構築することです。バイブコーディングを補完する良いツールを人々が構築することを願っています。
テスト駆動開発について何かコツはありますか？Claudeが実装全体を吐き出してからテストケースを書くのをよく見るからです。時々それらは失敗して、テストケースを最初に書くようにプロンプトしようとしているのですが、実装をまだ見ていないので自分でそれらを検証したくありません。テスト駆動開発を試したことはありますか？反復可能なアプローチはありますか？
テスト駆動開発はバイブコーディングで非常に非常に有用です。テストを自分で見なくても、テストケースが何かを理解できる限り、Claudeがもう少し自己一貫性を持つのに役立ちます。しかし、多くの場合、Claudeが実装に特定すぎるテストを書く穴に落ちるのは簡単です。
これをやろうとする時、私はしばしばClaudeに例を与えます。「3つのエンドツーエンドテストを書いて、ハッピーパス、エラーケース、このもう一つのエラーケースをやって」と。私はそれについて非常に規範的です。テストが一般的でエンドツーエンドであることを望みます。それは私が理解できるものであることを確実にし、Claudeが詳細に入りすぎることなくできるものであることを確実にするのに役立つと思います。
バイブコーディングしている時、コードの唯一の部分、または少なくともコードの最初の部分として読むのはテストです。テストに同意し、テストが通るなら、コードについて非常に良い気分になります。Claudeに非常にミニマリストなエンドツーエンドテストを書くよう奨励できるなら、それが最もうまくいきます。
非常に魅力的な講演をありがとうございました。多くの人がやっていないことをあなたがやって、Karpathyの元の投稿のより特異な行の一つ、「指数関数を受け入れる」を解釈しようとしたことも評価しています。
もう少し具体化して言うなら、どうやって指数関数を受け入れたかを知るでしょうか？そのアドバイスに従うことを正確に意味するものは何でしょうか？そして、それが意図することをもう少し具体化すると、モデルは良くなるということを暗示しているようです。モデルが良くなるという事実が、私たちが想像しているかもしれない考えられる次元すべてで良くなることを意味するわけではない、と言うことに何らかの正当性があると思いますか？
では、指数関数をどう受け入れるのでしょうか？
モデルが良くなり続けると仮定し続けるという引用に近づきましたが、それを超えた一歩です。指数関数のアイデアは、それらが良くなり続けるだけでなく、私たちが想像できるよりも速く良くなるということです。
ここの点の形を見ることができるでしょう。それは着実に良くなっているだけでなく、良くなって、それから野放しになります。これから聞いた他の面白い引用は、DarioとMike Kriegerの講演だったと思いますが、「慈愛の機械はサイエンスフィクションではない。それは製品ロードマップだ」というものです。
非常に遠いもののように聞こえても、指数関数にいる時、物事は非常に非常に速く、期待するよりも速く野放しになります。90年代にコンピュータをやっていた人と話すなら、「よし、素晴らしい。数キロバイトのRAMがある。さらに数キロバイトのRAMがある」というような感じです。
しかし、今いる場所まで早送りすると、テラバイトがあります。それは2倍良くなっただけでなく、物事が何百万倍も良くなったということです。それが20年間の指数関数で起こることです。だから、20年後について考える時、これらのモデルが2倍良かったらどうなるかと考えるべきではありません。
これらのモデルが今日よりも100万倍スマートで速かったらどうなるかを考えるべきです。それは野放しです。90年代にコンピュータで働いていた人は、コンピュータが彼らが働いていたものより100万倍速かったら社会に何が起こるかを考えることができなかったと思います。しかし、それが起こったことです。だから、指数関数で意味するのは、それが暴走することです。
バイブコーディングに関して2つの異なるワークフローがあります。ターミナルにいる時と、VS CodeやCursorにいる時です。どのワークフローを使っていますか？ターミナルでClaude Codeを使っている場合、どのくらいの頻度でコンパクトしますか？バイブコーディングが長くなるにつれて、関数が新しい名前を得たり、物事が軌道から外れたりすることを発見するからです。コンパクトしても、まだ起こります。ガイドするドキュメントを作成しても、まだ軌道に戻す必要があります。
素晴らしい質問です。私は両方をします。しばしばVS CodeでターミナルでClaude Codeを開いています。Claude Codeがほとんどの編集をしていて、私はVS Codeでコードをレビューしています。これは、ここでの意味でのバイブコーディングではありません。または、そこからのテストだけをレビューしているかもしれません。
人間のプログラマーとして、昼食を取りに行って戻ってくるような、休憩を取るような良い停止点にClaudeを到達させた時はいつでも、コンパクトするか新しいセッションを開始するのが好きです。そのような段階にいると感じるなら、コンパクトするのに良い時です。
Claudeにすべての関連ファイルを見つけて計画を立ててもらうことから始めて、それをドキュメントに書いてもらい、それからコンパクトします。それにより、その計画を作成し、すべてのファイルを見つけるのにかかった10万トークンが取り除かれ、数千トークンに煮詰められます。
前の質問に続いて、Claude Codeと一緒に他のツールを使って、gitワークツリーを使って複数のClaude Codeを一緒に実行したり、いくつかのものをマージしたり、スタックPRなどをしたりして、速度を少し上げるようなことを個人的にフォローしたり、アドバイスしたりしますか？
2番目の質問は、あまり馴染みのないコードベースの部分に構造的で良いエンジニアリング方法でアプローチして、本当に速くPRを出荷したくて、本当に良い方法でやりたくて、バイブコーディングしたくない場合、どうやってClaude Codeを使ってこれらの両方のことを助けるかです？
Claude CodeとCursorの両方を確実に使います。典型的には、Claude Codeで物事を始めて、それからCursorを使って物事を修正します。または、非常に具体的な変更がある場合、変更したいファイルのこの正確な行があると知っている場合、Cursorで自分でやって、変更する必要があると知っている正確な行をターゲットにします。
あなたの質問の2番目の部分は、コードベースの新しい部分で立ち上がる方法でしたね。機能を書こうとし始める前に、Claude Codeを使ってコードベースを探索するのを助けてもらいます。「このコードベースでオフが起こる場所を教えて」や「このコードベースで何かが起こる場所はどこか。これに似た機能を教えて」と言って、ファイル名を教えてもらいます。見るべきクラスを教えてもらいます。
それを使って、これができて、バイブコーディングしないことを確認できるような心の絵を構築しようとします。何が起こっているかの良い感覚を得ることができることを確認して、それからClaudeと機能に取り組みます。
どうもありがとうございました。まだここにいて、他の質問にも答えることができます。
コメント