これって明らかな質問かもしれないけど、なんでClaude Codeが含まれてないの？

Google Julesはどう？それに、もちろんOpenAI Codexはこの手のタスクに特化してるから、パフォーマンスが良いのは当然だよね。一方でCursorはプログラミングの分野ではもっと汎用的なツール/アプリだし。

マージ率は確かに役立つ指標だけど、考慮すべき他の要素もいくつかあるよね（PRの小さい編集や大きな編集、リファクタリングと依存関係のアップグレード、直接マージ、マージされたミスを修正するフォローアップPR、これらのAIエージェントを設定するのがどれだけ簡単か、マーケティング、使用料など）。NPMのダウンロード数だけでは、パッケージの本当の成功や品質を反映しないのと同じだね。

WindsurfやCursorみたいな専用ツールにはちょっとがっかりしてる。ChatGPTを使うよりも面倒なことが多いから。ニッチな役割はあるけど、使ってるとすごくフローが壊れるから、長時間使うのが難しいんだよね。でも、数日前からCodexをカジュアルに使い始めたら、もう3つのPRができたよ。目的に応じたツールがあるのはいいけど、Codexの完全非同期な感じはすごくいいね。シンプルなことをやってくれるし、一貫性を高めたり、小さな改善をするのが得意で、本当に助かる。特定の問題に対して、もっと家電みたいに動くものがやっと出てきた感じ。前は、まるで学習中のティーンエイジャーみたいだったから。

（免責事項：私はGitHubでコーディングエージェントに関わっています）このデータは素晴らしいし、GitHub全体で自律的なコーディングエージェントの急成長を見るのはワクワクするね。マージ率に関して覚えておくべきことは、これらの製品が作業の異なるフェーズでPRを作成することなんだ。だから、PRの作成からマージまでを追跡するだけでは、各製品の物語が異なるんだよね。AIが生成したコードを反復する作業（十分に良くない場合は放棄する可能性もある）はプライベートで行われていて、ユーザーが共有/マージする準備ができたときに初めてGitHubのPRにプッシュされることがある。これがCodexの場合の例だよ。このような製品体験のマージ率は、ここで示されている統計では良く見えるけど、多くのAI生成コードの変更がプライベートで放棄されている場合もあるんだ。他の製品体験では、タスクが割り当てられたときにすぐにドラフトPRが生成されて、ユーザーはコーディングエージェントと一緒に「オープンに」反復できる。これによって、成功と失敗のケースの透明性が高まる（両方のエージェントセッションのログも含めて）。これはGitHub Copilotのコーディングエージェントの例だね。この「オープンに学ぶ」ことは、個人やチーム、業界にとって価値があると信じている。でも、これがここで報告されているマージ率が悪く見える原因にもなってるんだ。論理的には、他のツールの「タスク割り当てからマージされたPR」成功率と同じなのにね。ドラフトPRの概念をこれらのユースケースにもっと自然に進化させていくことを楽しみにしてるし、これらのコーディングエージェントがGitHubでオープンなコラボレーションから恩恵を受けられるようにしていきたい。