その通り。拡張機能のウェブページから：自動インストール：VSCodeのターミナルからClaude Codeを起動すると、自動的に拡張機能を検出してインストールします。

VSCode内でClaude Codeを起動すると自動でインストールされる これって私だけ？それとも本当に侵入的に感じる？

たくさんの人が一緒に使ってるよね（IDEにはCursorを使って、IDE内のターミナルではClaude Codeを使う感じ）。パフォーマンスに関しては、エージェントによって違いがあるよ。彼らのエージェントが使う基本モデルは同じだけど、例えばコードベースの見方や、タスクを下位モデルに振り分ける決定、ツールへの接続方法はそれぞれ異なる。

Cursorは別のIDEに切り替えさせるけど（VSCodeを使ってない限り）、Claude Code（またはAider）は現在のIDEと並行して動くターミナルで、プロジェクトファイルを直接編集できるんだ。私の場合、「IDE」はvim+tmux+bashだからCLIアシスタントが好きなんだけど、VSCode以外のグラフィカルなIDEを使ってる人にも当てはまるよ。

違いはすごく大きいよ、質や使い方の面で全然違う。Claude Codeは完全にエージェント的で、タスクを与えると全てを実行して、驚くほど良い動作するコードを生み出す。テストしたり、コミットしたり、コマンドを実行したり、リモートシステムにログインしたり、デバッグもできる。Cursorはトークン使用量を最適化するけど、Claude Codeはそうじゃないから、初回からより高品質なコードを生成できる（その代わりコストはかなり高いけど）。Cursorのエージェントモードはまだ追いついていないけど、Cursorは基本的にファイルを編集するためのツールで、Claude Codeはまるでジュニア開発者みたい。

何をやってるの？違いを感じないなんて。私にとってClaudeは全ての面で優れてる。全然比べ物にならないよ。主にScala、Python、JS、Dartを使ってるけど、もしかしたら他の言語ではカーソルの方がいいのかも？Claudeを使うとすごく生産的なアシスタントになれる。特に小規模から中規模の変更にはめっちゃ役立つ。計画を立てれば、まるで魔法みたい。コードを重複させる傾向があるけど、それくらいかな。カーソルが生成するコードは、私が最後に試したときはかなり手を加えないといけなかった。助けるどころか、逆に遅くなっちゃうことが多い。

Cursorにまだ独自の機能として残っているのがCursor Tab機能だね。最近の編集やカーソルの移動に基づいて、次の編集をほぼ正確に予測してくれる。でも、エージェントの観点から見ると、Claude Codeはタスクを理解し、それを小さなステップに分解して、正確に実行するのにもっと調整されてると思う。全体的に見て、エージェントによるコーディングは、特にテストがバックアップされている場合には、明確に定義されたタスクには最適だよ。ただ、深い技術的な議論やアーキテクチャの決定に関しては、特定の方向に促されない限り、意見を持たないのが残念。ここはGemini Proが得意な分野だけど、コーディングエージェントとしてはイマイチ。だから両方使ってる。高レベルのデザインにはGemini Proを使って、計画を実行するにはClaude Codeに明確な要件を与えてる。自分でもCursor Tabを使って少し編集しながらね。

Claude Codeはすごく印象的だよ。まるでターミナルで別のプログラマーが一緒にいるみたい。完璧ではないし、何をやろうとしてるのか理解するのに助けが必要なことが多いけど、全ての要素が揃って動き出すと信じられないくらい素晴らしい。プロジェクトを本当に理解するために必要なコンテキストをちゃんと与えてないから、正しく使えてないんだけどね。TypeScriptやウェブ開発にも使ってないし。

Cursorのいいところは、o3やGeminiみたいな他の非人間的モデルも使えることだね。o3はローカライズされた難しい問題を解くのに役立つし、Geminiは大規模なコンテキストのリファクタリングに便利だよ。

このスレッドの別のところからのコメントはVSCode Copilotにも当てはまるよね： https://news.ycombinator.com/item?id=44353972

数日間使ってみたけど、統合があって、ファイルを開いて更新を確認する必要がなくなったし、ターミナルモードと比べてリアルタイムで変更が反映されるのが良いね。裏で何をしているのか全然わからなかったから。最初は面白かった一連の意味不明（でも面白い）名前（Pondering、Twerking、Jugglingなど）は、初めのうちの華やかさが過ぎるとあまり役に立たないね…。

この質問に答えるには、Claude Codeを試して体験する必要があるよ。そうじゃないと、ここでの議論は無意味になっちゃう。Linuxターミナルにいるなら、すぐにハマると思うよ。ドキュメントはちゃんと読んでね。CLAUDE.mdを使って、大きなタスクの計画ドキュメントをマークアップ形式で作成して、満足するまでその計画ドキュメントを繰り返し修正してから実装させるんだ。それと、コンテキストの限界に近づいたら、メモリをファイルに書き出して、/clearしてからそのファイルを再読み込みする技術も使ってみて。これでより良い結果が得られるよ。

CopilotのエージェントモードがPlaywright MCPで動かなかった。インストールはしたし、ツール選択の設定にも出てきたけど、copilotはその機能にアクセスできないって言ってる。

IDEプラグインとして同じことができない理由はないよね。

いいね、claude codeのために複数の作業ツリーが必要だなって思ってた。ウェブページについてだけど、スクロールするたびにうざいヘッダーが下がってくるのをなんとかしてほしいな。

こういうワークフローの提案を見ると、個人のコンテキストをどう管理するかが気になる。コワーカーのコードをレビューする時、コードを完全に理解しようとは思ってないし、正しいかどうかもチェックしてない。主に全体の理解を得ることと、明らかなミス（コードスタイルやベストプラクティスなど）をチェックしてる。これで1日にたくさんのPRを処理できるんだ。もっと重要なこと、例えば自分の監督下にあるものについては、ブランチをテストして実装を慎重にチェックする。それぞれのPRの更新についてね。これにはかなり時間がかかる。だから、たくさんのエージェントが動いていて提案を出している中で、どうやってコンテキストを切り替えるのか気になる。特に変更を確認する必要がある場合はどうするの？また、あるタスクの更新が別のタスクの実装に微妙に影響を与える場合、モジュールの依存関係はどう管理するの？

Anthropicは、顧客がいる場所に製品を置かなきゃね。もしみんなCLIやIDEにいるなら、遺伝的コーディング機能をCLIやIDEに入れるのが正解だよ。

あなたのツールはクールだけど、別の問題を解決してるね。今、バックグラウンドエージェントには2つの大きな問題がある。1つ目は、孤立した環境を正しく動かすのにちょっと手間がかかること。難しさはプロジェクトの具体的な内容による。「このユニバーサルコンテナを選んで」から「依存関係を全部動かすのは地獄だ」まで様々。IDEで作業することでほぼ解決できるけど、すでに全てがセットアップされている場所だからね。2つ目は、人々がエージェントがコードをどう作るかを学ぶ必要があること。IDEでエージェントが作業しているのを見ながら、介入したり修正したりできるのは、バックグラウンドエージェントの長期的な成功に非常に役立つよ。

今朝、Claude Codeがそのアプローチを推奨しているのを読んでたんだ。作業ツリーをうまく管理できるのはいいけど、レート制限がまだ問題っぽいね。

かっこいいね！Claude CodeのTS SDKを使わなかった理由は何？パッケージをインストールしてるみたいだけど、手動でclaudeコマンドを立ち上げてるの？ちなみに、electron-trpcも調べてみて。IPC処理がすごく簡単になるよ。

最適な作業方法は、いくつかのGitワークツリーを管理してエージェントを動かすことだね。そうすれば、Claude Codeが終わるのを20分以上待たされることもないし。100〜200ドルの月額サブスクリプションを払えるユーザーに限定してるみたいだけど、APIの価格は月に何千ドルもかかることもあるよ。C.C.は高いけど、私たちの中にはお金の問題が他の人より少ない人もいるから、これを悪化させるツールを作るつもりじゃないといいな。

このコメントでちょっと注目を集めてるみたいだけど、もし誰かがこのCrystalのLinuxインストーラーを試してくれて、動くかどうか教えてくれたら嬉しいな: https://github.com/stravu/crystal/actions/runs/15791009893/a...

私は個人的には違うと思う。商業プロジェクトで毎日Cursorを使ってるけど、バックグラウンドエージェントは面白いし便利な時もあるけど、ほとんどの場合はただの気を散らす要因になってる。コードに集中するには、1つの目標に絞ってそれに向かって繰り返し進むのが好きなんだ。何かが終わるのを待ってる間は、ドキュメントや情報を探してどう近づけるかを考えてる。既存のコードベースや変更を見直すのも、自分の進捗を把握して次に何をすべきかを理解するのにすごく役立つ。いろんなタスクのためにエージェントの群れを管理するアイデアは、私には合わないな。コンテキストの切り替えが多すぎて、マルチタスクが苦手なんだ。

そうだね。他にも色々あるよ。

全てのブランチでエージェントのプロンプトに素早く反応できる通知スタイルの方法。これはスタンドアロンのエージェントマネージャーツールで作られてるけど、エンジニアとしてすぐに飛び込む必要があるときにそれらのツールをうまく使えない。VSCode用のプラグインを書こうとしたけど、Claudeが編集しているファイルと行にジャンプさせるツールを動かすのはうまくいかなかった。なんとか動いたけど、すぐにハングしちゃった。

僕が求めてるのは、デバッグ機能を持つコーディングエージェント。スタックを辿ったり、ローカル変数や引数を検査したり、基本的に何が本当に起こっているのかを見れること。プリントやアサートでデバッグするのとは違って。

笑 Claude Codeはタスクで10ドルをあっという間に使っちゃうよ。

数年使った後にCopilotのサブスクリプションをキャンセルしたよ。何かを奪われて、同じ価格を払わなきゃいけないのが嫌なんだ。それに、エンターを押すたびにお金のことを考えたくない。