11月5日、Atomic Objectが「Pair Programming With AI Agents: Keep Learning While You Ship」と題した記事を公開した。AIエージェントとペアプログラミングする際に判断力と学習ペースを維持するための実践的な方法を詳しく紹介している。
「同じアウトプット、異なる判断力」という問題
記事の著者は、AIエージェントを使い始めてから「コードは動くが、なぜ動くか説明できない」という状況に陥った経験を率直に告白する。エージェントが「考えた後に使うツール」から「考え始める場所」に変わってしまったというわけだ。
この現象に名前をつけたのが、ニューヨークで開催されたLDX3でのGiordano Scalzoの講演「Tackling the Junior Developer Crisis in the Age of AI」だ（元記事に講演の正式URLは記載されていない）。講演のキーフレーズは「Same output, different judgment（同じアウトプット、異なる判断力）」。
AIを使えば誰のプルリクエストも見た目は似てくる。問題をじっくり探索した人のPRも、チケットをそのままエージェントに貼り付けた人のPRも、外見上はほぼ同じだ。差が出るのは、何かが壊れたとき、デモするとき、クライアントに「なぜこう作ったか」を聞かれたときだ。
コンサルタントとしての文脈で著者はこう述べる。「クライアントはキーストロークに金を払っているのではない。判断力に払っている」。エージェントはコードを書けるが、クライアントの前に立つことはできない。
梯子のいくつかの段が消えた
Scalzoは『Apprenticeship Patterns』（開発者の学び方を論じた書籍）から3つの学習パターンを引用し、AIがそれぞれをどう破壊したかを示した。
- Be the Worst（自分より優秀な人に囲まれて吸収する）→「あなたは一人で部屋にいる」
- Breakable Toys（失敗が前提の小さなものを作る）→「エージェントが失敗する前に答えを埋めてしまう」
- Sweep the Floor（誰も手をつけない地味な作業を引き受けてシステムを学ぶ）→「ルンバを買った」
地味な作業こそエージェントが最も得意とする領域であり、それはかつて最も多くを学べた作業でもあった。
さらにScalzoはエア・フランス447便の事故を引き合いに出す。2009年、リオデジャネイロ発パリ行きのこの便は大西洋上空で墜落し、乗員乗客228名全員が死亡した。速度センサーが氷結して自動操縦が切れたとき、乗務員は手動操縦に切り替えなければならなかったが、機長が直近6ヶ月で手動操縦したのは346時間中わずか2時間だった。練習しない技術は、どれだけ経験があっても衰える。ペアプログラミングは、その「手動操縦の練習」に相当すると著者は位置づける。
AIエージェントがいる時代のペアプログラミング、具体的にどう変わるか
ここが記事の核心だ。著者は「ペアをやめろ」ではなく「ペアのやり方を変えろ」と主張し、実践的な手法を複数提示する。
考えてからプロンプトを打つ
Scalzoのワークショップでは、エージェントを開く前に10〜15分、コードではなく普通の文章で計画を書く。「これはユーザーに何をするか」「最初に噛んでくるエッジケースはどれか」「一番自信がないのはどこか」。著者自身は、テックリードと大まかな方針を話し合ってからエージェントに渡すという軽量版を実践している。
エージェントを「壁打ち相手」として使う
ワークショップで機能しなかったのは、AIをオラクル（答えを知っている神託）として扱うことだった。機能したのはスパーリングパートナーとして扱うこと。解答を求めるのではなく、自分の案への批判を求める。「エージェントが見逃して自分たちが気づいたことは何か」「逆に自分たちが見逃してエージェントが気づいたことは何か」を話し合う。
決断を声に出す
意思決定の後、必ず「Xを選ぶのはYだから。Zを却下するのはWだから」という文を完成させる。空欄が埋まらないなら、それは立ち止まるサインだ。
プロンプトをコードレビューのように扱う
著者がまだ試していないが実験したい手法として、一人がプロンプトを書き、もう一人が送信前にレビューするというものを挙げている。プロンプトは「自分が何を理解しているか」と「何を言い忘れているか」の両方を映す。第二の目があれば、エージェントが誤った方向に走り出す前に文脈の欠落を補足できる。
実際のエージェント活用：「考える前置き」に使う
著者はエージェントの使い方そのものも変えた。今はコードを書く前の理解フェーズに重点を置いている。
- ツアーを頼む：ドキュメントがほとんどない古いプロジェクトに入ったとき、最初の依頼は修正ではなく「リポジトリの概観を教えてくれ」だった。ペアと組めば、各自がシステムの動き方を先に描いてからエージェントの地図と照合できる。
- 仮説を検証させる：「答えを教えて」ではなく「このチームメイトの仮説をコードと照合して」と頼む。勘を具体的な検証計画に変える。
- 「自分でやるとしたらどうするか」を聞く：エージェントに次のステップを任せる代わりに、「自分で調査するにはどこを見ればいいか」を聞く。「How would I check this?」は技術を磨く。「Do it for me」は磨かない。
セッション構成の提案
記事の末尾では、次のペアプログラミングセッションですぐ試せる7ステップが示されている。前半の「計画・批判・対話」フェーズと、後半の「実行・振り返り」フェーズに分けて捉えると使いやすい。
計画フェーズ（エージェントを開く前）
- 実際のチケットサイズの問題を選ぶ
- 二人で大まかな計画を描く
- 一人がプロンプトを書き、もう一人が送信前にレビューする
実行フェーズ（エージェントと協働）
4. 計画をエージェントに渡して詳細を埋めるか、批判を求める
5. それぞれが気づいたことを話し合う
6. 決断を声に出す：「XにするのはYだから」
振り返りフェーズ
7. 最後に互いに確認する：「エージェントなしでこれを説明できるか？」
7番の問いが答えられない状態でPRを出すことが、冒頭の「同じアウトプット、異なる判断力」問題をそのまま再生産する。このチェックリストは、そのループを断ち切るための最小限の構造だ。
AIが摩擦を取り去った分、ペアプログラミングがその摩擦を意図的に取り戻す手段になる——というのがこの記事の骨子だ。エージェントはコードを書けるが、隣に座って「なぜ？」と問いかけることはできない。
詳細はPair Programming With AI Agents: Keep Learning While You Shipを参照していただきたい。
