塔は高くなり続ける

• バイブコーディングされたソフトウェアがランダムかつ予想外に変化していく様子は、共通言語を失って建設が止まったバベルの塔に似ているが、AI時代には理解が崩れた後も建設が続くという違いがある
• 大規模ソフトウェアの限界は、個人のコード生産速度だけでなく、概念、境界、不変条件、所有権、設計理由に関する共有された理解をどれだけうまく調整できるかにも左右される
• コード探索や質問、レビュー、チーム間の協議で発生していた摩擦は、無駄であると同時に、互いの理解を同期し、システムに対する合意を確認するプロセスでもあった
• エージェントはOAuthの追加、キャッシュ導入、データベース再構築といった作業を会話なしに並列で実行し、各変更が妥当でテストを通過していても、人間の共通モデルは弱まる可能性がある
• AI支援エンジニアリングでは、エージェントが各領域を解釈して修正し、即座の失敗なしに建設を続けるため、人間が一緒にシステムを推論していたアーキテクチャ上の言語の喪失に気づきにくい

---

バベルの塔の力は技術よりも調整にあった

• 一部のバイブコーディングされたソフトウェアが、ややランダムで予期しない形に変化していく様子は、BruegelのThe Tower of Babelを思い起こさせる
• バベルの塔の物語は、しばしば傲慢と野心、人々が互いに異なる言語を話すようになった理由として解釈されるが、同時に技術発展を可能にする団結も示している
• 創世記11章3〜6節（KJV）では、人々は石の代わりに焼いたレンガを、モルタルの代わりに瀝青を使うという技術的向上を遂げ、天に届く都市と塔を建設しようとする
• 神が問題視したのはレンガや製造知識ではなく、人々が一つであり、一つの言語を共有していて、何ものにも制約されないという点だった
• 共通の言語で各自の作業を結合すれば、誰も一人では作れないものを建設できる
• レンガや製法ではなく、互いを理解する能力が失われると調整が不可能になり、建設も中断された

AIエージェントが摩擦をなくした後も上昇し続ける塔

• AI支援プログラミングは個人により強力なツールを提供し、エージェントを使う開発者はコードベースをはるかに大きく変更できる
• しかし大規模プロジェクトの限界は、個人がコードを生産する速度だけでなく、変更対象のシステムに対する理解を人々がどれだけうまく調整するかにも左右される
• ソフトウェアプロジェクトの共通言語は、英語やPythonそのものではなく、次の要素に関する共同の理解である
  • 各概念が何を意味するのか
  • システム境界がどこにあるのか
  • どの不変条件が重要なのか
  • 誰が何を所有するのか
  • システムが現在の構造を持つようになった理由は何か
• こうした理解は一カ所に完全に記録されるものではなく、ドキュメントやコードだけでなく、コードレビュー、会話、議論、変更内容を他人に説明した経験にも蓄積される
• エージェント以前は、他人のストレージ層を変更するには、コードを読み、質問し、依存サービスを運用する別チームと協議しなければならないことが多かった
  • このプロセスには無駄もあったが、一人の理解が他者へ伝わり、双方がシステムの動作についてなお合意しているかを確認する機能もあった
  • こうした摩擦が人々の理解を同期していた
• エージェントはこうした摩擦を大きく減らし、複数の人が互いに会話せず、それぞれ異なる変更を依頼できるようにする
  • ある人はOAuthを追加し、別の人はキャッシュを入れ、さらに別の人はデータベースをゼロから再構築してUIをピンク色にできる
  • それぞれの変更は独立して妥当であり得て、コードはコンパイルされ、テストを通過し、必要であれば説明まで生成される
  • 誰も他の人と会話したり、以前なら変更過程で学んでいたはずの共有モデルの一部を習得したりしなくてよい
• エージェントは苦痛を感じず、人間だけが苦痛を感じる。そして以前なら他人の助けが必要だったシステム領域やコードベースまで変更できるようにする
• 規模が大きくなったバイブコーディングのプロジェクトは、コミュニケーションできないからではなく、コミュニケーションする必要がなくなったから、バベルの塔のようなコードベースになる
  • 各開発者には、塔の特定領域を説明し、望む局所的な変更を実行する、疲れを知らない翻訳者がいる
  • 変更は反映され続けるが、人間たちが一緒にシステムを推論できるようにしていたアーキテクチャ上の言語は失われる可能性がある
• 聖書のバベルの塔では共通言語の喪失が工事を止めたが、AI支援エンジニアリングでは共有された理解が崩壊した後も建設が続く可能性がある
• 塔が崩れたり即座に失敗が発生したりしないため、何を失ったのかに気づきにくく、塔は高くなり続ける

[GN⁺]

Hacker News の意見

• ソフトウェアの合成可能性は、テトリスのように列が消えていくべきだと、ずいぶん前から考えてきた。未熟にエージェントを使ったり、経験の浅いエンジニアは、こうした整理を見落として塔だけをどんどん高くしがちだ。
  エージェントに既存の要素をより良い抽象化へと繰り返し統合させることはできるが、Fable や 5.6 Sol でさえ、ソフトウェアの微妙な進化を予測する高次のアーキテクチャ感覚では、まだ人間に大きく遅れている。現在のシステムは、人間が扱うような高品質で希少かつズーム可能な世界モデルを十分に維持できていないように見えるが、いまや差がこうした微妙な水準にまで縮まっているという事実自体は希望が持てる。

  • 証明はできないが、将来の変更を考慮した抽象化に必要な論理と直感は、予測トークンの連続だけでは実装できないと強く信じている。測定できない何かが欠けている。
  • かつては人間の精神の能力がプログラム複雑性の上限だったが、バイブコーディングはその壁を突破できる。問題が実際にそれほど複雑だからではなく、開発プロセスが簡潔な抽象化へ収束しないからだ。
    これは Brooks が『The Mythical Man-Month』で扱ったスケーリング問題の AI 版であり、規模が大きくなるほど組み合わせ爆発が悪化し、プロジェクトのあちこちに実質的に同じ機能を実装したコードが重複して生まれる。AI ベースのコーディングに簡潔性を追求させる方法が必要だ。
  • 人間のコンテキストウィンドウは、現在の LLM よりはるかに小さいかもしれない。この制約は、作業を頭の中に収められるようモジュール化し抽象化させる利点になるが、はるかに多くの内容を一度に抱えられる LLM には同じ誘因がなく、エージェントが整理されていないスパゲッティコードを作ることになる。
  • 結局は時間の問題だ。gpt2 や llama2 は現在のモデルと比べると衝撃的なほど出来が悪く、当時も実質的には役に立たなかったが、私たちは感嘆していた。
    かつて熱狂された GPT3.5 と gpt4 も、いまでは qwen27b や gemma31b に大きく後れを取っている。十分な時間と適切な**強化学習（RL）**が与えられれば、モデルも優れたソフトウェアシステムのモデルを頭の中に構築するようになるだろう。
  • LLM が短い時間範囲の課題を解くよう強化学習された結果ではないだろうか。テストを通す課題と違い、何年にもわたる努力、きれいなアーキテクチャ、良い感覚は、ベンチマークで最大化するのが簡単ではない。

• この記事の中心的な論旨は、Lisp Curse と Bipolar Lisp Programmer を思い起こさせる。Lisp は個人が欲しいものをあまりにも簡単に作れるため、プログラマーが協力して汎用的で複雑な成果物を構築する動機が弱まり、相当な努力を要する言語よりも公開ソフトウェアのエコシステムが貧弱になる、という論理だった。
  Armin も AI コーディングについて非常によく似た論旨を展開しているように見える: Lisp Curse, Bipolar Lisp Programmer

  • アセンブリプログラマーたちも同じ論理を唱えていた。ソフトウェア工学がパラダイムシフトを経験するたびに繰り返される通念であり、移行に他の人より苦労する人もいる。
  • 本当に同じ論理なのかは疑問だ。今では、集まって協業する必要はなく、エージェントの群れさえ動員すれば、想像するどんな複雑なソフトウェアでも作れると見る人も十分に多い。
  • むしろ TypeScript と Rust が市場を席巻していなければ、今はLisp 用 LLM 操縦者になるのに良い時期だっただろう。最近のエージェントはほとんど幻覚なしに大部分を説明できるので、理解しようという意志さえあれば理解の壁は事実上なくなり、これこそが記事の核心でもある。
  • 他の言語が同じ結果を出すために「はるかに多くの努力」を要求するという前提は明確ではない。多くの非 Lisp 開発者は構文を重視するが、Lisp 開発者はそうではなく、Lisp によって思考が拡張される体験をした後でも Lisp を好まない人は多い。
    両者の間には異なる認知処理方式があるのかもしれない。Lisp が他の言語と同じくらい生産的であるためには同像性（homoiconicity）を積極的に活用する必要があるが、その結果、本格的な Lisp プログラムは、1人か2人しか理解できない**ドメイン固有言語（DSL）**の集合になりがちだ。

• 大規模ソフトウェアプロジェクトの限界は、個人がどれだけ速くコードを生産できるかではなく、システムを変更する人々がそのシステムについての共通理解をどれだけうまく調整できるかにある。2022年11月30日以降、すべてがより複雑になったというのは正確だ

  • ソフトウェアはレイヤーの上にレイヤーを積み重ねて過度に複雑になっており、それに対処しようとして、さらに多くの複雑さを生むツールを使っている。1990年代から2000年代初頭には、正式な教育がなくても Visual Basic や PHP で強力なアプリケーションを作れたが、今日の Web やデスクトップ開発は圧倒的に複雑で、React でさえきちんと使うには知るべきことが多すぎる
    ここに AI を導入するのは、既存の複雑さの上にさらに別の複雑さを載せる過ちに近い。よく見ても膨大なハードウェアの浪費であり、悪く見れば、エージェントがバグを直すのと同じだけ新しいバグを作り、脆弱なゴミのようなソフトウェアが増える一方で、人々が技術を学ばなくなり、人類全体の能力が弱まる可能性がある。ソフトウェアは本質的にここまで複雑である必要はなく、解決するにはクラフトマンシップを重視すべきだ
  • システムを変える前に理解しなければならないという事実は新しくない。Peter Naur の Programming as Theory Building はすでに1980年代に出ていたし、それを読んでいなくても、熟練した開発者の間ではシステム理解が必須だというのは常識だった
  • すべてがより複雑になったわけではない。主要なデータベースには実用的な高可用性ツールが含まれるようになり、マイクロサービスは後退し、NoSQL の代わりに構造化データベースが戻ってきている
    HTML と事前レンダリングも HTMx、LiveView とともに復権し、CSS も過去の奇妙な回避策から脱した。IE6 で Web ページをデバッグしていた方法を若い同僚に説明すると、隔世の感がある。複雑になった部分もあるが、別の部分は十分に成熟して、より単純になった
  • 「2022年11月30日以降」ではなく、紀元前2022年以降すべてがより複雑になったと言うべきだ。複雑性の増大こそが人類文明史である
    紀元前2万年の人は食べ物を探し、寒さと捕食者を避けていたが、紀元前5千年の人は農耕を行い、雨や病気を心配し、共同体と土地を管理する仕組みを作った。今日では大半の人が食料を自分で栽培せず、巨大な社会の複雑性を管理している。1970〜80年代の開発者から見れば、LLM 以前のソフトウェアでさえ途方もなく複雑であり、今では抽象化レイヤーなしにハードウェアへ直接コーディングする人はほとんどいない。暗号化でもライブラリが複雑さを隠し、「自分で実装するな」と教える。今や核心的な問いは、LLM が変更対象システムについての理解をどれだけ速く調整できるかである

• ソフトウェアプロジェクトの共有言語は、英語でも Python でもなく、概念の意味、境界、不変条件、所有権、そしてシステムが現在の形になった理由についての共通理解である。Christopher Alexander の Pattern Language はまさにこの問題を扱っており、各ドメインに合ったパターン言語を作るよう勧めたことが、有名な GoF Design Patterns につながった
  プロジェクトごとに、ビジネス・プロダクト・技術ドメイン向けの3つのパターン言語を AI に維持させる機能を実験しているが、非常にうまく機能している。計画時にそれを参照し、実装とレビュー中に整理させると、100% AI でコーディングしたプロジェクトでも体系的で、ドメイン間の整合が取れており、扱いやすくなった

  • 実際の例が気になる。コードの成熟過程が都市の自然な成長に似ているという話は何度も聞いたが、具体的な結果は見たことがない
  • 公開されている GitHub の例があるのか気になる

• バベルの塔では共通言語を失うと建設が止まるが、AI 支援開発では共有された理解が崩れた後も建設が続く。筆者は良し悪しを明示していないが、明らかに悪いことだと見ている
  トマトが果物であることを知るのが知性で、フルーツサラダに入れないのが知恵だとすれば、AI は知恵がまったくない知性の究極形であり、実質的には知性の幻想に近い。AI が何をしているのか理解する人が誰もいないなら、立ち止まり、自分たちが作っているものを制御するための知恵が不足していることを認めるべきだ

  • 筆者が説教する代わりに、画像そのものに意味を伝えさせている点がよい。歴史にまったく同じ繰り返しはないが、常に韻は踏む
  • 「トマトが果物であることを知るのが知性」のような幼稚な決まり文句は、ミスリードが目的でないなら避けたほうがよい。分類と依存関係の理解だけでも十分に難しい問題であり、スーパーマーケットや Nix v. Hedden の課税基準ではトマトは野菜である

• 私もバベルと Bruegel の絵を思い浮かべるが、はるかに悲観的に見ている。近視眼的な小さなエージェントたちが、知りようもないほど巨大な全体の各自の領域を開発し、一方には胸壁が50個あり、もう一方には奇妙に突き出した塔があり、理由も分からないまま中庭の上にはアドビの屋根、その隣の踊り場には茅葺き屋根の付いた塔を建てているような姿だ
  個別の設計レベルでは妥当でも、事業全体を統合する複数レイヤーの方針と判断がないため、設計の巨大な怪物になる。十分に大きな組織で共通言語を作り維持するには規律が必要だという事実は、成功した企業や軍隊の独特な用語にも表れている。「Gastown Mayors」とその下の「polecats」、さらに下のゴーレムまで同じ言語を使っていると思っていても、すべてが完成した後で初めて、王座から完璧に伝えたと信じていた理解が実際には共有されていなかったことに気づくのだろう

• Anakin: 「エージェントを使う開発者は、コードベースを変える能力が劇的に高まるはずだ」
  Padmé: 「より良い方向に、だよね？」
  Anakin: 沈黙
  Padmé: 「より良い方向に、だよね？」

• バイブコーディングが生成されたコードを読むなと言う理由は、Python ファイルの中に潜む恐怖を一度見ると忘れられないからのようだ。広い意味では要求どおりに動くが、目的を達成する方法を選ぶたびに一貫性のない判断を下す
  一部のユーザー入力にだけ奇妙な検証を適用し、理由もなく3つの段階でデータを繰り返しソートしたり小文字化したりし、入力 CSV の先頭行にある列名まですべて文字列としてハードコードする。半分はデータクラスを受け取るグローバル関数を作り、残りはクラスとして実装する、といった具合だ。いつか自分で更新し保守しなければならないと考えると、これを直さずにはいられないが、そうやって修正しているうちに、節約した時間のかなりの部分が消えてしまう

• エージェントベースのプログラミングは、実際のプログラミングよりも管理業務にはるかに近い。管理者は個々の貢献者がしていることを高いレベルでしか把握しておらず、すべての詳細を理解する時間・認知的余裕・能力がない場合も多い
  エージェントによって書かれるソフトウェアが増えるほど、ソフトウェアエンジニアの役割は技術職よりも管理職に近づいていくだろう

  • プログラマーも同じである。ほとんどの個々の貢献者は、自分が作業している層の下で何が起きているのかを知らず、ライブラリ・フレームワーク・リモート API・システムコールの内部実装まで把握していない
    すべてを理解する時間と余裕がないため、抽象化された自分の層で必要な作業を行っているだけである
  • 一日中ジュニア開発者のコードをレビューしているような感覚なのでほとんど使っておらず、主に自分が見落とした部分を見つける用途でのみ使っている

• かつては大規模なリファクタリングには大きな労力がかかるため、十分な理由が必要だった。今ではプロンプトが少し曖昧で、結果をきちんとレビューしなければ、エージェントがコードの半分を書き直すこともあり、プログラムの魂が毎日大きく変わり得る。素晴らしいことでもあり、同時にまったくそうではないことでもある

  • 大規模リファクタリングの最大の障壁は、もともと作業量ではなく、バグリスクの最小化、機能の維持、既存エコシステムとの互換性の保証だった。AI 時代にそれが容易になった理由は、私たちがこうしたことをもはや気にしなくなったからである