【ITニュース解説】Dijkstra, Knuth, Kernighan: 10 Quotes That Predicted the AI Coding Debate

システムエンジニアを目指す皆さんにとって、AIがコードを書く現代は、未来の働き方を考える上で大きなテーマである。AIコーディングの登場により、「コードを書く意味はあるのか」「AIが作ったコードは信用できるのか」といった疑問が日々議論されている。しかし、実はこれらの疑問の多くは、AIが存在しなかった何十年も前から、ソフトウェア開発の歴史を築いてきた偉大なプログラマーたちによって語られていた問題の再燃なのだ。彼らはAIを知らなかったが、その言葉はまるで2026年のAIコーディングの議論に直接答えているかのようだ。これは、ソフトウェアの本質が時代を超えて変わらないことを示している。

エドガー・ダイクストラは1972年に「有能なプログラマーは、自分の頭の厳しく限られた大きさを完全に認識している。それゆえ彼は謙虚にプログラミングタスクに取り組み、とりわけ巧妙なトリックを疫病のように避ける」と述べた。この言葉は、AIコーディングが正当化される根拠そのものだ。人間の脳には限界があり、それがAIに作業を委ねる理由となる。しかし、この言葉の後半が重要である。ダイクストラの言う謙虚さとは「巧妙なトリックを避ける」ことだった。AIは、指示されると印象的な、つまりは「巧妙な」コードを生成しがちである。2026年における真の謙虚さとは、AIの利用を拒否することではなく、その巧妙すぎる出力ではなく、もっと地味で確実なコードを選ぶことだと言える。

ダイクストラは1969年に「テストはバグの存在を示すものであり、バグの不在を示すものではない」と語った。これは、AIが生成したコードをレビューする際に、常に心に留めておくべき最も重要な言葉の一つである。AIがコードを生成し、テストがすべてグリーン（合格）になったとしても、それで作業が完了したと判断する強い衝動に駆られることがある。しかし、ダイクストラの言葉は、テストがグリーンであっても、それは単にバグが見つからなかっただけで、バグが全くないことを証明するものではないと教えてくれる。AIが書いたコードの場合、AI自身がそのコードの仮定を裏付けるようなテストを書きがちであるため、このギャップはさらに広がる。AIが自身の試験に合格することと、コードが本当に正しいこととは別物だ。

ブライアン・カーニハンは1978年に「デバッグは、最初にコードを書くことの2倍難しい。したがって、できるだけ巧妙にコードを書けば、定義上、そのデバッグができるほど賢くないことになる」と指摘した。この言葉は、AIが生成したコードについても全く同じように当てはまる。もしAIがその「賢さ」の限界まで巧妙なコードを書き、あなたがそれを理解しないまま受け入れてしまったら、カーニハンの計算によれば、そのコードをデバッグできるほど賢い人間は誰もいないことになる。これは、いわゆる「雰囲気コーディング」（コードの中身を深く理解せず、見た目や動けばOKという感覚で開発を進めること）が抱える根本的な問題点である。表面上はうまく動いても、いざ変更や修正が必要になったときに、その巧妙なコードに誰も手が出せなくなるリスクがある。

ドナルド・クヌースは1977年に「上記のコードにバグがあるかもしれないので注意せよ。私はそれが正しいことを証明しただけで、試したわけではない」と述べた。クヌースは自身のコードの正しさを数学的に証明できるほど厳密な人物であったにもかかわらず、それでもバグの可能性を警告した。対照的に、AIは何も証明できないにもかかわらず、まるで証明したかのような自信をもって出力を行う。もし、世界で最も注意深いコンピューター科学者が、形式的に検証したコードでさえ慎重な姿勢を取るのなら、AIの「これで動くはず」という言葉に対する私たちの信頼は、もっと低い位置に設定されるべきだ。

ハル・エイベルソンとジェラルド・サスマンは1985年に「プログラムは、人が読むために書かれるべきであり、機械が実行するためには副次的に過ぎない」と記した。この言葉は長らく、チームメイトが理解しやすいコードを書くことの重要性を説いてきた。しかし2026年においては、AIも「読者」の一人となる。きれいで、適切に命名され、構造化されたコードは、AIが自信満々に間違った編集をするのではなく、正しい編集を行うための重要な要素となる。ジュニアエンジニアに優しいコードは、AIにとっても読みやすいコードだ。可読性はもはや「礼儀」ではなく、AIを活用する上での「パフォーマンス機能」になったと言える。

グラディ・ブーチは、フレッド・ブルックスの「銀の弾丸なし」という思想を受け継ぎ、「アマチュアのソフトウェアエンジニアは常に魔法を探している」と述べた。AIは、ソフトウェアの歴史上、最も説得力のある「銀の弾丸」のように見えるかもしれない。しかし、ブルックスの区別は依然として有効である。ツールは「偶発的な複雑さ」（定型コード、構文、連携部分など）を取り除くことができるが、「本質的な複雑さ」（何を構築すべきかを考えること）には何もできない。AIは驚異的な偶発的複雑さの削除ツールであるが、アマチュアはそれが仕事のすべてだと勘違いしがちだ。しかし、それは決してそうではない。

ウォード・カニンガムは「初めてのコードをリリースすることは、借金を抱えるようなものだ」という言葉で「技術的負債」という概念を提唱した。これは、コードの品質を、お金を基準に考える人々に説明するために生まれた言葉である。2026年のアップデートを考えると、AIは初稿コードを以前の10倍の速さで生成できる。これは、その負債を返済しなければ、10倍の速度で負債を積み重ねることを意味する。返済計画のない負債こそが問題である。昼食前に何千行ものコードを生成できるAIは、気づかないうちにあなたのプロジェクトの「クレジット限度額」を使い果たしてしまう可能性も持っている。

Facebookのかつての社内スローガン「Move fast and break things（早く動いて、破壊せよ）」は、2014年には「Move fast with stable infrastructure（安定したインフラで早く動け）」に修正された。このスローガンとその修正は、一つの完全な教訓である。それは、使い捨てのプロトタイプには適しているが、何百万ものユーザーが利用するコードにとっては無謀だ。AIは高速な開発を容易にするが、「破壊」のコストを安くするわけではない。開発段階によって、速度が美徳となるか、負債となるかが決まるのだ。

ディープラーニングの著名な研究者であり、GoogleやBaiduでAIを率いたアンドリュー・ンは、「AIがあるからコーディングを学ぶ必要はないと言うのは、これまでで最悪のキャリアアドバイスの一つだ」と述べた。これは単なる懐古主義ではない。彼の論理は「レバレッジ」（てこの原理）にある。ツールが優れていればいるほど、そのツールを指揮し、出力を検証できる人間に価値が集まる。自分で書けないようなコードの出力をレビューすることはできない。AIコーディングから最大限の恩恵を受けるのは、コーディングを学ぶプロセスをスキップしなかった人々に他ならない。

リーナス・トーバルズの「Talk is cheap. Show me the code.（議論は安っぽい。コードを見せろ）」と、アンドレイ・カルパシーの「The hottest new programming language is English.（最もホットな新しいプログラミング言語は英語だ）」という二つの言葉の間に、現代のAIコーディングに関する議論の全てが集約されている。トーバルズは何十年もの間、議論よりも実際に動くコードが重要だと主張してきた。一方、カルパシーは、英語がコードそのものになりつつあると語る。この二人はどちらも正しいという点が、私たちを悩ませる。英語は機械に指示を与える手段であり、その英語の指示がうまく機能したかどうかを教えてくれるのは、依然としてコードだけだ。2026年に求められるスキルは、意図を正確に記述することと、その出力を批判的に読み解くことの両方である。カルパシーの言葉はドラフト（下書き）を得ることを助け、トーバルズの言葉はそのドラフトを信頼すべきかを教えてくれる。

これらの先人たちは、AIを予言していたわけではない。彼らはソフトウェアそのものの本質を語っていたのだ。作者がAIになったからといって、ソフトウェアの性質が変わるわけではない。私たちが前例のない問題だと考えている議論（生成されたコードを信頼できるか、巧妙さが罠になるか、コーディングは死にゆくスキルかなど）は、私たちが触れたことのない言語で作業していた人々によって、すでに明確に提示されていた問題である。ツールは新しいが、そこにある知恵は長い歴史の中で得られた貴重な教訓なのだ。