コードの死に関する報告は大げさである

45日前原文(stevekrouse.com)

概要

英語仕様の曖昧さと現実の複雑さのギャップ
AIによる「vibe coding」とその限界
抽象化による複雑性の克服
AGI時代のコーディングの未来
コードの価値とAI時代における意義

英語仕様の限界と「vibe coding」の幻想

英語仕様 は直感的に正確に思えるが、実際には 曖昧さ が多い現実
Bertrand Russell の「全ては、正確にしようとするまで曖昧である」という言葉の引用
プログラミング も文章執筆も、試行錯誤で精度を高める活動
AI は英語から 即座にコード生成 できるため、反応しながら要求を明確化できる
「vibe coding」 は英語レベルの感覚で進めるが、抽象化の漏れがバグとして現れる危険
- Dan Shipperの事例： vibe coding で作ったエディタがバイラル化後にダウン
「ライブコラボレーション」 は一見明確な仕様に思えるが、実装は非常に難解
- 過去の経験からも、 複雑性 と エッジケース の記憶困難さを実感

抽象化と複雑性の克服

人間の脳 には同時に扱える情報量の限界（7±2個）が存在
複数の情報を一つに圧縮することで、無限の複雑性を制御
- この圧縮作業が 抽象化
抽象化 の目的は曖昧さではなく、新たな 精密な意味レベル の創出
- Edsger Dijkstraの名言
Slack の通知フロー図をSophie Alpertが抽象化してシンプル化した事例
プログラミングの醍醐味は、 優れた抽象化 を発明し複雑性を乗り越えること
- 関数型リアクティブプログラミング などの例

AGI時代とコードの未来

AI の進歩により、いずれ AGI （汎用人工知能）に到達するのは時間の問題
AGI時代には「vibe world」になると誤解されがち
- 例：Karpathyレベルの天才AIを大量に安価で雇える世界
しかし、 コード は単なる成果物ではなく、 重要なアーティファクト
- 良いコードは詩のような価値を持つ
文章執筆とコーディング のアナロジー
- 「vibe writing」という概念が存在しないのと同様、コーディングも本質的にクリエイティブ
AGI登場後は、 最も困難な抽象化問題 の解決にAIを活用
- より良い抽象化やライブラリの創出
Val Town でのAI活用事例：React Router 7の全スタック対応をAIが一発解決

コードの価値とAI時代の誤解

「コードは死んだ」との世間の認識は誤り
- Sam Harrisの発言例
- 印刷機発明で「物語が死んだ」と考えるのと同じ誤解
AIはコーディングを加速させる恩恵
コードはこれからが本番

形式主義と抽象化に関する名言集

Edsger Dijkstra ：「形式記号の使用は負担でなく特権」
Tony Hoare ：「ソフトウェア設計には二つの方法がある。明らかに欠陥のないほど単純にするか、明らかに欠陥が見えないほど複雑にするか」
Charles Babbage ：「代数記号による意味の圧縮が推論を容易にする」

Hackerたちの意見

チャットボットのコーディングの世界で、どうやって新しい技術に進化していくんだろう？AIはたくさんの人の過去の作品を学習してるけど、新しい言語やフレームワークみたいに前例がないと、AIモデルは苦労するよね。開発者が十分にいないと、必要な新しいトレーニングデータはどうやって生まれるんだろう？

└

それは事実と違うよ。ほとんど前例がないフレームワークで作業するためにモデルを使ってるし、誰もやったことのないことをやってるんだ。これを知ってるのは、これらの若いフレームワークの周りのエコシステムにいるから。モデルはマニュアルを読んだり（コードも）して、新しいことをやることができるよ、実際にね。

└

既存のアートを（どんどん増えていく）コンテキストウィンドウに注入して、インコンテキスト学習に任せて進めばいいんじゃない？

└

ほとんどのアートフォームは、材料やメディアの急激な変化がないんだよね。ソフトウェアでは、ツールの変化が遅くなってきてる。コンピュータが提供する価値がより明確になってきて、特定の技術に依存しなくなってきたから。AIコーディングがあれば、NIH症候群から解放されて、リレーショナルデータベースを10回目に再発明することもなくなるかも。

└

今、みんなこれをやってるよ。基本的に、skills.shとかその類のものがそのためにあるんだ。AIに新しいことを教えるためにね。例えば、うちの会社が新しいフレームワークを作って、そのエージェントに向けられるスキルがあるんだ。そのスキルを使えば、かなり複雑なコードを一発で書けるようになる。スキル自体は、ほぼドキュメントといくつかのコード例だけなんだけどね。

└

これは、LLMから見えないところで新しいプログラミング言語を設計する必要があるってことでもあるね。コードを隠す必要があるかもしれないから。

└

チャットボットのコーディングの世界で、どうやって新しい技術に進化していくんだろう？面白いことに、伝統的なプログラミングについても同じことが言えると思う。1972年のベル研究所のK&Rのグループの誰かが、僕の日常のワークフローを認識するのに問題はないだろう。テキストエディタを立ち上げて、Cコードを編集して、コンパイルして、実行する。それを手作業で繰り返す。これっておかしいよね。50年以上も同じことを同じやり方でやってきた業界が進化するはずがない。そろそろ本当のパラダイムシフトの時だと思うし、今まさにそれが起きてる。これから書かれるべきコードはもう全部書かれてるんだ。あとはリファクタリングして、再編成して、再利用するだけ。それはロボットの仕事だよ。

└

もしかしたら、君は現代のLLMについて正しいかもしれない。でも、君は暗黙の前提を置いているように思える。「人間には新しいものを作る特別な何かがあって、コンピュータにはそれがない」という前提だね。今のLLMを支えるシステムに新しいトリックを教えられないかもしれない。でも、すべてのAIシステムが新しい技術を合成できないと信じる理由はあるの？この点で人間が特別だと信じる理由は何なの？

└

LLM自体にドキュメントをもとに生成させることもできるよ。まるで人間の初期採用者みたいにね。

└

人についても同じことが言えるね。答えは社会的知性だよ。

└

「もっと大きな問題があるんだよね。AIが君のフレームワークを見てなかったら、君は存在しないってこと。もうすぐAI企業が、開発者からお金を取って、自社のフレームワークをトレーニングデータセットに含めるように頼むようになるよ。GoogleのSEOよりもひどいよ、あれはまだ多少はゲームできたから。」

社会の知的才能がソフトウェアに偏りすぎてる気がする。頭のいい人たちの多くが広告技術や監視、隣人からできるだけ注意を引き出すことに取り組んでる。今の技術者の配置は市場の失敗かもしれないし、コーディングの disruption が再配置のきっかけになるかもね。

└

それはビジネスの目標で、テクノロジーが変わったからって簡単には消えないよ。

Swiftプログラミング言語の発明者クリス・ラトナーが、クロードAIによって完全に書かれたコンパイラを見てみたんだけど、AIが生成したコードには何の革新も見つからなかったんだって。だからこそ、最先端を進めるには人間が必要なんだ。AIは従来の知恵を受け入れがちだから、本当の批判的思考には苦労するし、独自に最先端を進めることができない。AIシステムは膨大な人間の成果をもとに学習して、既存の考えの中心に近い答えを生成する。人間は時々、従来の知恵に疑問を持つことがあるけど、AIは自分からそういうことはしない。コンセンサスに合わせることはできても、それに挑戦することはできない。だから、独自に知識を前進させることはできないんだ。人間はAIの助けを借りて革新できるけど、AIはまだ人間の指示が必要なんだよ。AIシステムに批判的に考えるよう促すことはできるけど、結局平均に戻っちゃう。会話がコンセンサスから離れると、システムが安全な中間に戻ろうとするのが感じられる。90年代後半のAppleの「Think Different」キャンペーンが言ってたように、世界を変えられると思ってる人たちが実際に変えるんだよね。変わり者や反逆者、トラブルメーカー、四角い穴に丸い棒を入れようとする人たち、物事を違った視点で見る人たち。AIはそういう存在じゃない。AIはコンフォーミストなんだ。それが強みでもあり、弱みでもある。

└

...既存の考えの中心に近い答えを生成する。これはウィキペディアの普遍近似定理の記事にも書いてあるね。「機械学習の分野では、普遍近似定理（UAT）は、特定の構造を持つニューラルネットワークが原則として任意の連続関数を任意の精度で近似できることを示している。この定理は、ニューラルネットワークを使用するための数学的な正当性を提供し、十分に大きいまたは深いネットワークが現実のデータにしばしば見られる複雑で非線形な関係をモデル化できることを研究者に保証する。」そして、「ニューラルネットワークは、コンパクトな集合K内で近似することが求められることにも注意してほしい。証明は、関数がその領域の外でどのように外挿されるかを説明していない。」NNやLLMも含めて、彼らは補間者であって外挿者ではない。NNが近似する領域はかなり複雑で、「X:R^N drawn from N(c,s)^N」と簡単には定義できないことがSolidGoldMagiKarpが示している。

└

その記事は結構まともな意見だと思う。>CCCは、AIシステムが特定の分野の教科書的知識を内面化し、それを一貫してスケールで適用できることを示している。AIは今や確立されたエンジニアリングの実践の中で信頼性を持って動作できる。これは、繰り返しの面倒を大幅に取り除き、エンジニアが最先端に近いところから始められるようにする本当のマイルストーンだ。そして、> 最も効果的なエンジニアは、AIとコードを生産することで競争するのではなく、AIを使ってアイデアをより早く探求し、より広く反復し、人間の努力を方向性とデザインに集中させることを学ぶだろう。実装の障壁が低くなることはエンジニアの重要性を減少させるわけではなく、むしろビジョン、判断、センスの重要性を高める。創造が容易になると、何を創造する価値があるかを決めることが難しくなる。AIは実行を加速するけど、意味、方向性、責任は根本的に人間のものなんだ。

└

この話題、数日前にHNに載ってた気がする。

└

AIは従来の知恵を受け入れがちだ。だから、真の批判的思考が苦手で、独自に技術の最前線を進めることができない。もちろん！でも、それが彼らを強力にしてるんだよ。99%のケースでは、従来のものが欲しいからね。AIはエージェンシーを持っていれば新しいことを考え出すこともできるし、自分で学ぶこともできる（例えばRLを使って）。でも、ほとんどの使い方ではそれを望んでない。予測不可能だからね。代わりにツールが欲しいんだ。この創造性の欠如が知性や批判的思考の欠如を意味するわけじゃない。AIは明らかに、求められれば推論や批判ができる。概念的には、AIシステムのブレークスルー（特にコーディングにおいて、他の分野でもある程度真実）は、あいまいで潜在的に矛盾するアイデアを取り入れ、トレーニングデータから矛盾の少ない部分を見つけて、機能する、とはいえ従来の実装を作り出す能力にある。強みは、どの矛盾を取り除くかの直感にあるんだ。（人間の思考の誤り訂正コードみたいに考えられる。）例えば、AIに「赤い線を7本、直交させて、青いインクで、いくつかは透明に描いて」と頼むと、これらの制約から矛盾を取り除く解決策を見つけたり、ドメインを尋ねたりして、どの矛盾した表現を捨てるか決められる。実際にクラウドに試してみたら、素晴らしい答えが返ってきたよ。「創造性には感謝しますが、このリクエストにはいくつかの幾何学的（および色彩的）な不可能性が含まれているようです：[..] だから、このリクエストを忠実に実行するには、ゼロ本の線を描く必要があります — これが唯一の正直な答えです。」これはもちろん、Vihartのクラシックなコメディスケッチ「七本の赤い線」のジョークへのオマージュだ。そこでコンサルタントがこの不可能な仕様を見事に受け入れるというもの。クライアントが時々論理的または物理的に無意味なことを要求することがあること、そして人々が時々それを受け入れてしまうことを完璧に風刺している。実際に描けるものを描いてほしいですか？

└

だから、技術の最前線を進めるには人間が必要なんだ。どれくらいのパーセンテージの開発者が技術の最前線を進めているのか、どれくらいのパーセンテージのジュニアがそれを進めているのか？

└

スウィフトプログラミング言語の発明者クリス・ラトナーが最近、クラウドAIが完全に書いたコンパイラを見たんだけど、ラトナーはAIが生成したコードに革新性は何も見つけられなかったんだって[1]。だから、技術の最前線を進めるには人間が必要なんだ。「技術の最前線を進めるために必要」と「実際にそれをするために配置される」は別のことだからね。おそらくAIが自ら技術の最前線を進めるようになるか、もしくは技術の最前線があまり進まなくなるかのどちらかだろうね…。

└

ラトナーはAIが生成したコードに革新性を見出さなかった。置き換えは単純な二者択一ではないと思う。むしろ、スペクトラムだ。多くのソフトウェアエンジニアが心配しているのは、AIが需要を減らして、業界が供給過多になるかどうかだ。それは経済の問題で、私たちには解決すべき新しいビジネスの問題が十分にあるのか？もしあるなら、AIは私たちを助けるけど、置き換えることはない。もしないなら、結局は無駄な仕事をたくさんすることになるから、多くの人が職を失うことになるだろう。AIがあってもなくてもね。

└

LLMが一番助けてくれるのは、いろんなシステムを統合する時なんだよね。それぞれにドキュメントがあって、2、3のシステムを自分のシステムと正しいOAuthスコープやSAMLで統合するのに何時間もかける代わりに、LLMが短時間で動く統合を作ってくれる。これって革新的なことじゃないし、エンジニアとしてドキュメントを読み込んで、欠けている部分を推測する根気の勝負なんだ。LLMはその部分が得意なんだよね。あとはAIと自分の考えを話し合う時間を使ってる。いわゆるデバッグ用のゴムダックみたいな感じだけど、結構考えさせられる返事をくれるんだ。そういう時は、コードを書く量は減るけど、不変量や期待される失敗モード、漏れた抽象を見つけることに集中してる。そしたら、コードを書いたり、見たいものについて良い指示を出したりできる。そうすれば実現してくれる。実際、非実践者がこれらの会話を特定の複雑さを超えてできるかは分からないな。

└

でも強化学習がこれを変えるんだよね。37手を覚えてる？問題は、それには検証可能な報酬が必要で（良い環境設定もね）、人間が求めるすべてをカバーする報酬を得るのは難しいってこと（セキュリティ、シンプルさ、パフォーマンス、可読性など）。

└

クリス・ラトナー、Swiftプログラミング言語の発明者が最近、クロードAIによって完全に書かれたコンパイラを見た。ラトナーはAIが生成したコードに革新性を見出さなかった[1]。だからこそ、人間が最先端を進める必要があるんだ。プログラミング言語のアイデアを持っている人はたくさんいるけど、そのアイデアがオリジナルなものもあれば、実際に実装するための時間やスキル、モチベーションが足りない人も多い。もしAIがアイデアから実装までの道のりを楽にしてくれるなら、元々のアイデアが人間から来ていても、私たちはこれまでよりもずっと早く進歩できるかもしれない。

一週間前に、ドナルド・クヌースがAIに何か未証明のことを証明させたっていう記事を見たんだけど、AIがその証明を見つけたんだよね。クヌースがその既存の真実を見つけられなかった可能性もあるけど、みんなが疑った理由があるんだよ（私もそこで言ったけど）。私はCコンパイラを書いたことがないけど、もしお金をもらったら書くって賭けてもいい。少なくとも数年はかかるだろうけど、革新的なものは何もないと思う。もうこの分野は十分にカバーされてるからね。私が他のコンパイラと違うのは、コンパイラを書く方法を知ってる人がしないような愚かなことをした可能性が高い。

└

"もうこの分野は十分にカバーされてる" 1899年にアメリカの特許コミッショナーは「発明できるものはすべて発明された」と言って特許庁を閉鎖したがってた。でも、人間の創意工夫はそれとは逆のことを証明し続けてるよね。

└

たぶん数日でできると思うよ。Cはそんなに難しくないから。

└

だから、どうやって証明を見つけたのか知りたいな。おそらく、著者が特別だと気づいていないような obscure な記録から引っ張ってきた可能性が高いと思う。これがLLMを非常に強力な研究ツールにしていて、出現する能力の錯覚を生み出すんだ。

クラウスはサイモン・ウィリソンの素晴らしい記事を指摘してる。ウィリソンは、バイブコーディングの重要な役割は、単に速くするだけじゃなくて、コードをより良くすることだと提案してるんだ。異なるデザインモデルに基づいたプロトタイプを生成することで、最終的な製品はコードの可読性、信頼性、耐障害性などの特定の基準で評価できて、これらの目的に合わせて迅速に修正できるようになる。もはやバイブコーディングの勝利のダンスは「動いた！」とか「こんなに早く作った！」だけじゃなくなるんだ。

└

これが私の希望でもある。今はもう少し良いものを書く時間があるから。PRに簡単な改善をコメントすれば、それが実現することもある。でも、職場で人を納得させるのが難しいんだ。大多数は、コードが消えて二度と考えなくて済むことに満足しているみたい。

新しい技術が登場すると、必ず超ワクワクするフェーズを経るのは避けられないよね。極限まで使おうとして、その過程で実際に何ができるのか、何ができないのかを理解していく。ハイプサイクルは確かに嫌なものだけど、これが人間の物事の理解の仕方だと受け入れたよ。子供のように、正しく使う方法を学ぶ前に、まずは使い倒す必要があるんだ。多くの人が、エージェントプログラミングの約束があまりにも良すぎると感じていると思う。プログラマーやエンジニアとしての経験からね。でも、専門家は常に少数派だから、他の人たちも同じ直感にたどり着くのは大変だってことを理解しなきゃ。

プログラミング言語は自然言語よりも意図をより良く（密度が高く、正確に）カプセル化できることには同意するけど、逆のことが多いと思う。自然言語の方がプログラミング言語よりも意図を密度高く、正確にカプセル化できることが多いんだ。ラッセルの引用をこう使うのはちょっと皮肉だと思う。私の意図は、機械の実行コンテキストに縛られた言語にエンコードされると、読者にはあまり明確じゃなくなることが多い。良い抽象化はこのミスマッチを意味のある形で解消してくれるし、強力な言語（ML系やLisp系の言語）のDSLはしばしば自然（っぽい）言語を反映している。プログラミング言語自体も、実装よりも意味的に密度が高い自然言語の仕様を持っていて、しばしば複数の実装を支配している。コードは単なるコードじゃない。一部のコードは意図を意味的に情報密度の高い形でカプセル化している。それは確かに詩であり、意図を表現する最良の方法かもしれない。サーバーとクライアントの時間の例のほとんどのコードは実装の詳細に過ぎない。Electric Clojureのバージョンは意図をより良くカプセル化している（https://electric.hyperfiddle.net/fiddle/electric-tutorial.tw...）。自然言語のバージョンは、既存のクライアントサーバーアーキテクチャのプログラムの文脈で実行されると、最適だと思う。「サーバーのUnixエポックタイムスタンプとクライアントのをライブで更新して表示し、その下にそれらの間のずれを表示する。」ラッセルから始まったから、ウィトゲンシュタインの「ぼやけた絵を鮮明なものに置き換えることが常に利点になるのか？ぼやけた絵が必要なことも多いのでは？」で締めくくることができるね。

└

同意見だと思う。私のダイクストラの引用は、君のウィトゲンシュタインに対する完璧な返答だよ。「抽象化の目的は曖昧さを持つことではなく、絶対に正確である新しい意味のレベルを作ることだ。」— エドスガー・ダイクストラ

「インテグレーショングルーのコメント、めっちゃ共感するわ。俺は主にOAuthフローやAPIの統合にエージェントを使ってるんだけど、そういうのってクリエイティブな要素が全然ないんだよね。3つのドキュメントを読んでトークンを正しく設定するだけ。昔は嫌だった作業が、今は何時間も節約できるようになった。でも、実際のアーキテクチャの決定とかトレードオフを考えなきゃいけない瞬間には、また自分の頭に戻る感じ。しばらくはそんな感じで落ち着くと思う。」

「AIがすぐに俺の代わりになるとは思ってないけど… AIのおかげで、使う言語にあまりこだわらなくなって、アルゴリズムにもっと集中できるようになった。AIはテストを書くのを手伝ってくれるし、改善案を提案してくれたり、コンパイル前にバグを見つけてくれる。AIがヘルパースクリプトやツールを作ってくれるから、毎月数百ドル払う価値はあると思ってる。まあ、実際は雇い主がそれを払ってくれてるから、俺は払わなくてもいいんだけど。6ヶ月前は、AIはあまり良くないし、コードは解決策を指定するのに英語よりも正確だって主張してたんだ。でも、その最初の部分はもう多くのことに関しては真実じゃなくなった。後者はまだ正しいけど、気にしてることに関してはあまり関係ない。AIについて何を考えるべきか教えようとする記事にはうんざりしてる。「AIは素晴らしくて、全てのプログラマーを置き換える！」…「AIはクソで、君の脳とコードベースを台無しにする！」…どちらももう飽き飽きしたし、意味のない議論だよ。」

「新しいタイプのCRDTを作ってるんだけど、木構造内での移動・再配置・削除操作をトゥームストーンなしでサポートしてるんだ。Claude Codeはコードを書くのが得意なんだけど、削除操作にトゥームストーンを戻しちゃうんだよね。「研究にはトゥームストーンが必要だから正確性が求められる」って。通常のアプローチではそうだけど、俺がCRDTを書く理由はそのトゥームストーンを避けるためなんだよね！とにかく、長い話を短くすると、最終的にはClaudeを納得させたけど、そのために構造的な証明を書かなきゃいけなかった。すべてのケースで明確な順序と前進を示すためにね。それでも圧縮がそれをリセットしがちなんだ。こういうシステムには、まだまだ足りないサブタイトルがたくさんあるよ。」

ハクソク