実際にはそんな風にはいかないよね。「みんながどうやって物事が動いてるのか知らない」っていうのが問題じゃないと思う。人は料理の細かい化学や物理のメカニズムを理解しなくても、自分の食べ物を作ることができたから。でも、基本を理解しなくなるのは問題だよね。たとえば、店で用意された卵を買うだけで、自分で卵を焼くことができなくなるとしたら、それは全然違う無知だし、もっと危険だよ。農業企業が小麦や肉を生産するのは問題ないかもしれないけど、もし企業がみんなのために標準化された料理を作り始めたら、それって本当に同じことなのか？それは良い進化なのか、そうじゃないのか？ここが議論のポイントだね。

ここで主張されているつながりは、すぐに崩れちゃうな。CPUの命令、キャッシュ、メモリアクセスなどは、議論され、テストされ、強化され、文書化されているレベルが、最近使われているLLM生成のコードとは桁違いなんだ。基本的なコンピュータの抽象化は、そんなに漏れやすくもないし、明日リファクタリングが必要なほどでもないよ。

AIがこの状況を悪化させるだろう。私はAIに懐疑的な方だけど、この記事の結論は正しいとは思わない。LLMが私たちのためにできることは、正反対なんだ。彼らはほぼすべてのことについて訓練されているから、AIに電話がどうやって動くのか、ブラウザにURLを入力するとどうなるのかを尋ねれば、実際に答えて詳しく説明してくれる（それは論文サイズのテキストになるけど）。正確さや幻覚を除けば、電話がどう動くのか全く知らない人間よりも、はるかに優れているよ。人間の脳は「自分が知らないことを知らない」という領域にかなりのギャップがあるけど、言語モデルは非常に広範な知識を持っていて、ある意味で優れている。ただし、コストが高くて電力を大量に消費するけどね。まあ、技術的な詳細は置いといて。LLMは知識の機械で、すべてのレベルで人間の言語で説明されている限り、すべてのことについて知っているのが得意なんだ。LLMは私たちの知識を、以前は不可能だった方法で統合してくれる。推論やコード生成はあまり得意じゃないけど、ほぼ何にでも答えるのが得意なんだ。

これには多くの層があるけど、私が気になるのは一つのプログラミングスタイルだ。上の層（製品が存在する理由やシステムの目標）も下の層（実際にその動作を実装する方法）も理解していない状態。過去には多くの開発者がビジネスケースをほとんど理解していなかったけど、少なくともコードに翻訳する方法は理解していて、ビジネスに対して圧力をかけることができた。でも今は、コードがどう動くかを知っている必要すらないみたい！議論は、「それは他の誰かの心配だ」という薄い潤滑油の上で浮かんで、チケットからチケットへと幸せに滑っていくことのようだ。目標も成果も理解していない。テストがグリーンでボタンが送信されれば、ミッション完了！Claudeを使っていると、状況認識がどんどん薄れていくのを感じる。どんなコードも見なくなる開発スタイルが明らかになってきた。私の英語の指示は、何の成長も残さない。上に戻すために何も学べないし、下に何があるのかも知らない。私が存在する理由は何？

確かに私はソフトウェア開発者じゃないから、私が扱うものはもっとシンプルなことが多い。でも、「全体がどう動いているかを知っている」と認められている人たちは、その区別を得るために努力してきたと思う。必ずしも実際にどう動いているかを知っているわけじゃなくて、1. 必要に応じて調査して物事がどう動いているかを見つけ出す能力と興味がある人たち。彼らは物事がどう動いているかに興味を持っている。私の場合、数学や物理など、自分の分野の「接着剤」に関してはかなり有能だと思う。2. 知識のギャップを埋めるために必要なときに即興で答えを出せる能力があること。問題を解決するために、何が理解される必要がないかを決めることもできる。

依存関係のツリーが実際に一番厄介なところだよね。普通のNode.jsプロジェクトって、800以上の間接依存関係を引っ張ってくるんだ。それぞれが独自のリリースサイクルや破壊的変更のポリシーを持ってる。チームの誰もがその内部の動きなんて理解してないけど、それはまあいいとして、誰かが破壊的変更を出したり、APIを非推奨にしたり、サポート終了になったりすると大変だよね。anon291のインターフェースの安定性についてのコメントはその通りだと思う。CPUのマイクロアーキテクチャを理解する必要がないのは、1990年のx86命令が今でも動くから。2023年のReactコンポーネントライブラリは、次のメジャーバージョンで生き残るかわからない。インターフェースが安定していてよく文書化されているときは、「誰も全体のシステムがどう動いてるか知らない」問題は管理可能だけど、インターフェース自体が変わり続けているときは本当に危険だよね。気づいたのは、チームが自分たちの依存関係がEOLに近づいているか、バージョンに既知の脆弱性があるかを追跡すらしていないこと。知識のギャップは「これがどう動くか」だけじゃなくて、「私が依存しているものはまだアクティブにメンテナンスされているのか、そして私がスキップした過去3回のリリースで何が変わったのか？」ってことなんだ。これが毎週人々を悩ませる運用上の問題なんだよね。

これは複雑な技術の根本的な性質です：私たちのこれらのシステムに対する知識は、せいぜい部分的なものです。そう、AIはこの状況を悪化させるでしょう。でも、これは私たちが長い間直面してきた状況です。それがOKというわけではありません。これは、柱が劣化し始めた部屋に閉じ込められているようなもので、誰かがハンマーを持ってきてそれを叩き始めたときに、あなたの反応が「まあ、状況は悪いし、さらに悪化するだけだけど、屋根がまだ落ちてきてないから何もしないでおこう」って感じです。状況が耐えられないなら、正しい行動はそれを修正しようとすることであって、無視することではありません。

この記事は、どう動いているのか知らずに抽象化を使っている人々についてのものです。これは問題ない。これが進歩の方法です。でも、誰かがその抽象化を設計した（例えば、Wifiドライバ、プロセッサ、トランジスタ）ことを忘れないでください。彼らはそれが機能することを確認し、上の層にインターフェースを提供しました。完全にコーディングエージェントによって書かれたソフトウェアはただの別の抽象化だと言えるかもしれませんが、この記事はその点をあまり強調していないので、何を伝えたいのかよくわかりません。「私は自分のwifiドライバを理解していないから、自分のコードを理解する必要はない」というのは、有効な主張には聞こえません。

「ブラウザのアドレスバーにURLを入力してエンターを押すと何が起こるの？」いろんなレベル（例えば、HTTP、DNS、TCP、IPなど）で話せるけど、実際に全てのレベルを理解してる人っているのかな？ 要約すると、割り込み、802.11ax変調方式、QAM、メモリモデル、ガーベジコレクション、フィールド効果トランジスタ… まぁ、ある程度は理解できるよ。多分、俺は少数派で、いろんな職業を経てきたし、ちょっと自閉症も入ってるかも。最初のキャリアは、アメリカ海軍の潜水艦の核電子技術者/原子炉オペレーターだった。そこでの訓練では、電子理論やトラブルシューティング、修理を教わったんだけど、「これが電子だ」と始まり、「これでVMEbus [0] Motorola 68000ベースのシステムをコンポーネントレベルまでトラブルシュートできる」と終わるんだ。後にその学校に戻って教えたこともあって、68000の訓練カリキュラムをIntel 386を使うように書き直したんだ（進歩だよね？）。さらに、すべての潜水艦乗組員は資格を得る前に口頭試験を受ける必要があって、そういう質問はすごく一般的なんだ。例えば、「私は海水の一滴です。あなたのラックのライトをどうやって点けるの？」ってね。その質問に答えるためには、（記憶から）たくさんのシステムを描いて、それらをつなげて、正しいバルブ番号や電気バスを説明しながら、ボードメンバーが興味を持つような様々なトピックに深入りしていくんだ。もしどこかに書いてあったり、導き出せるものであれば、それは全て対象になる。TFAのブレンダン・グレッグの知識の限界を探る話のように、ボードメンバーはあなたが知らないことを見つけるまで止まらない。そうなったら、そのことを調べて、戻ってくる必要がある。俺がテックの世界に入った時も、この考え方を適用した。知らないことがあったら、調べる。ドキュメントを読んだり、マニュアルページを見たり、仮定をテストしたり、いじったり、実験したり。これが何年も役立ってきたし、事件やトラブルシューティングの時に、ランダムに見える知識が浮かび上がってくることもある。全部は覚えてないけど、ソースのドキュメントを見つけて記憶をリフレッシュするのには十分覚えてるよ。0: https://en.wikipedia.org/wiki/VMEbus

確かに、下のレイヤーがどう動いているか、つまりコンパイルされたコードが詳細にどう実行されるかはいつも知っているわけじゃない。でも、コンパイラを使うのに十分なメンタルモデルは持ってるし、コンパイラの作者たちがちゃんとやってることを信じてる。結果がしっかりテストされていることもね。40年以上、いろんな言語を使ってきたけど、それは素晴らしい賭けだと思ってる。でも、自分のコードがどう動くかは理解してる。下のレイヤーを理解していないことと、自分が責任を持つレイヤーを理解していないことには大きな違いがあるんだ。