この動画は、AI開発スタートアップの3人の技術創設者が、Claude Codeの実際の活用方法について詳しく解説する内容である。単なるチャットツールとしてではなく、本格的なAIエージェントとしてClaude Codeを最大限活用するための実践的なワークフローと戦略を、豊富な実例とともに紹介している。
Claude Codeの真の価値
もしあんたがClaude Codeを単なるチャットBTみたいにプロンプト打ち込むだけで使ってるんやったら、その価値の90%を逃してるで。Claude Codeは一見軽量なコマンドラインツールに見えるけど、実際は違う。これは今後やってくる高性能AIエージェントの第一波なんや。
そのパワーをどうやって活用するかを理解することが重要で、これがClaude Codeの本当の実力に驚かない理由かもしれへん。僕はパトリック、CTOでAIネイティブなスタートアップの共同創設者をしててな、2月からClaude Codeを使ってる。今週の初めにシアトルの創設者グループで話したんや。友人のアナドとガレンと一緒に、Claude Codeを最大限活用するための基本原則と戦術的なフレームワークやツールについてな。
アナドの解説開始
今回は最も価値ある話題を幅広くカバーするで。CPSを使ってClaude Codeに目を与える方法、ダブルエスケープ法と再開法を使ってClaude Codeのコンテキストを分岐させて複数のインスタンスを立ち上げる方法、僕のお気に入りでめちゃくちゃ役立つ自動コードレビュー、CodexやOthersを含む主要コード生成ツールの現状、ガレンが最後の方でデモするMyデベロッパー・プロンプティング・トリック。これ実は僕の一番の収穫やった。どうやって検証ステップを構築してClaude に良いアウトプットと悪いアウトプットを理解させるかとか、他にもたくさんあるで。
説明欄にはそれぞれのセクションと話したトピックを詳しく書いてるから、もう知ってる話題があったら、興味深くて関連する部分にサクッと飛んでもらったらええ。そこには本当にええ宝石が詰まってると思うで、僕の偏見のない意見やけどな。3人の話のスライドもリンクしてるから参照してくれ。これがClaude Codeの次のレベルを解放する助けになることを願ってる。
Claude CodeとCursorの違い
よく聞かれる質問がこれや。Claude Codeとcursorの違いは何なんや？これに集約されると思う。Claude Codeは複数ステップの処理が得意なんや。大きなタスクがあってそれを完了させたい時、サブタスクに分解して一つずつ実行していける。
僕は新しいプロジェクトを始める時にいつも使ってる。2、3日おきに新しいプロジェクトを投稿してるけど、それは本当に良いスペック、本当に良い計画書を作れるからや。後で詳しく説明するけど、それをClaude Codeに渡して自由に実行させてる。これは多分やったらあかんことやけど、ランダムなサイドプロジェクトやからリスクないしな。これがうまくいくのは、その反射的なループがあるからや。
複雑さがたくさんあって、異なるファイルからいろんなものを引っ張ってこなあかん場合でも、Claude Codeはそれが得意や。長時間動くプロセスがある場合も、僕はClaude Codeを選ぶ傾向にある。
Cursorは特定の問題を解決したり、特定のファイルやコード行を扱うには今でも本当に良いで。それらを簡単に選択できるからな。
Cloud MDファイルの重要性
Cloud MDファイルについて説明するで。このファイルはメインのコンテキストファイルや。スラッシュイニットを実行する時、これについては後で詳しく説明するけど、コードベースの概要を生成する。すべてのファイルを調べて、すべてがどう設定されてるかを把握して、起動プロセスやすべての場所について詳しいメモを作る。
ドキュメントからの引用が気に入ってるんやけど、「あなたのCloud MDファイルはClaudeのプロンプトの一部になる」って書いてる。文字通りそうなるわけや。だから頻繁に使うプロンプトのように洗練されるべきなんや。要するに、Claude Code専用に作られたreadmeみたいに考えてくれ。
init機能は素晴らしいけど、僕は独自のコマンドセットを実行してる。すべてのファイルを調べて、まずファイル構造とフォルダ構造を抽出させる。それからそれぞれのフォルダに対して、新しいCloud MDファイルを作る。各サブフォルダにCloud MDファイルがあって、実質的にすべての単一サブフォルダに対して詳細なメモ、詳細なreadmeを作成できる。すべての関数とファイルを追跡できるレベルまでな。
それでClaudeが操作する必要がある時、もうめちゃくちゃにgrepしなくてもええ。更新されてる限り、それらのClaude MDファイルを見せれば、認知負荷を大幅に削減できる。
これはcursorのrulesファイルみたいなもんなんか？プロンプトとはどう違うんや？ちょっと混合してる感じやな。cursorのrulesは実質的にcursorに入るプロンプトやろ？でもコードベース全体のreadmeでもある。だから両方の役割を果たせる。
僕の実際のcloudファイルの良い例を見せるで。メインのやつがあって、バックエンドとフロントエンドがある。だからこう設定してるって言うわけや。フロントエンドはこんな設定で、バックエンドはこんな設定って。フロントエンド構造をカバーしてて、実際にはフロントエンドフォルダ自体にもっと詳細なリストがある。
バックエンド構造もあって、バックエンドフォルダにあるけど、もっと詳しくなってる。でもそれらを僕のプロジェクトフォルダや会社フォルダに抽出できる。僕にとっても見やすいし、コードベース横断やレポジトリ横断で何かを実行しなあかん時も、管理がめちゃくちゃ楽になる。
他の有用なMDファイル
あまり語られてないけど、めちゃくちゃ有用な他のMDファイルがある。変更ログとかな。良い変更ログがあれば、Claudeが時間の経過とともに、どんな変化が加えられてなぜそうなったかを理解しやすくなる。変更を加えるたびに、Cloud MDファイルとは別に変更ログを更新してもらう。
これでなぜ変更したのか、なぜこのやり方に戻っちゃダメなのかっていう良い理解を与えられる。新しいプロジェクトや新しいタスクを始めるたびに、Plan MDファイルを使ってる。これは実際に単一の文書でやりたいことのリストみたいなもんや。
GitHub統合
今から触れたい重要なことがある。Claude CodeをGitHubレポジトリに接続できるんや。これは基本的にDevinを置き換えるか、実質的にDevinそのものやけど、あんたのフィランソロピックキーを使って、設定がめちゃくちゃ簡単や。このコマンドを実行するだけで、すべて自動化してくれる。本当に手間がない。
それからissueを作成できる。僕がやりたいプロジェクトがあって、このライブラリ用のコンポーネントを作成してくれって言って、開発者にタグ付けするみたいにClaudeにタグ付けする。そしたらissueを作成して、このto-doリスト、このチェックリストを作成して実行する。後で実際にこれはあんまり良くなかったなって思った時、実際の開発者と同じようにPRで再度タグ付けできて、また実行してくれる。
このプロセスを使うと、自分のコンピュータで1つのエージェントや複数のエージェントを同時に実行するよりもはるかに多くのことができる。めちゃくちゃ便利や。
Claude Codeには、レビューPRコメントみたいな組み込みコマンドもあって、コンソールからレビュープロセスを効果的に自動化できる。コメントを取得して、ローカル環境で操作できるようにしてくれる。これらのコマンドは組み込まれてる。本当に探索することをお勧めする。
僕は30個の異なるコマンドを同時に実行できる。Claude Codeを使って、構築したいすべての機能のリストがここにあるって言って、これらすべてに対してPRを生成して、最後にClaudeにタグ付けしてジョブを開始するようにしてくれって頼んだ。それができたんや。これは僕の電話じゃない。家に帰る頃には全部完了してた。本当に驚いたで。
GitHubとの統合で？それともCLIで？CLIからや。GitHubに統合できる。要するにアプリが動いてるってことやけど、Claude Codeボットが動いてる。
コマンドの活用
コマンドについて説明するで。コマンドはただのプロンプトや。ファイルに保存して、プロジェクト間で共有したり、チーム間で共有できるプロンプトや。非常に包括的なステップバイステップのものを開発して、Cloudから組み込まれてるPRやinstall GitHubみたいに実行できる。自分で書くこともできる。
これが素晴らしいのは、チームに知ってもらいたい特定のことがあるかもしれへんからや。チームの誰かがClaudeエキスパートやAIプロンプトエキスパートで、素晴らしいものを書いたら、それをチーム全体で共有できる。使うのがめちゃくちゃ簡単や。包括的なワークフローを作成できるコマンドの使用を本当に検討すべきや。Claudeが簡単に従えるプロンプトを使ってな。
これは例えば、僕が使えるコードベース分析プロンプトで、Cloud MDファイルで本当に包括的な分析をセットアップできる。めちゃくちゃ長いけど、うまくいく。GitHub actionも作ったで。GitHubのインターフェースから直接実行できる。これは僕が集めたコマンドの一部や。
とにかく、ウェブサイトとQRコードがここにある。興味があったらな。これを作ったのは僕やから、本当に簡単に追加できるようにした。免責事項として、僕が作ったけど、これらのアイデアを共有する本当に良い方法やと信じてる。
サブエージェントも起動できる。Claude Codeを始めたばかりやったら、これについては考えんでもええけど、基本的に2つのことを同時に実行できる。結構クールや。
パトリックの解説開始
皆さん、僕の名前はパトリックです。2月24日にClaude Codeが出てからずっと使ってます。永遠に感じるけど、新機能の絶え間ない進化を見るのは素晴らしかったで。
Claude Codeで最もクールなことの一つは、Anthropicチームが明らかにMLとAI側で密接に連携してることや。実際の機械学習研究者がポスト訓練やファインチューニングなどをやってて、実際のプロダクトチームと一緒に。だからClaude Codeとの密接な結合が見られて、これが他の体験とは一線を画してると思う。
KleinファウンダーのLatent Spaceポッドキャストを聞いてたんやけど、ちなみにそのポッドキャストエピソードと全体的にポッドキャストも素晴らしい推薦や。彼らがOpus 4とSonnet 4がbashコマンドを使ってgrep aroundしたがってることについて話してた。アナドが話してたようにな。
だからOpus 4とSonnet 4が試みることの好ましいビットの全領域があって、アプリケーションと機械学習チームが密接に話し合ってることを考えると、Claude Codeと本当によく合うんや。これがClaude Codeが使うのに素晴らしい理由の一つや。
Claude Codeの基本
Claude Codeの基本について少し話すで。これが他のcursorや他のプラットフォームよりも刺激的で興味深くて、最近話題になってる理由は何や？僕の観点から、最大の部分はコード生成以上のことをやってるってことや。
実際に本格的な最初のプロダクションエージェンティックツールの一つと働いてるんや。約1時間程度の複数ステップ処理ができる。コード生成の観点だけでなく、アプリケーションの観点でもっと広く考えることができる。少しで僕のお気に入りの非コーディングワークフローをいくつか紹介するで。
でもこれらのエージェントがより長く動作して、実際に実行しようとしてることに対してより正確になるのを感じるキャラクター、性質、これらすべての要因は、他のドメインで、自分の製品で、あるいはGeminiを使ってYouTube動画を要約するみたいなツールを使って、エージェンティックワークフローを構築する際に学び、内在化すべき本当に役立つレッスンなんや。
これがClaude Codeの素晴らしい部分の一つや。Claudeは僕が言ったように、Claude Codeが大いに活用するツール用にファインチューニングされてる。bashタイプコマンドがあるから、コードベースをgrepしたり、GHやGitHub CLIツールを使えたりする。
でもネイティブツーリングもある。ウェブ検索、ファイル検索。僕のお気に入りの部分の一つはto-doリストや。昔はいつもPRDを作ってたけど、これは今でも役立つワークフローやけど、ほとんどのことに対してはClaude Codeにshift+tabして計画モードに入らせる。
実行しようとしてることのスペックを考え抜いて反復させて、小さなto-doリストを作らせてトラックに留まらせる。特に異なるステップ間で引き継ぎをする時や、サブエージェントを使ってコードベースの異なる部分を要約したり、研究を考え抜いたりする時にな。
それを引き戻してto-doリストで地に足をつけて保つことができる。6つの箇条書きのto-doリストであってもめちゃくちゃ役立つ。出力してることを反映する能力みたいな他のツールもある。これは絶対的なゲームチェンジャーや。これがよく起こるのを見るで。何かに取り組んで、ちょっと待て、これは実際にこれに対する最良のアプローチじゃないとか、この仮定は間違ってたって言うんや。
タスクで実行させて15分後くらいに戻ってきて出力を確認しようとする時、その能力は想像できると思うけど、めちゃくちゃ役立つ。面倒を見なあかんタッチポイントが一つ減るし、通常は複数のタッチポイントが減る。それに加えて、その反射部分で出力がはるかに良くなる。
だからその組み合わせ、特にOpus 4、でもSonnet 4もClaude Codeとの組み合わせは本当に信じられないほど生産的なワークフローなんや。
注意点として、Claude Codeを使ってる時、スラッシュモデルを実行すると、SonnetかOpusかを選択できる。知らない場合のためにな。デフォルトはsonnetや。
Opusは4倍高いけど、maxプランを使ってるなら、月100ドルか200ドルのプランやけど、これを強く推薦する。推論の量がバカげてる。完全にClaudeを使ってる月を推定すると、APIコストの観点で3000から5000ドルくらいやと思うけど、月200ドルのスロットや。これがいつまで続くのか、cursorや他のように薄めてくるのかわからんから、言及したかった。
エージェントの種類
異なるタイプのエージェントの概要を簡単に説明したい。もちろんチャットベースエージェントがある。ChatGPT、Geminiなどで皆慣れ親しんでる。CLIとIDEベースエージェントもある。もちろんClaude Code、cursor、windsurf、AWSやAmazonのKlineの真新しいchiroやkiro、などや。
それからバックグラウンドエージェントがあって、ここ数ヶ月で展開され始めてる。CodexもCLIツールを持ってるけど、もちろんOpenAIのProPlanを使えば、どこでも1つから4つの異なるO3インスタンスを実行するエージェンティックプロセスを開始できる。
僕はGitHub統合もここに含めるで。アナドが話したから詳しく説明せんけど、信じられない。僕らの友人サムがこれを説明してくれたんやけど、絶対に驚くべきワークフローを持ってる。
基本的にClaude CodeとGitHubで構築できる統合を取って、YAMLファイルを修正したんや。基本的にやってることは、GitHub actionの設定ファイルであるYAMLファイルを作成することで、追加の詳細を加えることができる。実行してるプロンプトを修正できるし、デフォルトのsonnetの代わりにopusを使えるように使用するモデルをuncommentすることを強く推薦する。
これで追加のパラメータを加えることができる。基本的に設定ファイルにCPSを忍び込ませて、異なるbashツーリングを使う許可を与えて、markdownファイルのような他の設定ファイルへのアクセスを与える。
このGitHub統合を通じて、アナドが言ってたみたいにDevinタイプの体験を本質的に作成できるけど、もっとコントロールがあって、より良いモデルが使える。これで本当にクールなのは、アナドが言ってたように、コードレビューの素晴らしい方法に関して内部で持ってるプロセスを埋め込むことができることや。PRを提出するユーザーに基づいて物事を変更することもできるから、本当にワークフローのこれらの部分を埋め込むことができる。
これらのコマンドやこれらのランナー内にな。僕がClaude CodeとCPSについて愛してることの一つは、内部で持ってる異なるワークフローをカプセル化できることや。一人の開発者としても役立つけど、チーム全体ではめちゃくちゃ役立つ。その知識とめちゃくちゃ生産的になる能力を体現して、経験の浅い人たちに引き継げる。基礎となる詳細をすべて理解する必要がない。
バックグラウンドエージェントがある。GitHub統合も僕はその一部と考えてる。それから少し高度やけど、エージェントスウォームがある。これは本当にクール。基本的にたくさんのコンテナを立ち上げる。
Codexは基本的にこれで、4つあったら1つから4つまで行ける。同時に実行してるエージェントがすべてあって、解決策を思い付いて、手動で比較するか、LLMを審査員として比較できる。
友人のサムが僕に説明してくれたワークフローは、3つのopusインスタンスを開始して、良いコードがどんなものかの受け入れ基準がある。異なるスタイルガイド、API文書やAPIスペック標準の例があって、それらの出力と比較する。LLMがその3つの出力のうちどのバージョンが一番好きかを選んで、自動的にマージして、CI/CDパイプラインを構築して、その時点でレビューできる。スウォームアイデアでかなり洗練されたことができる。これは基本的なバージョンや。
それからAIエンジニアワールドフェアで、僕らの何人かが1ヶ月前にSFで参加したんやけど、何百ものコンテナが立ち上がる例を見た。もちろんそれはOpus 4で僕を破産させるやろうけど、考えるだけで刺激的や。
それからもちろん非エンジニアリングエージェントもある。ManusやDeep Researchや僕らが慣れ親しんでる他のものな。
Claude Codeの多様な活用
僕のお気に入りはClaude CodeとCLI。ヘッドレスモードでも、TypeScriptとPythonのSDKがある。それからもちろんCLIでも、ターミナルでパイプできる小さなインテリジェンスがある。ビルドパイプラインに入れることもできるし、レビューしたり、あなたのいるところや、アプリケーション内で、すべての種類の異なるものを構築させることもできる。
Claude Codeをコード生成ツールとしてだけでなく、さまざまなコンテキストでデプロイできるエージェントとして考えることは本当に強力やと思う。僕はGemini CLIも好きで、Claude Codeに非常に似てるけど、魔法はないけど、他のタスクには、僕が見つけた最もクールなものの一つは、誰かがGeminiを使って基本的にYouTube動画を見てたことや。1秒に1フレーム見ることができて、GoogleのYouTubeツールとのファーストパーティ統合を通じてトランスクリプトも持ってる。
僕はこれをいつもやってる。1時間の講演を見る前でも、summarize.google.comに行って、基本的に何について話してるかの感覚を得る。この講演では、Claude講演からの詳細を覚えてたけど、全1時間を見て見つけたくなかった。大体このポイントを覚えてるけど、これのタイムコードはどこやって聞いただけで、引っ張ってくれた。めちゃくちゃ役立つし、これはYouTubeでの一つのワークフローやけど、めちゃくちゃ役立つ。
もう一つクールなのは、Gemini CLIでチュートリアルを取って、それをローカルコンピュータで実行して構築しようとさせることができることや。コマンドラインや露出してるさまざまなツールから実行可能なものやったらな。非常に多様や。
エージェントに必要なもの
エージェントが素晴らしいパフォーマンスを得るのに必要なもの。コンテキスト。コンテキストがすべてや。コンテキストは本当にすべてや。皆さんも知ってると思うけど、プロンプトエンジニアリングはコンテキストエンジニアリングにリブランドされた。モデルに合わせるもの、与えるものがな。
僕が引用したアナロジーは、Anthropicのコンテンツプロダクトオフィサー、Instagramの創設者でもある人からやと思う。彼の話し方は、あなたがClaude Codeだと想像してみろ。目を覚ますと、この箱の中にいて、誰かが渡したもの、つまりプロンプトしか持ってない。限られたコンテキスト、限られたツーリングしかない状態で生産的なことをするのはめちゃくちゃ難しい。
だからコードベースのコンテキスト、アーキテクチャスタイル、僕らの好みのライブラリが何か、異なるUIモックやスタイルガイドを与える。良いアウトプットと悪いアウトプットの例、何をする必要があるかとともに、アウトプットを評価する方法や方法。再び良いものと悪いものの例、リンターはめちゃくちゃ役立つ。僕は何かするたびにelintを実行させてる。めちゃくちゃ時間節約になるからな。
そのエージェントループをできるだけ長く続けて、リアルタイムでできるだけ多くのフィードバックを与えたい。コミットやブランチングに関する標準、受け入れ基準、自動テスト、それからツールも。異なるCPSが最も簡単な方法やけど、組み込みのウェブ検索やbash、GitHub CLIなど、これらのモデルがパフォーマンスを向上させ、はるかに良い結果を出すために与えることができる他のツールもたくさんある。
エンジニアリング以外にもこれらのエージェントが得意なことがたくさんある。Second Brainは基本的に個人的な知識管理やメモ取りに関する方法論で、異なるコンピュータ管理タスクと一緒に本当に役立つ。命名、スクリーンショット、そこにあるコンテンツのスペースオフ、ファイルの自動整理。もちろんパイプオペレーター。3Dモデルを作成するBlender用のMCPがあって、本当に楽しい。僕自身は使ったことないけど、素晴らしいデモを見たことがある。時間が迫ってるから、残りのスライドを本当に素早く進めるで。
役立つ異なるタイプのCPSがある。これらはMCPの機能タイプの主要カテゴリや。これらはCPSを見つけることができる最高のレジストリの一部や。
Reactで起こる、ユーザーにとってひどい動作があって、たくさんのコードを一緒に投げ込むと最終的に起こってしまう。それを修正するのは難しいし、何かMCPがそれを読み込んで、LMで読み取れる形式で進捗を出力する方法があると思ってるんやけど、まだそれが何かわからん。これに対する良い解決策がない。
一つの考えやけど、異なるUIの状態で一時停止させるためにブレークポイントを入力させて、スクリーンショットを撮るのは面白いアプローチかもしれん。でも素晴らしい質問やな。
時間切れや。残念やけど、このスライドを共有するで。ここには僕が本当に情熱を持ってることがたくさんあるけど、時間を確保したい。
ガレンの解説開始
大きな絵として、まだカバーしてないことがあるなんて信じられん。これはClaude Codeをコマンドラインで使うたびにやりたいことや。
どれくらいの人が実際にClaude Codeを使ったことがある？みんな使ったことあるんか。オーケー。だからこれを知ってるやろ。うまくいけば少し面白いことを教えられるで。でも探索、計画、実行や。
実行に直接飛び込んだら、僕も時々やるけど、これはめちゃくちゃ簡単やろうって思って、Claudeは馬鹿で失敗する。実際にSonnet 4にthinking hardを使った方がOpusよりも多くのタスクで良くて速いことがわかった。でもタスクの複雑さは僕のと違うかもしれん。
僕の目標はここでClaudeにトークンを使わせてコンテキストを構築することや。Markdownファイルを読むことはできる。僕のは全然最新じゃない。読んでも、誰かのコードベースがどう動くかについて300行読んで、今これを構築してくれって言われるようなもんや。何かを間違える。
だからこれに取り組む準備をしろ。Claudeは取り組むもののアイデアから始める。君らみんなと同じや。オーケー、読み始めて、これをどう構築するかわかったって思って、読むのをやめて、構築する準備ができたって思う。
コードを読めって言ったら、もう少し読む。でも僕らのフロントエンドがどう動くかを議論する準備をしろって言ったら、Claudeは7分間で50,000トークンを使って、オーケーって言う。それからうまく動く方法の良い概要をくれる。それをやった時、Claudeはもっと賢い。
概要が間違ってたら、escapeを押す。エスケープかスラッシュクリアで、最初からやり直し。修正しようとするな。修正を試すこともできる。僕は時々やる。時々仕事で。でも基本的にコンテキストウィンドウでトークンをかみ砕いてる。悪い請負業者に押し戻そうとしてるようなもんで、悪い請負業者はクビにして新しいのを雇え。
間違ってたら、2回目に正しくするために他に何を入れる？再実行して、正しいかどうか見るだけや。再実行するだけ。たくさんのサブエージェントを再利用する。正しくなる。10回のうち9回は正しい。
これは素晴らしいギャンブルゲームで、負けた時に、なんで負けたんやって思わん。いや、ほぼいつも勝つって思う。僕はmarkdownファイルを作るだけ。Claudeに書いてもらう。僕らのアーキテクチャがどう動くかについて話して、取り組んでることのチェックリストを作る。これは古いやつや。明らかにコードは書かん。
これは多分PRを持ってる場合は次のを検討する。でも実際にはこれの方がずっと良いと思う。アプリの文書識別部分に取り組む予定で、関連ファイルを掘り下げて読んで、どう動くかの詳細について議論する準備をしろ。
実際にコンテキストを持ってることを確認するために時々質問で追いかける。よくやるのは、良い仕事をしてると思ったら、ダブルエスケープでコンテキストから削除することや。コンテキストウィンドウでたくさんの余裕が欲しいから。
ダブルエスケープ。どれくらいの人がクラブでダブルエスケープを使う？いつもこれを使うべきや。7分間コンテキストを構築したばかり。この請負業者はこれが本当に得意や。ダブルエスケープして会話をフォークできる。たくさんの作業をして、ダブルエスケープして、すべてのコンテキストを持ってる同じポイントに戻る。お金と時間を節約できる。主にmaxプランからすぐに追い出されないようにな。主に座って待たなくて良くて、悪いギャンブルを得ないかもしれん。
賢いクラウドを得たら、それを保って何度も何度も再利用すべきや。
これがどんな感じかや。ダブルエスケープして、以前の会話に戻ることができる。これはクレイジーな分岐多元宇宙や。新しいタブを開くことができる。たくさんのコンテキストを構築したばかりで、新しいタブを開いて、resumeを押すと、ターミナルの新しいタブでそのコンテキストすべてを得る。
だから5つのターミナルすべてで、その正確な素晴らしいフロントエンドやバックエンドやAPIコンテキストすべてで実行できる。いくつか質問して、どこでも始められる。どこでも。これをやって、フロントエンドで3つの異なることを書き始めるのはやめろ。
git work treesと異なるディレクトリ、どうやってるんや？僕は同時に2つ以上のタスクに取り組むのを好まん。脳がフライになるから。15個のタブを開くことになる。タブに戻って、このタブは何やって思って、ああ神様、今この決定を下すことができない。なんでこの道を始めたんやって思う。2つのwork treeがあるだけ。git libraryの平行ケースみたいなもんや。
それらをmasterにマージするだけ。開いたままにしておく。ただそこにある。気にしない。gitを適切に使ってない。
だから計画、計画モードは使わん。3、4回、5回試した時、僕が計画を立てるより良い計画を立てなかった。thinking hardが好きや。これがClaude が計画を立てるのに本当に一生懸命考える必要があるところや。
これは僕の一般的な指示や。本当に気に入ってる。関数名を書いて、何をするかを1～3文で。テスト名を5～10語で、カバーする動作について。でも本当に短い概要がな。Claudeのデフォルトの計画はよく、書く予定のコードの束みたいな感じで、今はそれより高いレベルで考えてほしい。概念的に何をやってるかを教えてほしい。そんなコードをやり始めると、細かいところに入り始めて、アーキテクチャ的に考えてない。
これは異なる例や。実際に新しいPDFタイプを追加するための全システムを構築した。PDFを取ってGeminiに投げるような全システムがあるけど、異なるタイプがあって、実行したい異なる検証がある。いくつかのガイドを読ませるだけ。
それからこれを実行させるだけで、これにはコンテキストがない。これをGitHubに入れることができて、Claudeに行って、GH issue 140をやって、終わったら閉じてくれって言う。それからauto acceptを押して、さよなら。
リスクベース計画。小さければ、考えすぎるな。コードを評価するだけ。中から大なら、テスト可能でデプロイ可能なPRに分解しなあかん。これをコンテキストウィンドウの観点で考えてる。僕にとってPRサイズくらいや。PRサイズの作業のかたまりくらい。
それから高リスクなら、計画を3回撃つ、2、3回撃つべきやと思う。本当にそれに取り組むべきや。Claudeと一緒に、僕は再び計画を立てない。その計画を見て、これは嫌なにおいがする。これはひどい。エンジニアが僕のところに来たら、あんたはエンジニアや。この計画を持って僕のところに来て、これは本当に複雑やって言う。失敗する。コードベースを台無しにする。
計画を立てたら、新しいタブを開いて、同じ素晴らしいコンテキストを引き上げるけど、計画には飛び込まない。計画を立てたら、自分自身を批判しない。でも素晴らしいコンテキストに戻って、僕の開発者がこれをやるためにこの計画を思い付いたって言ったら、Claudeは、よし、この計画について教えてやるって言う。僕はあんたと一緒で、あんたの開発者チームにはいない。
僕がこの計画を思い付いたって言ったら、素晴らしい仕事やって言う。素晴らしい計画や。少し違ってやるかもしれんことがいくつかある。
でもこの場合は、あんたの開発者は、知らん。僕はそのやり方でやらなかったやろうって言う。具体的になるようにしろ。この計画を立てたって言うだけなら、良い仕事をしない。だから自分に聞く質問を聞け。
計画についてフィードバックを得る。2つのクラウドに計画を立てさせることができる。3つ目のクラウドにそれらの間で決めさせることができる。markdownに入れてクラウドに作業させる傾向があって、それからPRサイズのかたまりに分解させて、実行する。
そのPRサイズのかたまりでは、データベースについて、すまん、アプリについてのその50,000トークンをコンテキストウィンドウに持ってるのがめちゃくちゃ価値があるから、すでに構築したその同じコンテキストを使った方が良い。Claw mdの200行だけで空のクローを立ち上げるよりもはるかに良いコードを書く。
だからその50,000トークンのコンテキストウィンドウを引き上げて、PR1に取り組めって言う。これは僕の例のプロンプトや。一生懸命考えて、これを完了するエレガントなコードを評価しろ。これは本当に大きなやつや。
後方互換性が大好きで、僕は好きじゃない。僕は嫌で、優雅なフォールバックがあるって言って、僕は嫌、それはただのジャンクや。壊れる。それから優雅にフォールバックする。それを言う時、僕にとってはアプリが静かに失敗して、削除すべき古いコードに頼り始めるから気づかないってことや。
これは僕がClaudeにイライラするところがわかる。だからしろうとする。これは少しやりすぎかもしれん、テストとか時々やけど、本当に簡単なもののために、lintingとcompilingと対応するテストを書くのは良いと思う。実際にはTDDをやれって言うだけ。
テストを書いて、失敗するテストを書いて、テストを通すコードを書いて、素晴らしい仕事をする。TDDはひどい。コードをやってた時、1週間くらい試してみて、TDDがクソ嫌いやって思った。これはテストを書くより悪い。
だからthinking hardやthink for thisが好きや。Claudeに自分の作業をチェックするスクリプトをたくさん書かせる。
PDFでGeminiを呼び出すスクリプトを書かせたり、そのスクリプトを書かなあかんかったり、今は新しいmarkdownファイルを作成した時に、PDFを検証するmarkdownファイルを作成した時に、実際に動作することを確認するテストをしろって言う。このファイルで検証しろ。PDFファイルを見る必要があったら、クラウドはそれがひどい。できない。GeminiやUn Instructに聞け。markdownファイルをくれる。行って、それを見て、何が起こってるかを理解して、何をすべきかを理解できる。
見るか見ないかの大きな質問や。Claudeが僕の場合、10回から20回に1回、コードをコピーして馬鹿なことをし始めるから。コミットを見ない。行くときはかなり見るか、全然見ないかや。コミットした。動く。良い。
200行のコピーされたコードが通るのを見た。アプリの5つの異なる場所にある奇妙な設定があって、いつも、この設定を1つの場所に置けないのかって言って、計画があるって言う。あんたは馬鹿や、これは見た目より難しいと思う。
Return Trueは3.7の問題やった。もうそれは得られない。でも通常は、goって押すだけで、感覚がつかめる。これはClaudeがやるのに十分簡単なことかどうかの感覚が今ある。Go shift tab、自動完了にする。
これがどうやって生まれたか聞いたことがあるかどうかわからんけど、なぜ今素晴らしいコーディングエージェントがあるのか。RLのせいで、モデルが、技術ツリーを十分上に移動した時、モデルが良いコンパイル可能なコードを書けるようになったら、実際にコーディング問題を与えて、基本的に80%の時間でソリューションを作成できるかどうかを理解し始めることができる。
thinkingをやった方法は、たくさんのものを書いてくれて、最後に正しい答えを得たら、クッキーをもらえて、その回路に報酬を与える。得られなかったら、クッキーをもらえない。GPT-4とClaude 3.5レベルのモデルに達して、実際にthinkingをオンにし始めることができたけど、モデルが最後まで行くのに十分良かったから。
でも問題は、ソフトウェアエンジニアリング問題を作成してて、検証可能やってことや。このコードを書け。コンパイルされるか？最後に正しい質問に答えるか？テストし返すのがめちゃくちゃ簡単。でもそれは良い編集を作るか？いや、それは本当に良い新しいコードを書く、新しいメソッドを作る。Claudeはそれを好む。皆気づいてると思うけど、多分、編集してるなら、cursorスタイルなら、関係ない。
でも僕の場合は、これを書けって言う。コードを編集しろ、どこを編集できるかを理解しろ。本当にそれをプロンプトしなあかん。Claudeはまだ、オーケー、新しいコードを書く。これは楽しい。新しいメソッドをやろう、みんなって調整されてるから。
ここで切れてるけど、claude 3.7はタスクを完了することにRLされてて、それを元に戻した。そこからReturn Trueが来た。でもまだClaudeがタスクを終わらせようとして、クッキーを得ようとする問題がある。エレガントにコードを統合したり編集したりするんじゃなくて、新しいコードを書くことでな。
だから開発者のことに戻る。プランナーに頼る。プランナータブを開いてて、僕の開発者がステップ2を終わらせたばかりやって言う。低レベルのフィードバックと高レベルのフィードバックをくれ。それを言わないと、素晴らしい仕事をしたって言う。
だからフィードバックを得て、開発者に戻って、このフィードバックをもらったけど、どう思う？って言う。良いフィードバックやな。やる。
これがClaude、Claudeのコード上でスラッシュレビューを押したことがあるかどうかわからんけど、このコードは素晴らしいレビューって言う問題や。ClaudeはClaudeのコードが好きや。
時々これを使うけど、準備。コンテキストウィンドウを使い切ったり、プルリクエストを終わらせてる時に、Claudeに、次のステップに取り組まない、次の開発者にアドバイスをくれ、markdownファイルに入れろって言う。
Claudeは通常、ここで素晴らしいスタートを切ってるけど、役立つことがある。
コンテキストウィンドウ管理。これを得る？僕はもうcompactしない。Compactは時間の無駄や。1ページ半を生成して、4つのファイルを読めってClaudeに言って、めちゃくちゃ偏ったClaudeを得ることになる。
だから巻き戻そうとする。5%に達したら、何をやったかを文書化して、40%に戻って巻き戻してる。これまでにやったことがここにある。続けろ。
巻き戻すってどういう意味？消すんじゃなくて？compactが嫌いで、clearで始めるのも嫌い。でもコンテキストがない。resumeを使ってそのコンテキストを取り戻すことができるし、ダブルエスケープも使える。なぜ使わないんや、もっと高いから、すでにその、その新しいトークンだけに課金されるやろ？新しいトークンだけに課金される。彼らにとってはもっと高いけど、僕らにとっては新しいトークンだけやから、素晴らしい。
実行に直接飛び込んだ。他のコツとヒント。僕が思うのは、work treeの問題は、これをここでやって、これをここでやって、マージするって言うことや。マージ競合がある。Claudeに、gitを扱ってくれって言うだけ。オーケーって言って、毎回正しくやる。信頼すべきかって思う。毎回うまくいく。
簡単なタスクには儀式をスキップして、やるだけ。Claudeは企業対応が大好きや。企業のために企業によって作られてるから、それと戦わなあかん。
これは僕の、計画がかさばりすぎた場合の好きなやつの一つや。これが大好きで、完全に正しくて、半分に切って、僕にとってずっと良い計画にしてくれる。
探索、計画、実行、再開、僕の開発者。それからClaudeが最後に僕のためにこのジョークを作った。僕は加えてないけど、気に入ってる。良いやつや。よし、それが僕の話や。
僕らの話が役立つことを願ってるし、もしそうやったら、Claude Codeのようなコード生成ツール内で、ソフトウェアエンジニアや創設者として特にAIネイティブになる方法についてのこれら2つの動画を楽しめると思う。それでは、このようなコンテンツのために購読することを忘れずに。ありがとう。
コメント