エージェントベースAIはなぜ優れたペアプログラマーではないのか

• LLMエージェントは人間よりはるかに速くコードを書くため、ペアプログラミングの体験がむしろ低下することがある
• 速すぎる自動化によって、ユーザーがついていけず、作業のコンテキストを見失う問題が頻繁に発生する
• この現象は、経験豊富な開発者とのペアリングで感じた疎外感に似ており、最終的には品質管理とコミュニケーションの弱体化につながる
• 解決策として、非同期のコードレビュー中心の協業と、AIとのペアリング速度を落として品質管理とコミュニケーション中心のワークフローへ転換する方法を提案している
• AIエージェントにも人間のように「立ち止まって対話し、自信よりも疑いと検証に集中する」設計が必要である

---

LLMエージェントとペアプログラミングの問題点

• AIエージェント（例: Copilot Agent）は人間の思考速度よりはるかに速くコードを書く
• その結果、ユーザーは追いつく前にコードが次々と出てきて、コンテキストを見失い、作業への没入度が低下する現象が起きる
• 問題が起きてエージェントが助けを求めても、ユーザーはすでに状況を把握できておらず、「後始末」を担うことになり、結果として 誤った方向に進んだコードを整理する負担 が大きくなる
• 結局、品質管理、コミュニケーション、正しい方向性の維持が難しくなる

• 最高のAIエージェントとペアを組む体験は、かつての 卓越した人間プログラマーとのペアリング で感じた ネガティブな記憶 を思い起こさせる
  • ペア相手が 過剰な速度で無言のままキーボードを打ち続ける ことで、コードについていけなくなる
  • 精神的なエネルギーをすべて使い果たし、次第に作業から遠ざかってしまう
  • ペアが行き詰まった瞬間に助けを求められても、状況把握が難しい戸惑う体験になる
  • 作業の進行中に 目標と異なる方向の実装 が作られ、締め切りまでに修正しなければならない負担を押し付けられる

The path forward: 実践的な解決策

• 1. 非同期の協業

  • 人間とのペアプログラミングで一人が主導して進めるときのように、AIがコードを独立して書き、Pull Requestでレビューする形 のほうが効果的である
  • GitHub Coding Agent などの 非同期ワークフロー を活用すれば、ユーザーはレビューと品質管理に集中できる

• 2. 速度を落とした「ターン制」のペアリング

  • AIの Agent Mode の代わりに、Edit/Ask Mode のように一度に一段階ずつ進める方式 を使う
  • Ping-pongペアリング（一方が提案し、一方が承認する）のように、AIが提案した変更をユーザーが直接受け入れ／確認しながら速度を調整 する
  • 問題解決やデバッグだけにAIを使うのではなく、一貫したワークフローの中で活用することが望ましい

エージェントペアリングをより人間的にするアイデア

• ユーザーが コード出力速度（行/分、語/分） を直接調整できるようにする
• エージェントを一時停止 して、ユーザーが質問したり方向性に異議を唱えたりできる機能
• 既存の チャットボットUIを超え、作業進行状況と連動したUIプリミティブ（例: 現在のセッションを特定のGitHub Issueに固定、内蔵To-doリストなど）を提供する
• エージェントがより頻繁に立ち止まり、対話するよう設計する: 「なぜこれをやるのか」の確認、助言の要請、方向性の点検など、人間との協業の雰囲気を作る
• 高度な音声チャット対応 を導入し、ユーザーが目はコードに向けたまま音声でAIとやり取りできるようにする

• こうした機能が適用されれば、現在の速く一方通行なエージェントペアリングではなく、真の 人間-エージェント共同協力体験 が可能になるだろう

結論

• 現時点では、AIエージェントベースのペアプログラミングの限界と可能性を同時に目撃している
• AIエージェントによるペアプログラミングは、単に速いだけでなく、人間との協業のようにコミュニケーション・品質・検証を中心に設計したとき、より大きな効果 を発揮できる
• 「ゆっくり、対話し、検証し、状況を共有する」 方式が、AIペアリングの質を高める

[panarch]

> 1. 非同期のコラボレーション
> 人間とのペアプログラミングで一人が主導して進めるときのように、AIがコードを独立して書き、Pull Requestでレビューする形のほうがより効果的である

Codexを数日間使っていますが、エージェント型よりはこちらに共感します。複数のプロジェクト作業を同時に回せるようになって、本当にジュニア開発者数人と一緒に働いているような経験をしています。
非同期でAIを使えるようになると、複数のプロジェクト、そして1つのプロジェクト内でも複数の作業を同時に任せられるようになり、生産性が単純計算で3〜10倍以上出るのを本当に実感しています。

[GN⁺]

Hacker Newsの意見

• これがまさに、自分がこういう形でAIを使ってすぐにやめた理由を正確に説明している文章だと感じた。自分が何かを作りたいとき、すでにだいたいの<i>方法</i>は決めているのに、AIが実際にやるやり方が自分の望むものとしばしば違うからだ。しかもAIが2,000行のコードを一度に生成すると、かえって仕事が増える。「まずこのコメントを全部消して、シンプルなコードに不要な説明が倍になってる。Xはこう抽象化しないで、私はこうしたい……」のように指示しなければならず、フィードバックを与えると今度は2,000行が700行に急に変わってしまって、追いかけるのがとても大変になる。コードベースが、自分もよく分からない、やり方もバラバラなスクリプトだらけになるのも嫌だ。自分のスタイルや考え方に近いAIが必要だが、それがとても難しい。AIと一緒に働くのは、経験のない誰かと初日に一緒に仕事をするのに近い感覚だ。個人的には、これはツールの自信過剰というより、設計プロセスがより露わになったという話だと思う。理想的には、「こういうアプローチを考えていて、こういう関数やクラス、状態をこういうやり方で管理する予定です」という設計書を先に見て、問題なければその次に実装へ進む手順が必要だ。

  • 人間のエンジニアと同じく、まずプランニングセッションが本当に重要だという点を強調したい。コードを書く前にまず議論し、交渉するように細部を詰める。自分はわざと最初の質問をできるだけ曖昧に投げて、予想外の提案が出るかを見て、そこから徐々に具体化していくやり方で進めている。十分に満足したら、LLMにinitialprompt.txtとTODO.mdという2つの文書を作らせる。initialprompt.txtにはプロジェクトの要約とTODO.mdを読むようにという指示、それから各段階が終わるたびにチェックを付ける命令を含める。このやり方のおかげで、LLMは全体目標と細かな作業の両方を把握でき、あとでコンテキスト制限のせいで会話が途切れて再開するときも、素早く作業内容を思い出させてくれる。

  • 自分の経験をそのまま要約してくれたように感じる。AIが書いたコードでうまく終われたのは、結果物だけが重要で、その分野について背景知識がほとんどないときだけだった。自分の中で何が「良い結果」なのかについて強い意見があると、結局は挫折してプロジェクトを諦めることが多い。roo codeのarchitect機能でまずアプローチを整理し、その後code modeで実際のコードを実装するときは、喜びと苛立ちが半々だった。重要な教訓は、常に新しい作業として始めること、長い会話を引きずらないこと。自分はもともと問題を細かく分割して結果を確認するタイプなのに、LLMには問題空間全体を一度に投げて失敗しがちだった。自分なりのやり方を見つけるために何度も試し、今日も30分でアプリの機能を追加した。自分で実装すれば本当に数日かかった仕事だった。そして実際に30分しか工数を記録しなかったのは、自分が欲しいものをはっきり分かっていて、過程には関心がなかったからだ。こうした経験から、いつか他人が使うコードをAIに任せるのは、あらゆる意味で不可能だという結論に至った。

  • 結局、ひどく疲れるだけで、結果にも満足できない経験ばかりだった。こういう悩みを持つ人にはそう言いたい。自分もエージェントコーディングに満足したのは、コード品質を気にしない短命なスクリプトか、本当にどこにも影響しない末端の関数だったときだけだ。

  • AnthropicのClaude Code活用ガイドで推奨されているワークフローは勧められる。要点は「まずコードを読ませ、その後で変更計画を立てさせ、最後に実行させる」こと。AIがコードを1行も書く前に計画書を見て修正できる。エージェントを使うとき、自分の望むやり方と違う動きをするなら、たとえば設計図なしでいきなりコーディングを始めるなら、単に「別のやり方でやって」と求めればいい。

  • 2,000行のコードを一度に生成するって話、もしかしてSNESでSkyrim全部を動かせみたいなプロンプトを入れてるんじゃないか。昼を食べて戻って実行してみたら、PS1風で近接攻撃しかないFalloutを作られて怒ってる、みたいな情景が浮かぶ。

• HNの1ページ目に記事が載ると、いつもコメントを見て、自分がどれだけ間抜けか、人々がどれだけ自分の面子を引きずり下ろす攻撃的な発言をするかと怖くなる。けれど、ときにはタイトルが本当にうまく決まると、誰も本文を読まずに各自が自分の話ばかりして、結果的にそういう非難を免れることがある。

  • 愉快でありつつ現実的な話だと思う。他の記事でも似たパターンをよく見る。いずれにせよ、こういう議論そのものが好きなので楽しい。

  • 良い記事だった。いわば「AIとペアプログラミングを楽しむ方法」みたいな感じだった。役に立ったので感謝している。

• LLMエージェントを最初に使ったとき、自分は双方向のやり取り、本当の協調的なペアプログラミングを期待していた。だが実際には、完全に自分のやり方で全部を解決しようとする相手に出会った。自分が少し直そうとすると、AIが書いたコードのコンテキストが壊れて、かえって不便になる。自分が欲しいのは、自分が少し、AIが少し、互いに交代しながら進める本当の共同作業だ。

  • 最近もう一度試したかと聞きたい。自分の経験は違う。私はAIが生成したコードを修正した後、ファイルを読み直すように指示する。すると普通は「ファイルに変更がありますね」といった反応をする。AIがコードを変えたら、私がテストを回してフィードバックを返し、反復的に改善する。ZedとClaude Sonnetではこのやり方がよく機能する。

  • 自分がだいたい使うやり方は、まずAIの提案を受けて、必要ならリファクタリングしたり、プロンプトで再度指示したりすること。こういうアプローチには受け入れ率（accept rate）を人為的に高める効果があり、その統計がAI企業の「AIは非常に良いコードを書く」という主張の根拠になり得る。実際には、「はあ、もう自分で直すか」と思って受け流した瞬間も多い。

  • 自分は主に「まずは議論だけしよう。コードは変更するな」と付け加えると、望む形で会話できる。十分にやり取りしたあと、最後に「適用して」と指示する。

  • 望む協業の形があるなら、それを具体的にLLMに要求すべきだと助言したい。どの会話でも取り出して使えるプロンプト文書をいくつか用意しておくとよい。

  • 最近は文脈維持が大きな問題ではなく、コード修正にも支障はない。自分はAskモード（コマンドではなく質疑応答中心）でしか使わず、Claude CodeではOpus、Cursorではo3 maxを使っている。エージェントモードは意図的に避けている。元記事のように、時間が経つほど自分が得る利益が少ないからだ。タブ補完はたまにしか使わず、提案コードの80〜90%は自分で修正して打ち直す。そのおかげで170wpmの速度で打ち続けられる。Opusとo3 maxは出力速度が制限されているので、読むのもそこまで大変ではない。最初は速すぎてきつかったが、すぐ慣れた。個人的な評価では、もしGitHub CopilotがLLM体験のすべてなら、それはモーテル級の体験にすぎない。

• ペアプログラミングもあらゆる状況に適しているわけではない。むしろ多くの場合は適していないかもしれない。別のところでも言ったが、LLMの自動補完提案のせいで集中してコーディングする流れが途切れ、途中で止まって読んで確認し、受け入れるか拒否するかを判断しなければならず、プログラミングのフローが完全に壊れる。自分のワークフローにAI補完を組み込もうとして本当に苦労した。

  • 私も同感だ。解決策は、AIなしの専用IDEとCursor/VS Codeの両方を使い、交互に切り替えること。本当の没入やディープワークは、チャットボットと会話しながらでは不可能だ。

  • 最近新しいノートPCを買ってIDEを入れ直し、数時間コーディングしている間ずっと何かが「変だ」と感じていた。よく見たらGitHub Copilotへのログインを忘れていて、AIなしで作業していたのだ。コード補完を待つ必要がないので、はるかに積極的にコードを書いている感覚があった。特にCursorは作業の流れをずっと邪魔するので、「次のカーソル位置を予測」みたいな機能も本当に不要だ。今後はCopilotは切っておき、boilerplateや反復作業にはaiderのようなエージェント型ツールだけを使うつもりだ。

  • AIの自動補完やコード提案機能は、特に強い型付けの言語では最悪だ。たいてい80%は合っているが、IDEの自動補完はほぼ100%正確だ。AIエージェント方式のほうが優れている点は、1) 思考の流れを絶えず邪魔しないこと、2) 自分でコンパイルやテストを回し、間違いを直したうえで正しいコードを返してくれることだ。

  • 自分はむしろ自動補完が大好きだ。Go言語を書かなければならず、boilerplateがとにかく多いので、ライブラリ追加などで解決できない問題も多く、むしろ自分で打つほうが速いことも多い。面倒なコードを書くのはAIより自分の手のほうが速いので、自動補完は本当に助かる。1行の提案なら一瞬で読めるし、長い提案でも自分が書こうとしていた内容に近ければそのまま進められる。繰り返しているとAIが何を予測するか感覚がつかめてくる。劇的な生産性向上ではないが、ログメッセージやforループのような面倒な部分は確かに速くなる。自分が読む速度のほうが実際にタイプするより速い場合にだけ役立つと思う。

  • ペアプログラミングが常に合うわけではないが、大半の状況では有用だという見方だ。うまく合わないのは、たいてい片方または両方がこのプロセスに積極的でないとき、どちらかが「こんなの無理だ」と拒絶するとき、あるいはペアプログラミングの原則を厳格に守りすぎるときだ。

• 立場が少し複雑だ。少なくとも1か月、会社でさまざまなLLMツールをすべて積極的に使い、できるだけ効果的に活用する方法を学んでいる。コード行数ベースでは確かに生産性は上がる。だが全体としてより生産的だとは言えない。完了した各作業ごとに説明のつかない妙な動作をしたり、ときには関係ない部分まで触って結局巻き戻さなければならなかったりする。AIが自動生成したテストは最初はもっともらしいが、カバレッジなど別の指標で見ると不足が明らかだ。望む結果にたどり着くには、むしろいくつもの段階を逆戻りしなければならない感じがある。利益や学習どころか、完全に後退しているような体験だ。以前、一度だけ5万行の不要なimportコードが、もともと変更対象ではないモジュールにこっそり追加されたこともあった。またあるときはルールを明確に設定したのに、オブジェクト指向の構造全体を壊し、if/elseだらけで実装されたこともあった。問題は、状況によって結果があまりにも違うことだ。同じ作業でも、あるときは完璧なのに、あるときは全体を壊してしまう。作業の任せ方や誘導の仕方をいろいろ試したが、似たような作業でも振る舞いが違いすぎるので、毎回変更内容をレビューしなければならない苦痛がある。コードがほぼ合っていても、特定の部分だけ直してくれと頼むと、かえって全体が変な方向へ行ってしまう。私の経験では、小規模ツールを書くレベルでは有効だが、中〜大規模コードベースでは一貫した結果を期待しにくい。

• LLMエージェントはおしゃべりすぎて、いつも自分のやり方が正しいと思っている感じがする。簡潔ではなく、1行で済むこともものすごく長く説明する。些細な変更にも長文のコメントを付けてくる。こちらを教育しようとしてきて、過剰すぎるスタイルだ。

  • 人々が嫌う一部の挙動（「出力が長すぎる」「コメントが多すぎる」など）は、LLMが別の面で効率を上げるよう設計された副作用なのかもしれない。長い出力は、手抜きでないコードや高い性能ベンチマークと結びつく傾向がある。コメントの乱発も、ローカルコンテキストを強化して次のコード品質を上げ、エラーを減らすことと関連している。

  • 昨日sonnet 4を使ってみたが、たった1つの設定値を変えようとする作業に15分使い、ひたすらテストとリファクタリングを繰り返した。結局、無駄に40ファイルを変更した。存在しないデバッガを何度も実行しようとしたり、認証が必要なWebページを開こうとし続けたりもした。本当に完璧とは程遠いと感じた。

• 私の経験では問題は速さではなく、むしろ遅すぎることだ。速度が微妙に中途半端で、それがかえって悪い。もっと速ければコードをリアルタイムで追いながら作業できただろうし、もっと遅ければその間に別のことをして戻ってこられる。だが現実には50秒〜数分単位で作業が終わるので、他のことに集中できない。むしろもっと小さな単位で素早く反復するほうが良いと思う。究極的には、人間のレビューに近い自律性、たとえばマージリクエスト（PR）をレビューするような独立した作業のほうがよい。今のループ（作業を渡す→1〜3分待つ→結果を見る→フィードバックを返す→繰り返す）は、個人的には最悪のケースだ。

  • この話を聞くと、オートミールの「遅いインターネット vs まったくないインターネット」の漫画を思い出す。

  • 集中が散るなら、机に30Lの水槽を置けという助言。ぼーっとするには最高だという気の利いた話。

• 開発者として、自分はAIをほとんど使わず、たまにプロジェクト外の質問用にチャットボットを使う程度だ。クライアント案件にもAIを使っているのか、それとも個人的なpet projectだけなのか気になる。クライアント向けで使うなら、コードがAIに送られることを契約書に含めているのか聞きたい。ほとんどのクライアントはNDAの形で外部公開禁止契約を結ぶし、AI利用まで禁止する条項を置いていたクライアントもいた。AIコーディングツールを例外として認めるクライアントに会ったことがあるのか知りたい。

  • 私はほぼ社内でしか使わない。それも会社に明確なAI利用ガイドラインがあるからだ。実感としてはそれほど時間を節約してくれないので、自分の個人作業のためにお金を払って使うことはない。個人プロジェクトでは結果より自分で作る楽しさのほうが大事なので、プロンプト作業より自分で作るほうが楽しい。

  • クライアント側からAI利用を積極的に求めてくることもある。より高品質で、より速い開発を期待している（結局はコスト削減が目的）が、現実はその期待と違うことも多い（とはいえ、それはまた別の話だ）。

  • OpenAI/Anthropicには、Web検索欄にそのまま貼り付けられる程度に公開可能なコードしか共有しない。

  • 私は共有しない。社内プロジェクトも含めてで、外部にコードを共有するのは対価がある場合だけだ。個人情報も扱っているので、アメリカ企業にコードが露出するなら法的リスクが大きすぎる。

• ついに誰かが核心を突いてくれた。AIは設計については過剰な自信を見せる一方、詳細実装は相談もなく勝手に進めるスタイルだ。モックAPIですら構造を守らないことが多く、作り直しが必須になる。LLMの振る舞いがもっと協調的で、ディテールが不足していればすぐ質問してくれるスタイルになってほしい。最初のプロンプトにすべての情報を入れることはできないし、追加のプロンプトは最初の設計の文脈や思考の流れを壊してしまう。自分の使い方が悪いのか、もっと良い方法があるのか知りたい。LLMがフィードバックを段階的に受け取り、反映する方向に改善してほしい。文脈の追加や更新そのものが難しい問題なのかもしれないが、それでも学び続けたいと思っている。

  • 最近のたいていの技術スタックは「設計／計画」セッションをサポートしているので、まずこれを試すと改善があるはずだ。自分がよく使うワークフローは、大きなモデルでも小さなモデルでも、「@file、@docs、@examplesを基準に、@module_requirements.mdを参照しながら@pathで_作業を進めたい。実装の前に必要なことを全部話し合おう」という会話から始めること。前後にやり取りして合意できたら、.mdファイルなどに保存しておくか、そのまま「では進めて」と渡せる。.rulesや.mdファイル、IDEスニペットなどでワークフローを登録しておけば、新しい作業ごとに繰り返し使える。最新のLLMははるかに多くの文脈を必要とするので、コードベースごと（プロジェクトごと）に異なる流れを試す必要があり、それによって結果も変わることを覚えておいたほうがいい。

  • 情報が増えるほどAIが混乱しているようにも感じる。たぶん克服する方法はあるのだろう。ごく小さな情報の断片を取り出すのは得意だが、業界全体がチャットボットモデルにばかり集中している雰囲気は残念だ。もし私たちがキーボードやマウス、GUI、タッチスクリーンを作り続けていなかったらどうなっていたか、と想像してしまう。

• AIを補助役として使う協業型スタイルこそがAIの正しい使い方であり、「AIにコードを直接書かせる」ことに集中する今の流行は、むしろソフトウェア業界が間違った方向へ流れている例だと思う。私はAIにコードを書かせることは絶対にしない。自分が書いたコードを批評させたり、大規模なコード構造の設計戦略を立てさせたりするためにだけ使う。いわば戦略コンサルタントとして使うのであって、LLMの文脈をうまく組み立てれば非常に優れたガイドが得られる。主体は常に自分であり、理解し、実行するのも自分で、AIにはあくまで助言者以上の責任を与えないという原則だ。AIは「バカ天才（idiot savant）」だと考えて慎重に扱うべきだ。