Copilotの妄想 - The Copilot Delusion

(deplet.ing)

37 ポイント投稿者 GN⁺ 2025-05-25 | 25件のコメント | WhatsAppで共有

AIコーディングツールが実際に開発生産性を高めてくれるという信念は誤解である
このようなツールはプログラミングの楽しさと人間の深い理解力を損なう
AIは反復的なコード生成には役立つが、文脈と性能、ニュアンスには弱点がある
過度な依存は開発者の学習・探究意欲、コード品質を低下させる現象である
プログラミングという職業の本質がAIの利便性によって徐々に失われていく問題が大きくなっている

序論: AIコーディングツールに対する妄想

この記事は2025年5月時点のAIコード生成ツールの現実を扱う
AIの無能さをめぐる議論は時間が経つにつれて弱まるかもしれないが、プログラミングの本質と楽しさの毀損の問題はむしろ深刻化する見通しである

第1章: 私の同僚、プログラマー

実際に無責任にコードをコピー&ペーストする非専門の開発者と働く経験を例に挙げ、そのような同僚が残した性能悪化/バグ爆弾/アーキテクチャ無視の問題を強調する
このような同僚は継続的にテストとプロファイリング、文脈理解なしにコードを修正し、結局はチームの動機と学習意欲を奪っていく
「キャプテン・オビアス」というどんでん返しの告白を通じて、実はこの描写がGitHub Copilot、Claude CodexなどのAIコーディングツールに対する風刺であることを明かす
本物の航空機の副操縦士(copilot)はシステム全体を理解し、協調し、責任感を持つ。一方、AI Copilotは本質的な理解なしに表面的なコードだけを残す
「Copilot」という名前だけを借りて、生産性・イノベーションという見せかけのもと、すべての開発者IDEに強制導入されつつある

第2章: Copilotの利点

AIコーディングツールも完全に役に立たない存在ではない
新人がC++のような言語の複雑な構文を単純に学んだり、コンセプトを素早く参照したりするときには有用である
ブレインストーミング、文脈整理、反復的なテンプレートコードなどは人間のインターンより速く、ミスも少ない
性能や効率性への配慮がまったくない点、周囲の監督なしに放置した場合に製品品質の惨事が起こる危険は明らかである
文脈のないscaffold/草案コードを素早く提供することはできるが、完全な設計とチューニングは人間の開発者の役割である

第3章: 開発者としての私とAI

著者は**「コーディングそのものの楽しさ」や、自分で作る達成感**を重視する
AIに反復コード(boilerplate)を任せ、自らライブラリ/マクロ実装まで放棄するなら、最終的に開発者の創造性と内発的動機は失われる
FOMO(取り残されることへの不安) によってCopilotに依存し、粗雑で検証されていないコードを素早く大量に吐き出す現象を招く
AI依存は本物の学習、低レベルの性能・構造理解、コード品質管理の機会を奪う
「Copilot」という名前は対等な同僚ではなく、短い経験しかないゲーマーが航空機を操縦しようとする幻想に近い

第4章: コンピュータは機械である

機械(ハードウェア)の実体と構造、性能特性を理解する能力は人間にしかない
AIには実際のキャッシュミスやメモリレイアウト、プロファイリング、パフォーマンスボトルネックに対する直接的な直観や経験がない
AIが出す回答は文脈から切り離されており、具体的な最適化が必要な領域では役に立たない
どれほど平凡なCRUDアプリを作るとしても、開発者はユーザーとシステムに対する礼儀、誠実さを持つべきである
専門性と職人気質は直接の経験、苦痛、繰り返された改善の中で形作られる

第5章: 結論

AIコーディングツールとそのアクセシビリティはハッカー精神の消失を招く
真のコーディング/構造/性能への関心がない受動的なユーザーだけが業界に残る現象を懸念する
過去には徹夜のIRC、ハードウェア実験、低レベル探究など、純粋な好奇心と創造性に満ちていた
今では「AIパッチレビュー」だけを繰り返す機械的な業務と無関心が残ってしまった
文脈理解と実際の能力を欠いたコード生成が業界標準になる危険と、本当の実力者が排除される現実を警告する

本文編集履歴

作成日に関するディスクレーマーを追加
HNの意見を反映し、性能批判の範囲(複雑なシステム vs CRUD)に関する立場を明確化
読みやすさのために文体と記号の使い方を一部調整

25件のコメント

roxie 2025-05-27

本文は面白いのですが、あまりにも多くの文章が「AIを使わないのがすべてではないし、だからといって無条件に信頼して慣らされるのもよくない」と要約できてしまう気がして、少し食傷気味ですね……

ifmkl 2025-05-26

LLMやAIは、時間が経つにつれて進化していますよね。ほんの数か月前までは、指示したとおりのコードの一貫性などはほとんど期待できませんでしたが、今ではそのスペース内でAIに初期構成を依頼したコードをファイルとしてアップロードし、新しいコードを書く際には常に既存のコードスタイルを守って書くよう指示して使えば、かなり一貫性のあるコードを書いてくれるようになりました。

crawler 2025-05-26

> 投稿者は以前の投稿を見ると、ゲーム開発者のようです
> ゲーム開発の知識や資料はLLMが大量に学習できておらず、CRUDアプリのケースとは違って、本文の著者のほうがLLMの限界をより強く感じているようです

一通り読んでみましたが、結局これが理由で著者がやや偏った見方をしているのだと思います。
もちろん、本文の内容どおりに進めるのはほとんど教科書的な話なので正しいのですが、
AIは学習できる資料が多いCRUDやフロントエンドについては、すでに十分うまくできていると思います。
自分のドメインの中で、できるだけうまく活用していくべきだと思います。

superscv 2025-05-26

著者が意図した意味の理解に、少し誤解があるのではないかと思います。
著者は、自分が管理するプロジェクトの性能、安定性、そして保守しやすいアーキテクチャやコードの一貫性などに焦点を当てており、代表的な例として、アーキテクチャとコードの一貫性は現在のLLMが本当に苦手とする分野の一つです。

特にWebは、開発への流入が多く、「とにかく動けばいい」という思想が強い領域なので、品質の低いコードがあまりにも多くデプロイされています。そしてそれを基にLLMが学習しているため、出力物の品質が呆れるほど低いです。

試しに、GPTに「Webフロントに入れるんだけど、jsでクイックソートアルゴリズムを実装して」と頼んでみてください。出力物の問題点を見つけられないのであれば、この対話にあまり意味はないと思います。

ohnul 2025-05-26

こんにちは。興味本位で「Webフロントに入れるのですが、js でクイックソートのアルゴリズムを少し実装してくれ」と言ってみたのですが、私には何が問題なのかよく分かりにくくて。教えていただけるととても助かります。あらかじめありがとうございます。 https://chatgpt.com/share/68340f9b-b684-8002-8dd5-495d477065cd

ohnul 2025-05-26

リンクがうまく動作していないようなので、もう一度やってみます。 https://chatgpt.com/canvas/shared/68341217ae788191b66a523c948b1a8e

superscv 2025-05-26

添付していただいた2つ目の quickSortInPlace()、これも遅い実装ですね。

以下のコードを実行してみてください。

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {
if (left >= right) return;

const pivotIndex = partition(arr, left, right);
quickSortInPlace(arr, left, pivotIndex - 1);
quickSortInPlace(arr, pivotIndex + 1, right);
}

function partition(arr, left, right) {
const pivot = arr[right];
let i = left;

for (let j = left; j < right; j++) {
if (arr[j] < pivot) {
[arr[i], arr[j]] = [arr[j], arr[i]];
i++;
}
}

[arr[i], arr[right]] = [arr[right], arr[i]];
return i;
}

function quickSort(arr) {
if (arr.length <= 1) return arr;

const pivot = arr[arr.length - 1];
const left = [];
const right = [];

for (let i = 0; i < arr.length - 1; i++) {
if (arr[i] < pivot) {
left.push(arr[i]);
} else {
right.push(arr[i]);
}
}

return [...quickSort(left), pivot, ...quickSort(right)];
}

const repeat = 100;
const arrLength = 10000;
const unsortedArray = new Array<number>();
for(let i = 0; i < arrLength; i++)
unsortedArray.push(Math.round(Math.random() * arrLength));

let sorted: Array<number>;

const qb = performance.now();
for(let i = 0; i < repeat; i++)
sorted = quickSort(unsortedArray);
const qe = performance.now();

const rqb = performance.now();
for(let i = 0; i < repeat; i++) {
let copied = [...unsortedArray];
quickSortInPlace(copied);
}
const rqe = performance.now();

console.log(q: ${qe - qb} ::: rq: ${rqe - rqb});

superscv 2025-05-26

基本的に、コレクションの生成・運用・マージに伴う負担への理解がまったく感じられないコードだと言えます。C++ の場合、すでに約10年前に Move Constructor に関する提案・実装も登場しており、メモリコピーに関するコストには常に鋭敏であることが基本中の基本です。quick sort はその仕組み上、すべての値の index を確定できるアルゴリズムであり、各フィールドはランダムアクセスできるようにしておくのが望ましいです。

マニアックな最適化なしでも、上記の内容だけを適用すれば、リンク先で示されている方式とは2倍以上の性能差が出ます。

dudlf016 2025-05-27

実際に実行してみましたが、やや遅い傾向はあるものの、2倍まではいかないようです。

function quickSortInPlace(arr, left = 0, right = arr.length - 1) {  
    if (left &gt;= right) return;  
  
    const pivotIndex = partition(arr, left, right);  
    quickSortInPlace(arr, left, pivotIndex - 1);  
    quickSortInPlace(arr, pivotIndex + 1, right);  
}  
  
function partition(arr, left, right) {  
    const pivot = arr[right];  
    let i = left;  
  
    for (let j = left; j &lt; right; j++) {  
        if (arr[j] &lt; pivot) {  
            [arr[i], arr[j]] = [arr[j], arr[i]];  
            i++;  
        }  
    }  
  
    [arr[i], arr[right]] = [arr[right], arr[i]];  
    return i;  
}  
  
function quickSort(arr) {  
    if (arr.length &lt;= 1) return arr;  
  
    const pivot = arr[arr.length - 1];  
    const left = [];  
    const right = [];  
  
    for (let i = 0; i &lt; arr.length - 1; i++) {  
        if (arr[i] &lt; pivot) {  
            left.push(arr[i]);  
        } else {  
            right.push(arr[i]);  
        }  
    }  
  
    return [...quickSort(left), pivot, ...quickSort(right)];  
}  
  
// =============  
  
function quickSortGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSort expects an array');  
    }  
    if (arr.length &lt;= 1) return [...arr];  
  
    const pivot = arr[Math.floor(arr.length / 2)];  
    const left = [];  
    const equal = [];  
    const right = [];  
  
    for (const el of arr) {  
        if (el &lt; pivot) left.push(el);  
        else if (el &gt; pivot) right.push(el);  
        else equal.push(el);  
    }  
  
    return [...quickSortGPT(left), ...equal, ...quickSortGPT(right)];  
}  
  
function quickSortInPlaceGPT(arr) {  
    if (!Array.isArray(arr)) {  
        throw new TypeError('quickSortInPlace expects an array');  
    }  
  
    const stack = [[0, arr.length - 1]];  
  
    while (stack.length) {  
        const [lo, hi] = stack.pop();  
        if (lo &gt;= hi) continue;  
  
        const pivotIndex = partitionGPT(arr, lo, hi);  
  
        // Tail‑recursion elimination: push larger partition first  
        if (pivotIndex - 1 - lo &gt; hi - (pivotIndex + 1)) {  
            stack.push([lo, pivotIndex - 1]);  
            stack.push([pivotIndex + 1, hi]);  
        } else {  
            stack.push([pivotIndex + 1, hi]);  
            stack.push([lo, pivotIndex - 1]);  
        }  
    }  
    return arr;  
}  
  
function medianOfThreeGPT(a, b, c) {  
    return (a - b) * (c - a) &gt;= 0 ? a  
        : (b - a) * (c - b) &gt;= 0 ? b  
            : c;  
}  
  
function partitionGPT(arr, lo, hi) {  
    const mid = lo + ((hi - lo) &gt;&gt; 1);  
    const pivotValue = medianOfThreeGPT(arr[lo], arr[mid], arr[hi]);  
  
    while (true) {  
        while (arr[lo] &lt; pivotValue) lo++;  
        while (arr[hi] &gt; pivotValue) hi--;  
  
        if (lo &gt;= hi) return hi;  
  
        [arr[lo], arr[hi]] = [arr[hi], arr[lo]];  
        lo++;  
        hi--;  
    }  
}  
  
function testQuicksort(qs, qsp) {  
    const repeat = 100;  
    const arrLength = 100000;  
    const unsortedArray = new Array();  
    for (let i = 0; i &lt; arrLength; i++)  
        unsortedArray.push(Math.round(Math.random() * arrLength));  
  
    let sorted = [];  
  
    const qb = performance.now();  
    for (let i = 0; i &lt; repeat; i++)  
        sorted = qs(unsortedArray);  
    const qe = performance.now();  
  
    const rqb = performance.now();  
    for (let i = 0; i &lt; repeat; i++) {  
        let copied = [...unsortedArray];  
        qsp(copied);  
    }  
    const rqe = performance.now();  
  
    // 小数点以下2桁まで  
    const p1 = ((qe - qb) / repeat).toFixed(2);  
    const p2 = ((rqe - rqb) / repeat).toFixed(2);  
    
    console.log(`Quicksort: ${p1} ms, In-place: ${p2} ms`);  
}  
  
function main() {  
    const useGPT = process.argv.includes('--gpt');  
    console.log(`Using ${useGPT ? 'GPT' : 'geekNews'} quicksort implementation.`);  
    if (useGPT) {  
        testQuicksort(quickSortGPT, quickSortInPlaceGPT);  
    } else {  
        testQuicksort(quickSort, quickSortInPlace);  
    }  
}  
  
main();

===
node q.js
Using geekNews quicksort implementation.
Quicksort: 29.55 ms, In-place: 9.94 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 28.42 ms, In-place: 9.07 ms
node q.js
Using geekNews quicksort implementation.
Quicksort: 26.91 ms, In-place: 9.15 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 28.73 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 26.87 ms, In-place: 9.22 ms
node q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.97 ms, In-place: 9.30 ms
node --version
v22.14.0

bun q.js
Using geekNews quicksort implementation.
Quicksort: 32.05 ms, In-place: 17.39 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 30.97 ms, In-place: 17.82 ms
bun q.js
Using geekNews quicksort implementation.
Quicksort: 29.73 ms, In-place: 16.14 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 30.61 ms, In-place: 12.63 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 31.09 ms, In-place: 12.76 ms
bun q.js --gpt
Using GPT quicksort implementation.
Quicksort: 33.24 ms, In-place: 12.75 ms
bun --version
1.2.14

deno q.js
Using geekNews quicksort implementation.
Quicksort: 32.30 ms, In-place: 6.79 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.79 ms, In-place: 6.86 ms
deno q.js
Using geekNews quicksort implementation.
Quicksort: 26.09 ms, In-place: 6.85 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 27.18 ms, In-place: 7.92 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.34 ms, In-place: 8.12 ms
deno q.js --gpt
Using GPT quicksort implementation.
Quicksort: 25.39 ms, In-place: 8.09 ms
deno --version
deno 2.3.3 (stable, release, x86_64-pc-windows-msvc)
v8 13.7.152.6-rusty
typescript 5.8.3

superscv 2025-05-27

ああ……何を言いたいのか理解しました。何と何を比較すべきかを理解されていなかったのですね……。quick sort アルゴリズムに quicksort と in-place という2つの実装方式があるわけではありません……。

そもそも、Array のマージが組み込まれた上記コード内の quickSortGPT()、quickSort()（どちらも GPT が出力したコードです）を作成して AI ユーザーに提供している点を問題視していたのです。

dudlf016 2025-05-27

GPT の応答には quickSort と quicSortInPlace の両方があり、コメントで [...,quickSort(left), ...equal, ...quickSort(right)] の部分を指摘されていたので、quickSort は quickSort 同士、quickSortInPlace は quickSortInPlace 同士で比較すべきだと理解していたのですが、そうではないようですね。

superscv 2025-05-27

「quickSortはquickSort同士で」という言葉に、思わずうなじを押さえてしまいます。

superscv 2025-05-27

記事を読む際は、必ず文脈を確認してください。

今ここで私が自分のコーディング能力を自慢しているわけではありません。いま例として使われている quickSort() のようなお粗末なコードが、GPTで優先度高く出力されている点を指摘しているのです。

GPTで何度か検索してみると、quickSort() 関数の結果だけを単体で提示するケースが多く見られますし、また、quickSort() はあくまで一つの例にすぎません。実務目的でGPTにコードを依頼すると、品質の低すぎるコードが数多く出力されます（有料ユーザーとしての体験です）。そして開発者自身にそれを見分ける能力が欠けている状態では、プロジェクトが壊れていく方向に進む可能性が高い、という本文著者の意見に共感して、私は現在の文脈に至りました。

すでに私の周囲では、このような粗悪なコードが塗り込まれたプロジェクトが増え続けています.

superscv 2025-05-27

当然、比較は quickSort() と quickSortInPlace() の2つの関数の性能比較であるべきです........

superscv 2025-05-27

???? 結果が2倍を超えて3〜4倍も差があるものとして共有しておきながら、2倍まではいかない気がするというのはどういうこと？

superscv 2025-05-26

return [...quickSort(left), ...equal, ...quickSort(right)];

この部分のコードをよく見て、考えてみてください。

roxie 2025-05-27

とても勉強になります

ohnul 2025-05-26

ご回答ありがとうございます！

crawler 2025-05-26

まず、私が言った「ドメイン内でAIを活用する」において、設計や調整を人間が行うのは当然のことです…
これは、昔ならともかく、今は誰もがLLMの限界を知っているので、あまりに当然の前提になっており、わざわざ言う必要もないでしょう。

次におっしゃっていた、開発知識のない一般の人々がLLMを使うケースについてですが、
これは本文でもHacker Newsでも私でも述べたことはないと思いますが、とにかくこの場合でも、利用者が結果に満足できる水準には達しています。
そうでなければ、Bolt.newやv0、Cursorまでが今のような評価を受けてはいないと思います。

superscv 2025-05-26

要約、

著者: 開発者は自ら能力を高め、それを維持しなければなりません。しかもAIはそれほどうまく機能していません。

crawler: え? 自分はうまくいってるけど?

superscv: 問題が多い…

crawler: うまく調整して使うべきでしょう

superscv: そもそも著者が伝えようとしているメッセージから、かなり離れてしまっているようです..

crawler 2025-05-26

著者の分野に言及した理由や、自分のドメインというものがどういう意味なのかを、あまり理解されていないようですね。
自分で考えずにあらゆる判断をAIに委ねるのも愚かに見えますが、
その反対側にいる人たちのことも、私にはよく分かりません。

最後にお聞きしたいのですが、superscvさんはコーディングにLLMをどう使うのがよいと考えているのか、気になります。

superscv 2025-05-26

普段はあまりコメントしないのですが、この文章にだけコメントを残した理由は、著者の考えにかなり共感しているからです。重要なのはAIやLLMそのものではなく、どんな環境が来ても開発者としての「自分」が備えていなければならない、ということだと思います。

LLMは学習されたソースの特性上、世界中に広がるオンラインデータの平均値に近いデータを主に提供します。（前述のjsクイックソートがその証拠です。）だから私はたいてい、思想やデザインの面で一般的な観点とどの程度一致しているか、ずれているか、あるいはこれまでどこに聞けばいいのか微妙だった内容を質問するために多く使っています。

superscv 2025-05-26

さらにこれ以上議論を続けることに、どんな意味があるのかよく分かりません。

そもそも、AIが生成したコードにはある程度のリスク要因があり得るので、十分に精査したうえで適切に活用するのがよい、という意見なのであれば、著者の文章のどの考え方が偏っているのかを説明してもらえればよいのではないでしょうか。要約にも「文脈のない scaffold/草案コードを素早く提供することはできるが、完全な設計とチューニングは人間の開発者の役割である」とあり、似た意味の内容が含まれていますから。

superscv 2025-05-26

著者のメッセージはやや強めに感じられる傾向はありますが、文章をよく読めば、"AIを使うな"という話ではありません。どう活用するかについての提案があり、要点は開発者自身に能力の欠如があってはならない、というメッセージです。

なぜ著者のメッセージが強く感じられるのかを見ると、copilotで開発が可能になるだろう（copilotへの開発依存度が高いニュアンス）という見方に対して応答する立場からメッセージが作られているため、開発者に対して自分自身の存在価値を損なうようなスタンスを取るな、という形でメッセージを展開しているのだと思います。

著者自身も"AIを使うな"というメッセージではないので、結局AIを活用するということであれば、その妥協点のどこかに落ち着くはずで、先ほどご回答された内容ともおおむね近いメッセージになっているように思います。

ただ、最初に書かれていた内容のうち、『偏った見方』という部分には同意しがたく、先に返信させていただきました。

GN⁺ 2025-05-25

Hacker Newsの意見

もし心臓ペースメーカーやミサイル誘導システム、M1戦車に入るソフトウェアのように、完全に堅牢でなければならないソフトウェアを作りたいなら、AIコーディングエージェントは脇に置いて、自分で学ぶ姿勢が必要だと思う。
でも、私たちの大半はそういうものを作っているわけではなく、要件がほぼ同じでスキーマが少し違い、統合方法が少し違うだけのCRUDアプリを量産している。
実際、私たちのほとんどが作るソフトウェアに新しいものはない。
既存の知識を再利用するのが最善であることが多い。
私にとってコーディングエージェントは、過去のコード再利用を極端に強化した版だ。
ついでに言うと、皮肉なことにこの記事自体がAIの書いた文章みたいにも感じた。
- 私はそもそもミッションクリティカルな低レベルコードは書きたくない。
  AIツールを筆者ほど無条件に有用だとは思っていないが、「Cでシステムプログラミングをしないならプログラマーではない」みたいな議論にはうんざりしている。
  フロントエンドを書くのが好きだ。
  低レベルのグラフィックスライブラリを自作したいとも思わない。
  夜中に目覚めてハッキングするタイプではないが、自分の仕事には情熱も誇りもある。
  誰もが筆者のような極端な姿勢であるべきだとは思わない。
  ソフトウェア市場には多様性が必要だと思う。
- 筆者の主張に反論するのはいいとして、この記事自体がAIの書いたものだというのは言い過ぎだ。
  筆者は生き生きした表現、強烈な比喩、本当に面白いユーモアまで交えて、自分なりのスタイルを文章全体に織り込んでいる。
  こういう文章をLLMが書くのは、現時点では本当に難しい。
  これはAIではなく、よく書かれた文章だ。
  主張に同意するかどうかは別として、筆力は認めるべきだ。
- 原文にもこういう一節がある。
  「飛行機を空に飛ばすコードや、人間の命に直結するコードを、おそらくあなたは自分では書かない。大半の人がそうだ。でも、ただCRUDアプリを継ぎはぎで作るエンタープライズで働いていても、結局はユーザーに対して敬意と品位を守る責任がある」
  どれほど単純なソフトウェアでも最低限の責任感は必要だ、という点を強調している。
- 実際、筆者もAIが有用なケースをいくつか認めている。
  筆者の核心的な問題意識は、私たちがAIを「コパイロット」と呼ぶことで、新人がAIを過信してしまうかもしれないという点だ。
  本当のコパイロットは熟練者であり同僚であるべきだが、AIはまだ半分の確率でひどい同僚だ。
  「今の私たちは、好奇心と主体性をシステムの外に置いている。本来伸びる資質のある人材が、AIのパッチセットをレビューするだけで情熱を失っていく現実。ターミナルはスプレッドシートになり、デバッガは棺になる」
  とはいえ、AIも結局は抽象化のひとつにすぎない。
  GC（ガベージコレクタ）のような自動化が当たり前になれば基礎を失うのではと心配するのと同じように、AIによって非常に基本的なプログラミング／学習能力が失われるのではという懸念がある。
  Web開発者は抽象化のおかげでスタックの深い構造を知らなくても、大抵はよいサイトを作れる。
  だがAIは抽象化として穴が多く、本当に基礎を知らないままでもある程度は動いてしまう。
  問題は、ある時点で深刻なバグが隠れていることに気づき、デバッグ・問題解決・自力で学ぶ能力はAIが代われない部分だということだ。
  だから、AIによって学びやすくなる一方で、重要な基礎能力が省略されてしまうのではという不安がある。
  結局、反復と自分でぶつかってみることを通じて成長するのが本当の学習方法だ。
  AIがその「学習」自体まで抽象化してしまうなら、長期的には開発者の能力を弱める。
  もちろん、AIだけを使うからといって誰もが愚かになるわけではなく、主体的に学ぶ人はこれからもいるだろう。
  ただ、全体としてその比率は下がる可能性が高い。
  初心者にとっての「自分で考えて作る」経験そのものが失われるかもしれないからだ。
  そしてAIという抽象化には、結局のところ隙が多い。
  初心者から見ればAIが全部やってくれるように見えても、結局は本質的なプログラミング力とデバッグ力が必要だ。
  だから、AIが作ったコードの問題をきちんと見つけるためにも、結局は技術を積み上げなければならない。
  私もAIコーディング補助をかなりうまく活用している。
  でも欠点がある以上、何もかも良いもののように見るべきではない、というのが私の結論だ。
- 自分用の短いコメディ動画をGoogle Whiskで作ってTikTokに上げてみたのだが、入ってみるとAI生成コンテンツや人が互いに真似し合う動画ばかりだった。
  「オリジナルな創作」には本当に何かあると思っていたが、結局私たちはあまりにも簡単に再現できる存在らしい。
  私たちが毎日コーディングする動画をTikTokに上げても、延々と同じようなアプリが繰り返されるだけだ。
  イーロン・マスクの言う通り、もう残っているのは本当に火星へ行くことだけ、という感じすらする。
  2年前にもLLMはそれほど「幻覚(hallucination)」しないと言ったことがあったし、今でも人間は不可欠だと信じている人は多いが、だんだんそうではなくなると言いたい。
  2年後にもう一度この話を思い出したい。
「機械は本物だ。シリコンも、DRAMも、L1キャッシュも、false sharingも、ブランチプレディクタがコインを投げることさえ、全部本物だ。関心さえあれば扱える」
こういう一節を本当に久しぶりに美しいと感じた。
- 私もまったく同じように感じた。
  筆者がDave Barry風の軽妙さで書いていて、何度も吹き出してしまった。
  Copilotについて共感できる考えを、ユーモアを交えて見事に表現していたのがよかった。
ソフトウェア開発の議論でよく抜け落ちるのは、「コードを書いた結果」だけがすべてではないという点だ。
数えきれないトレードオフを経て結果にたどり着く、その道のり自体がとても重要だ。
ジュニアと少し複雑なコードベースで機能をひとつ作ってみるだけでも、熟練エンジニアとして無意識にどんなトレードオフをしているか、すぐに実感できる。
AIもこうしたトレードオフの概念は持っているが、大半は観察から学んだレベルだ。
「コードをうまく書く助け」になるのは確かだが、最終的に判断し考えるのは人間の役目だ。
LLMは「考えて」はいない。
そしてAIが進歩するほど、人間がますます考えなくなる危険がある。
私にはCopilotの長所も短所もどちらもよくわかる。
ただし、ハッカーや若い頃の「職人気質」とは違って、エンジニアは昔からエンジニアだった。
今日の中核技術が苦労して生まれたのも、当時その難題を何としても解かなければならなかったからだ。
そうした劇的な歴史を「昔はみんなそうしていた」と一般化すると、偏った見方になる危険がある。
- 20年以上、難しいやり方で開発してきたソフトウェアエンジニアとして、難度の高い問題を解くこと自体が特権であり、やりがいでもある。
  単純なCRUDの更新は反復的で退屈だが、ときおり現れる頭を悩ませる課題や、昔大学で学んだ知識を使う瞬間、そして再帰アルゴリズムのような例外的なケースは、キャリアの中の宝石のような存在だ。
  これからのAI主導のソフトウェアエンジニアにも、こうした経験をいっそう大切にしてほしい。
  AIが論理的に答えを出すこともあるだろうが、ときには完全に的外れで危険なほど間違うこともあるので、実際に何をすべきかを知っている人が必要だ。
  AIが「幻覚(hallucination)」を起こしたり、文脈が不足したりする場面では、結局人間が問題を解決しなければならない状況は常にあるはずだ。
私にとっての比較対象はペアプログラミングではなく、海外のアウトソーシング開発者だ。
実際、CopilotやCursor、その他のAIツールがずっと良く感じられるのは、もうZoomコールで曖昧なコミュニケーションの問題や言語の壁、認識のずれのせいで時間を無駄にしなくて済むからだ。
たとえば「root nodeに関連してisChild（booleanを返す）という関数が追加されたが、親の存在チェックとは無関係」だとか、「APIパラメータが急にarrayを受け取れなくなった」といった、アウトソーシングでよくある状況だ。
AIと作業しているときは、こうした問題が起きても、すぐに間違っていると言って理由を説明すれば、すぐ修正できる。
人とやるときほどコミュニケーションや誤解、時間の浪費がほとんどない。
今後AIとJiraチケットが簡単に連携するようになった瞬間、開発作業の80%ほどはチケット作成と監督の役割に変わるだろう。
もちろん、エンジニアの役割がなくなるわけではない。Biz部門が良いチケットを書くはずもなく、結局は誰かが最終責任を負わなければならないからだ。
それでも多くの組織はこの事実を忘れ、その結果として大きな事故が起こる余地がある。
私がこの記事から核心的に受け取ったのは、
「今の後進的で肥大化し、過剰に抽象化されたソフトウェアの現実を、最高のものとして称賛するようになる。性能を極限まで絞り出したり、痩せて鋭く明快なシステムを築いたりする文化は、昔話として残るだけになる」
という部分だ。
2023年以前に作られたライブラリやアーキテクチャパターンが、今後はLLMが学習するデータの中枢として固定化されるのではないかという不安がある。
革新し続けるより、過去30年間に積み上がった依存関係や汚いコードが永遠に続くかもしれない。
JavaScriptのようなものも永遠に生き残りそうで心配だ。
最近のリーダーシップからは、「我々はAIを十分に使っていない」「AIを導入すれば既存スケジュールを半分にできる」と毎日のように圧力を感じている。
新しいAIツールを導入しなければKPIを満たせないと強要され、適応できなければチーム削減まで持ち出される現実だ。
世界は本当にどうかしてしまったように感じる。
AIはいつも「他人の仕事を置き換える道具」としてだけ売り込まれる。
実際にAIが優れているように見えるのは、自分がよく知らない他人の仕事を、十分に理解しないまま評価するときだけだ。
経営陣がAIというハンマーを持って、世の中のあらゆるものを釘に見立てて打ちつけているように思える。
- 本当に、経営層の構造をどうにかして減らし、実際に生産的な仕事へ時間を振り向ける方法を考えなければならない。
  AI活用より、実作業とデリバリーに集中する文化を望む。
- これは結局、AI業界の「ハイプサイクル」のパターンにすぎない。
  いずれ状況が落ち着けば、使い物になるツールと技術だけが残り、大半は消えるだろう。
  何が実際に残るのかを賢く見極め、その変化に影響を与えられるなら、今後も生き残る道はあるし、そう努めるべきだという意見だ。
- 今の「早く導入しろ」という強制は、私が知っていたエンジニアリング／デザイン／技術者としての本質と正反対だ。
  本来はツールや言語、サービスなどを導入するかどうかを慎重に検討し、なぜそれが自分たちのケースに合うのか、どんな長所と短所があるのかを根拠立てて導入するのが王道だった。
  「なぜこれが必要なのか、このサービスがなぜより合理的なのか」という方針決定プロセスが正常だった。
  本当に導入が必要な技術なのかをテストし、その後に成果や導入効率を評価するプロセスがあった。
  今の企業はそうした健全なやり方から遠ざかっている。
- 「AIは常に他人の仕事を置き換えられる道具だ」という幻想があまりにも広がっている。
  実際、単純反復の業務は多いとしても、ほとんどの仕事はうまくやるには固有の機微や繊細さが必要で、そうしたものが自動化の過程で消え去る危険が大きい。
  「AIで80%できれば十分だ」という話には同意できない。
  エラーはシステム全体に影響するし、評価する側はどうしても現場経験が不足しがちだ。
- 近いうちに管理職のほうが先に消えていくだろうと思う。
  それまではお互い頑張ろう、という励ましだ。
筆者は明らかにC++開発者っぽい。
実際、AIコーディングアシスタントがC++でまともに機能することはまれで、うまく使っている人の大半はスクリプト言語やCRUDアプリで効率的に使っている。
- 筆者の以前の投稿を見ると、ゲーム開発者らしい。
  ゲーム開発の知識や資料はLLMが大量に学習できていないので、CRUDアプリのケースと違って、本文の筆者はLLMの限界をより強く感じているのだと思う。
この記事の一部は、TV番組『シリコンバレー』のBertram Gilfoyleというキャラクターの声で読めてしまう感じがした。
そう感じたのは私だけだろうか。
核心は、常に「テレスコープ」の能力を持っておくことだ。
コーディングエージェントのおかげで高レベルな作業だけをしていても構わないが、必要なときにはいつでもコードの奥深くまで入り込み、自分で理解して直せる状態でなければ安全ではない、という指摘だ。

Copilotの妄想 - The Copilot Delusion

序論: AIコーディングツールに対する妄想

第1章: 私の同僚、プログラマー

第2章: Copilotの利点

第3章: 開発者としての私とAI

第4章: コンピュータは機械である

第5章: 結論

本文編集履歴

関連記事

25件のコメント

実際に実行してみましたが、やや遅い傾向はあるものの、2倍まではいかないようです。

Hacker Newsの意見