世界を動かす技術を、日本語で。

コパイロットの幻想

概要

  • 本記事は2025年5月時点のAIコーディング能力に基づく考察を展開
  • AIによるコーディング支援がもたらす功罪を、現場の視点から辛辣に描写
  • ペアプログラミングの実態やCopilotの有用性・危険性を具体例で説明
  • プログラマーとしての成長や、コードへの主体的な関与の重要性を強調
  • AI利用がプログラミング体験や人間的理解をどう変えるかを問題提起

AI時代のプログラミング現場と「Copilot」批判

第1章:同僚プログラマー、あるいはAIの化身

  • ペアプログラミング の現場で、知識や理解が浅い同僚と組まされる苦痛を描写
    • 共同作業なのに「脳」は共有できず、 生産性や品質の低下 を招くことを指摘
  • 理解不足のまま Stack Overflow からコピペしたコードを投入する同僚の例示
    • システム全体の理解不足 やチケット未読、グローバル状態の乱用などの問題提起
  • テストもプロファイリングもなく、 副作用や性能への配慮皆無 な実装を批判
  • バグを量産し、 「生産的」なふりをしてチーム全体の品質を損なう 危険性を強調
  • こうした同僚の行動が、実は GitHub CopilotやClaude CodexなどAIコーディング支援ツール そのものに酷似していると指摘
    • 「イノベーション」「進歩」 と称してAIが現場に導入される現状批判
  • 本物のコパイロット (副操縦士)はシステム全体を理解し、訓練・再認証を受けるプロであることを強調
    • Copilotはただの「過去のブログやStack Overflowの亡霊」であり、 本質的な貢献や責任感はない と断言

第2章:Copilotの功績と限界

  • Copilotの有用性 についても公平に評価
    • 未経験言語(例:C++)の 構文例やテンプレート生成 には便利と認める
    • ただし エッジケースや深い知識 には対応できず、 盲目的な信頼は危険 と警告
  • システム設計やインフラ構築時の ブレインストーミング支援 としては有効
    • 弱点やリスクの洗い出し を高速で提示できる点を評価
  • 単純作業や 疲労時の補助、複雑なコードの足場作りには役立つと認める
    • ただし 監督・検証の手間 は必須であり、 完全な信頼は禁物 と強調
  • 既存の複雑なコードベースの概要把握 には一定の助けとなるが、 全体像や詩的な説明は期待できない と指摘
  • 総括として「優秀ながら思慮の浅いインターン」 のような存在であり、 細部のニュアンスや独自性には弱い と評価

第3章:プログラマーとしての主体性とAI依存のリスク

  • プログラミングの本質的な楽しさ や創造性は、 監督者や中間管理職的なAIの監督 では得られないと主張
  • 「AIは退屈な部分だけ担当」との言い訳 に対し、
    • 本当に退屈なら 自動化やライブラリ化を自ら行うべき と提案
    • AI任せにすることで 学習・成長の機会が失われる 危険性を指摘
  • AIによるコード自動生成は、独自性や新規性の創出には向かない と断言
    • 既存知識の オートコンプリート機能 に過ぎないことを強調
  • コード品質の低下・抽象化の進行 によるパフォーマンス悪化や技術的負債の蓄積を警告
    • ハードウェアやメモリ、キャッシュミスへの意識の欠如 を問題視
  • 本物のコパイロットとの違い を再度強調
    • Copilotは訓練も責任もなく、 現場に「ロシアンルーレット」を持ち込む存在 と批判
  • 「本物のプログラマー」になるためには、機械への敬意と主体的な思考が不可欠 と結論

総括

  • AIコーディング支援ツールの導入は、進歩や効率化だけでなく、プログラマーの成長・主体性・コード品質に深刻な影響を及ぼす ことを論じる
  • AIの「便利さ」に流されず、プログラミングの本質や自分自身のスキル向上を重視すること を強く提案

Hackerたちの意見

いつもテレスコープする能力を持つことが鍵だと思う。コーディングエージェントが高いレベルを維持するのを助けてくれるけど、必要なときにはコードを理解したり修正したりする能力も常に必要だよね。

これ、身に染みるわ。毎日リーダーシップから「AIをもっと使ってない」とか「見積もりを半分にしろ、AI使うから」とか言われて、新しいAIツールを導入しなきゃいけないって言われてる。誰かが導入に関するKPIを追跡してて、うちのチームが十分にAIツールを使わなかったら解雇されて、もっとAIを使うチームに人員を回すことになるって。なんか、世の中が完全におかしくなった感じ。AIはいつも他の人の仕事を取って代わる道具として宣伝されてるけど、実際には他の人の仕事を理解してないからうまくいってるように見えるだけだよ。マネジメントはAI型のハンマーを持っていて、すべてを叩いてみてるだけ。

まあ、大きなハンマーを持ってると、すべてが釘に見えるよね。抵抗するんじゃなくて、なぜみんなが話してるような結果が出てないのかをもっと考えてみたらどう?もし過去2年間、あなたの生産性に何も変化がなかったら、問題はほぼあなたにあると思うよ。多くの人がそれが人生を変えるツールだと言ってるのに、何が間違ってるのかを見つけるのはエンジニアとしての責任じゃない?それとも、みんなが嘘をついてると思って、自分が正しいことをしてると思ってたの?言いづらいけど、これはあまり人気のない意見だけど、かなり厳しい真実だと思う。

マネジメントはAI型のハンマーを持っていて、すべてを叩いてみてるだけ。マネジメントを減らして、実際に仕事をすることに戻る方法を考えないといけないと思う。

これ、身に染みるわ。毎日リーダーシップから「AIをもっと使ってない」とか「見積もりを半分にしろ、AI使うから」とか言われて、新しいAIツールを導入しなきゃいけないって言われてる。これ、すべてが私が理解していたコンピュータ/開発/デザイン/"エンジニアリング"/建築/何でも呼ばれるこの職業に対して完全に逆行してる。通常、私は有能な技術的意思決定者がツールを統合したり、言語や「サービス」、プラットフォームを使うことを選ぶと思ってた。利点が見えれば、何が正しいアプローチかを示す「ケース」を作れるはずだって。つまり、どのように製品のニーズを満たし、欠点を解決し、効率を上げるかってこと。例えば「これが私の設計書で、$THINGをキャッシングに選んだ理由は$REASONで、$DATASTOREはblah blahを提供するから」って。「フィードバックや質問をください」って。これはそのアプローチとは全く異なる。理想的には、「私たちはCoPilot/他のLLMを使うつもりだから、あなたのワークフローに役立つか教えて、1ヶ月後にレポートをくれたら、それを基に続けるか決める」って感じ。

でも、マネジメントはすぐに去ることになるよ。もう一つの靴が落ちるのは確実だから、兄弟、これを約束するよ。強くいてね。

そうだね、これはただのハイプサイクルの現在のフェーズだよ。落ち着くさ。一部のツールやテクニックは残るけど、ほとんどはそうじゃない。どれが残るかを見極めて他人に影響を与えられれば、いい感じになるよ。

AIはいつも他の人の仕事を奪う道具として持ち上げられてるけど、実際には他の人の仕事を理解してないから良い仕事をしてるように見えるだけなんだよね。これはもっと多くの人が認めるべきよく考えられたポイントだと思う。確かに多くの仕事は単純作業や繰り返し作業だけど、色んな種類の仕事には、うまくやれば失われる微妙な部分がたくさんある。だから「AIが80%やってれば十分」なんて思わないよ。エラーはシステムを通じて広がるからね(そのシステムが会社や社会であっても)、そしてその「十分」と評価する人たちが必ずしもその分野の経験者とは限らないから。

確かに、これは共感できる。コパイロットの利点と欠点の両方ね。でも、子供やハッカーが職人だったのに対して、エンジニアはずっとエンジニアだったと思う。今日の基盤技術を作るために解決しなきゃいけなかった驚くべき技術的課題は、彼らがその課題を解決しなきゃいけなかったから存在してるんだ。これだけを見て「昔はこうだった」と言うのは生存者バイアスだよ。

20年以上、苦労してきたソフトウェアエンジニアとして、こう言えることを光栄に思う。難しい問題を楽しんでいる。CRUDアプリのアップデートは、頭をひねるようなランダムな中間の課題がなければ耐えられない。珍しい再帰アルゴリズムや、大学で実際に学んだ難解な知識の応用、大きなO推定を実際にやらなきゃいけないこと。これらは私のキャリアの宝物で、私を正気に保ってくれる。次のAI駆動のソフトウェアエンジニアたちが、AIが時々正しい答えを出したり、時にはひどく間違ったりすることを考慮して、これらのことをもっと評価してくれることを願っている。AIが幻覚を見始めたり、状況の文脈がコンテキストウィンドウを超えたりしたときに、実際に何をすべきか知っている人が常に必要だ。

ペースメーカーやミサイル誘導システム、M1戦車に組み込まれるようなソフトウェアを作りたいなら、そのボットを空気ロックから捨てて学ぶべきだよ。でも、ほとんどの人はそんなことしてない…ほぼ同じユーザーのニーズに対して、少し違う統合やスキーマ、化粧を施したCRUDアプリを作ってるだけだよ。正直に言おう。ほとんどのソフトウェアには新しいものなんてない。何千回も見られてきたし、だからこそ古い知恵を思い出して使ってもいいんじゃない?私にとって、コーディングエージェントはただのコード再利用の強化版だよ。ちなみに、この記事はAI生成っぽいね。

記事に対する反論は構わないけど、この特定の文章がAI生成だって言うのはバカげてるよ。著者のスタイルは生き生きとしていて、力強いイメージやメタファーを使っていて、時には本当に面白い。質的に見ても、著者は長いエッセイ全体を通して独自のアイデンティティを取り入れている。それをLLMにやらせるのはまだ難しい。これはAI生成じゃない。ただの良い文章だよ。前提を信じるかどうかは別として。

面白いのは、Google Whiskで自分の好みに合った面白いクリップをいくつか作って、「よし、TikTokを作ろう!」と思ったこと。TikTokには、AI生成のコンテンツや他の人がただコピーしたものが何百万もあるって知ってた?「オリジナルクリエーション」っていうのには何かあると思ってたけど、みんな簡単に再現可能なんだよね。ほとんどの場所で特別なものを作ってる人はいない。もしみんなが日常のコーディングのTikTok動画をアップロードしたら、同じアプリが何度も繰り返されるだけだよ、他のTikTokと同じように。イーロンがずっと正しかったのかも、もう火星に行くしかないってことだ。2年前に「LLMは思い込みがそんなにない」って言ってた人たちもいるし、遅れてきた人たちにはもう一度聞いてほしいな - 我々人間はもう本当に必要ないかも。!2年後にリマインドして。

うん、記事はAIが役立つ方法について話してる。全体的に、著者は専門家がAIを使うことに問題を感じていない。主な議論は、私たちがAIをコパイロットと呼んでいて、多くの初心者がそれを過信したり頼りすぎたりしているかもしれないってこと。実際には、AIは半分の時間はクソな同僚なんだから。真のコパイロットは、実際にあなたの仲間であり、彼らの仕事の専門家だ。> 今?私たちは、その好奇心がドアでロボトミーされる世界を作っている。かわいそうな奴が「このAI生成のパッチセットをレビューして」って言われて、一日8時間働かされることになるだろう。すべての驚きが無関心に固まってしまうまで。ターミナルはスプレッドシートになり、デバッガーは棺桶になる。一方で、AIはただの別の抽象化だとも言える。結局のところ、ゴミコレクターに過度に依存すると、新人が適切にメモリを管理する方法を学ばないって文句を言う人もいるかもしれない。メモリ管理はほとんどのプログラマーにとって有用な知識だけど、現代のプロのタスクでは実際にはあまり出てこない。それでも、少なくともそれについて知っていることは、プログラミングの理解と習得の深いレベルを持っていることを意味する。時間が経つにつれて、そういった小さくて珍しい詳細が積み重なって、あなたは専門家になるかもしれない。AIは非常に漏れやすい抽象化だから、別のクラスにいると思う。私たちは毎日多くの抽象化を使っている。ウェブ開発者は、スタックの深いレベルがどう機能するかを知る必要は本当にない — 抽象化は非常に強力だから。確かに、高いレベルで操作するためにはネットワークやブラウザの動作について知っておく必要があるけど、限られた知識でも非常に良い、スケーラブルなウェブサイトや製品を書くことは絶対にできる。重要なのは、あなたが何を構築しているのかを知っていて、必要なことを学ぶためにどこに行けばいいかを知っていることだ。(ウェブ開発者がウェブフレームワークを本当に使う前に、HTML/CSS/JSの基本を知っておくべきなのと似てるね。それにはあまり努力がいらない。)AIは違う — 基本的なプログラミングの基礎を知らなくてもやっていける可能性がある…限界まで。答えを探す場所や学ぶ方法を知らなくてもやっていける。結局、AIは大学レベルの基本的なプログラミング課題を完了するのが得意だから。でも、ある時点で、抽象化は非常に漏れやすくなる。あなたのコードは予期しない方法で壊れる。多くの人にとっての核心的な懸念は、新しい開発者がデバッグ、思考、自己学習のスキルを学ぶことがますます少なくなっていくことだ。これらはこの分野で専門家になるために本当に重要だ。そういったスキルは、自分でやってみて、壁に頭をぶつけて、うまくいくまで何度も挑戦することで得られるし、さまざまなプロジェクトや課題にさらされることで得られる。正直、学び方はそういうもんだ — 繰り返しと練習!でも、もし私たちが学ぶ行為そのものを抽象化してしまったら、多くの開発者の長期的なスキルにどれだけ悪影響を与えるか疑問に思うのは当然だ。もちろん、AIがみんなを無知にするとは言ってない。道中でコアスキルを身につける賢くて意欲的な人たちもいる。でも、それをする人の割合が減るのはかなりありそうだ。挑戦されない限り、そういったスキルは得られないし、AIがいることで、初心者向けの「プログラミングを学ぶ」課題が trivial になってしまう。つまり、人々は自分自身に挑戦しなければならない。そして最終的に、抽象化はただ漏れやすいだけだ。AIは初心者には問題を解決してくれるように見えるかもしれないけど、蜃気楼を見抜くと、自分のコアなプログラミングやデバッグスキルを抽象化することはできないと気づく。AIがあなたのために作り出す問題を修正するためには、実際にそのスキルに頼らなければならない — だから、学んでおくべきだよ!!ちなみに、私はAIコーディングアシスタントを使っている人間としてこれを言ってる。全てが悪いわけでも良いわけでもないと思う。でも、便利だからって欠点を無視するわけにはいかないよ。

基本的に、ミッションクリティカルな低レベルのコードを書くのは私がやりたいソフトウェアじゃないんだ。著者と同じ理由でAIツールがあまり役に立たないと思ってるけど、「Cでシステムを書いてないなら本当にプログラミングしてない」って考えにはちょっと疲れちゃう。私はフロントエンドのコードを書くのが好きなんだ。低レベルのグラフィックスライブラリをゼロから書く必要がある仕事には絶対に就かないと思うし、そもそもそんな仕事が欲しいとも思わない。まあ、私は赤目の3時のハッカー脳じゃないけど、情熱を持って自分のやってることに自信がある。ソフトウェアで働くすべての人が著者の考え方を持つ世界は現実的でも望ましいとも思わない。

TFAから: > もしかしたら、あなたは飛行機を空に保つコードを書くことはないかもしれない。もしかしたら、人の命がかかっているビットを押すこともないかもしれない。いいよ、ほとんどの人はそうだ。でも、たとえ膨れ上がった企業のために別のCRUDアプリを組み立てているだけでも、ユーザーには敬意を払うべきだよ。彼らには尊厳を与えるべきなんだ。

機械は本物だ。シリコンは本物だ。DRAM、L1、偽の共有、ブランチ予測がコインをひっくり返す—それは全部本物だ。そして、もし興味があれば、あなたもそれを使って働くことができる。これはしばらくぶりに出会った最も美しい文章の一つだ。

同感だよ。著者はデイブ・バリーみたいに書いてる。何度も笑っちゃった。彼はコパイロットについて私が思っていることを、たくさんのユーモアで的確に表現できていた。

これらの議論で最も見落とされがちなのは、「コードを書くこと」が最終的な成果物だということ。成果物を作る過程での無限のトレードオフを考慮していない - そこに至るまでの旅を。少し複雑なコードベースでジュニアと一緒に機能を実装してみれば、経験豊富な開発者として無意識に行っているトレードオフをすべてキャッチできるだろう。AIはこれらのトレードオフが何であるかの概念を持っているが、それは主に観察によるものだ。AIはコードを書くのを手伝う。そこでのキーワードは「手伝う」。でも、考えるのは人間の仕事だ。AIにあなたが望む出力を生成させる方法を考えるのもあなたの仕事だ。モデルが良くなればなるほど、考えることは少なくなるだろう。

これが私にとっての要点だね:「今の膨れ上がった、鈍重で、過度に抽象化された地獄をソフトウェアの頂点として崇めることになるだろう—システムから最後の一滴のパフォーマンスを絞り出すことや、スリムでワイルドで正確なものを作るというアイデアは、まるで伝説のように聞こえるだろう。」これは2023年以前のライブラリやパターンが、ほとんどの新しいコードがLLMによって生成されるイベントホライズンを越えると、石に刻まれてしまうという私の懸念と一致している。私たちは革新しているわけじゃなくて、過去30年間の開発のひどい依存関係スタックやクルッジを永遠に強化していくことになる。Javascriptは永遠に生き続けるだろうね。

これを読むと、どうしてもバートラム・ギルフォイルの声で頭の中に浮かんできちゃった。誰か、私だけじゃないって言って!

著者は明らかにC++プログラマーだね。最近、これらのAIツールがC++では他の言語、特にスクリプト言語よりも劣っていることに気づいてる。これらのツールをうまく使ってる人たちから学ぼうとすると、いつもスクリプト言語を使ってCRUDアプリに取り組んでるみたい。

他の投稿から判断すると、ゲーム開発者みたいだね。LLMがスクレイピングするためのコンテンツは、また別のCRUDアプリよりもずっと少ないんじゃないかな。

私の比較対象はペアプログラミングじゃなくて海外の契約者だね。CopilotやCursorなんかは、Zoomコール(Slackが失敗した後)で、ルートノードに関わるシステムの一部が、子ノードがあるかどうかに基づいてブール値を返すisChildという関数を突然持つようになった理由を尋ねる必要がないから、基本的により良い体験なんだ。あるいは、以前は配列を受け入れていたAPIパラメータが今は受け入れなくなった理由を理解するために。あるいは、メニューに定数リテラルを表示しないように頼んだら、i18nを使うのではなく、順序数のアルゴリズム的導出になった理由を理解するために。AIを使えば、そういうことは起こらないだろうけど、もし起こったら、すぐに「ごめん、それは間違ってる、こういう理由で」と言って、1分で変更できる。契約者と違って、コミュニケーションや理解のギャップ、言語の壁に多くの時間を無駄にすることがほとんどなくなるから。JiraチケットからAIと本当に簡単にやり取りできるようになった瞬間に、ほとんどのエンジニアは自分の仕事の80%をチケット作成者や監視者に変わるだろうね。(そして、エンジニアはまだ必要だよ。プロダクトはまともなエンジニアリングチケットを書けないから、AIにエンジニアリングチケットを書かせるのは多分近いところまで行くけど、誰かが状況を把握している必要があるから、そういうことを忘れようとする組織も多いけど、そうするとひどいことになる。)