塔は高くそびえ続ける

2026年7月15日原文(lucumr.pocoo.org)

概要

AI支援型開発 によるコード変更の予測困難化
Bruegelの「バベルの塔」 との比較による組織的連携の重要性
ソフトウェア開発における 共有言語 の喪失リスク
エージェント導入 による摩擦減少とその副作用
建設が止まらない新しい「バベルの塔」現象の考察

AI支援型開発とバベルの塔

vibecodedソフトウェア の変更が ランダムかつ予期せず 発生する体験
Bruegelの「バベルの塔」 の混沌とした描写との連想
旧約聖書のバベルの塔物語は 誇りと野望、そして 言語の分断 の由来として語られる
しかし同時に 技術進歩の源泉 としての団結の物語でもある
- 人々は レンガ製造技術 を共有し、 都市と塔 の建設に挑戦
- 神が問題視したのは 共通言語による協調 であり、レンガ自体ではない
連携の力 が巨大プロジェクトを可能にする根源

ソフトウェア開発における共有言語

ソフトウェア開発では 英語やPython ではなく プロジェクト固有の共有理解 が言語となる
- 概念の意味、境界、重要な不変条件、責任範囲、システム構造の理由など
この 共有言語 はドキュメントやコードだけでなく、 コードレビューや会話、経験 にも宿る
以前は摩擦が共有理解の維持に寄与
- 他人のコードを読む、質問する、他チームと調整する等の遅さが時に必要な同期を生む

AIエージェント導入の影響

AIエージェント によって摩擦が大幅に減少
- OAuth追加、キャッシュ導入、UI変更などが 個別に自動実装可能
- 各変更は 独立して合理的、テストもパス、説明も自動生成
しかし 人同士の対話や共有モデルの獲得 が不要となり、 全体像の共有理解が希薄化
エージェントは痛みを感じず、人間だけが痛みを感じる
エージェントの導入で 人の介在が不要な領域 が拡大し、 コードベースのバベル化 が進行

新しい「バベルの塔」現象

大規模プロジェクトで 誰もが自分の翻訳者（AI） を持ち、局所的変更が容易
人間同士の建築言語 が消失しつつも、 建設自体は止まらない
旧約のバベルでは 言語喪失＝建設停止 だったが、 AI支援開発では喪失後も建設継続
即時的な失敗が起きない ため、何が失われているか気付きにくい
塔は崩れず、ただ高くなり続ける 現象

結論

AIエージェント による効率化は 個人の生産性 を飛躍的に高める
しかし 共有理解の希薄化 という副作用が 長期的なリスク となる可能性
摩擦や同期 の意義を再考し、 持続可能な協調 のあり方を模索する必要

Hackerたちの意見

昔は、大規模なリファクタリングをするには良い理由が必要だったんだよね。だって、めっちゃ大変だから。でも今は、エージェントが君のコードの半分を、君のプロンプトが曖昧すぎるときに書き換えちゃう。全部をちゃんと見直そうとしなければ、プログラムの「魂」が毎日劇的に変わることもある。いい面もあれば、そうじゃない面もあるよね。

└

大規模なリファクタリングの最大の障害は、バグのリスクを最小限に抑え、機能を失わず、既存のエコシステムとの互換性を確保することだった。AIの時代になってこれが簡単になった理由は、私たちがこれらのことを気にしなくなったからだ。

AI支援のプログラミングは、より良いツールを意味していて、もっと野心的なソフトウェアを作れるようになるっていう魅力的なアイデアがあるよね。これは個人レベルでは確かにそうで、エージェントを使う開発者はコードベースを劇的に変える能力が高まることは間違いない。でも、大規模なソフトウェアプロジェクトは、個人がどれだけ早くコードを生産できるかだけで制限されているわけじゃない。人々が変更しているシステムの理解をどれだけうまく調整できるかが重要なんだよね。本当にそう思う。2022年11月30日以降、すべてが…もっと複雑になった。

└

わからないな。いくつかのことは減ったけど、主要なデータベースは今や効果的なHAツールを提供しているし、マイクロサービスは廃れつつあるみたい。構造化データベースがNoSQLの代わりに戻ってきた感じ。HTMLやプレレンダリングも復活してるし、HTMxやライブビューもね。CSSのデガウスや私たちがやったハック、今日、IE6でウェブページをデバッグしていた方法を若いスタッフに説明しようとしていたところだよ。いくつかのことはより複雑になったし、いくつかのことは十分良くなって、逆に複雑さが減った。

└

2022年11月30日以降、すべてが… より複雑になった。人類の物語は、複雑さが増していくことだ。文明の物語でもある。紀元前20,000年の人は、食べ物を探して、凍えないように、食べられないように地球をさまよっていた。紀元前5,000年の人は、食べ物を育てようとして、雨が降ることを願い、病気が村を壊滅させないことを願っていた。2番目の人は、人を管理し、土地を育て続けるために必要なシステムの複雑さを増している。今や地球上の大多数の人は自分で食べ物を育てていなくて、代わりに大きな社会の複雑さを管理することに忙しい。1970年代から80年代の人は、私たちのソフトウェアがLLM以前の時代のものははるかに複雑だと思うだろう。彼らは抽象化レイヤーなしでハードウェアに直接コーディングしていたから。今ではほとんど誰もそんなことはしない。ほとんどの場合、ハードウェアは抽象化されている。大多数の人にとって、暗号ライブラリはその複雑さが抽象化されていて、ほとんどの人は「自分で暗号を書くな、絶対に失敗するから」と言われている。今の質問は、LLMが変えようとしているシステムの理解をどれだけ早く調整できるか、ということだ。

└

ソフトウェアって、なんか複雑すぎる気がする（層が重なりすぎてる）。でも、その複雑さに対処するために、今はさらに複雑さを生み出すものを使ってる。しばらくコーディングしてきたけど、90年代や2000年代初頭は、ビジュアルベーシックやPHPで特に正式な訓練なしにかなり強力なアプリケーションを作れたことを覚えてる。あの技術は素晴らしいわけじゃなかったけど、すごくシンプルで取り組みやすかった。対照的に、今のウェブ開発やデスクトップアプリ開発を始めようとすると、圧倒される。Reactみたいなものは便利だけど、正しく使うために知っておくべきことがかなり多い。AIを導入してこの問題に対処するのは、全体的に見ると間違いだと思う。既存の複雑さの上にさらに複雑さを加えているだけだから。せいぜい、ハードウェアの無駄遣いになるだけだし、最悪の場合、エージェントが修正するバグと同じくらいのバグを生み出して、複雑さに溺れることになる。これらの技術を使って作られたものは脆弱なゴミになるだろうし、人類のスキルセットも減少していく。根本的に、ソフトウェアはこんなに複雑である必要はなくて、解決可能な問題なんだけど、職人技を大切にする人が必要なんだ。

└

それは、人々が変更しようとしているシステムの理解をどれだけうまく調整できるかに制限されている。まあ、これは新しいことではないけどね。プログラミングは理論構築だ（ピーター・ナウル）って、80年代に出版されたんじゃなかったっけ？この分野に新しく入ってきた人たちはそれに出会ったことがないかもしれないけど、出会ったことがなくても、変更しようとしているシステムの理解が重要だっていうのは経験豊富な開発者の間では常識だったよ。

ソフトウェアのコンポーザビリティは、テトリスをプレイするのに似ているってずっと言ってきたんだ。ラインを消さないといけないからね。エージェントを使っている人たち（スキルが低いエンジニアやキャリアの浅い人たち）が、無邪気にそれを破ってしまう感じがする。エージェントは、自分たちを折りたたむのが上手くなってきているけど、指示を出さないとダメなんだよね。でも、Fableや5.6 Solのアーキテクチャの直感は、今のところ私が反射的に達成するレベルにはまだまだ遠い。エージェントが過去の作業を振り返って、より良い抽象化に折りたたむ能力は確かにあるけど、将来のソフトウェアの進化を予測する「高い領域」のアーキテクチャは、今のところエージェントには手が届かない。彼らが今どれだけの情報を頭に入れられるかも関係しているのかもしれないね。どんなにうまく説明しても、現在のセットアップでは、私たちができるような高品質でスパースな「ズーム可能」な世界モデルを頭に持つのはまだ難しい。でも、そういう微妙な点について話していること自体が、期待できる兆しなのかな？

└

プログラムの複雑さの上限は、以前は人間の頭の力だった。「バイブコーディング」はその壁を突破できる。でも、それは解決されるべき問題がその複雑さを必要としているからじゃない。プロセスがコンパクトな抽象化に向かって自ら進まないからだ。これは、ブルックスが「神話のマンマンス」で説明したスケーリング問題のAIパワード版だ。組み合わせの問題は、スケールが大きくなるほど悪化する。具体的には、プロジェクトの異なる部分にほぼ同じものの複数の類似実装が現れる。これは今やバイブコーディングの既知の問題だ。AI駆動のコーディングが簡潔さを追求する方法を見つける必要がある。

└

「マイクロサービス」が復活すると思う？ローカルデーモンに公開APIがあって、それぞれのデーモンが雰囲気を持ってコーディングされてる感じ？

└

同意だね。LLMがまともなコードを書けるようになってから、技術を知っているコードベースと知らないコードベースでの品質の違いがすごく大きいことに気づいた。これは、例えばバックエンドコードのように自分の専門分野でLLMを効率的に操れるからで、モバイルのように全く分からないところでやると、すべてを適当にやることになるから。自分が知らない技術を使ったコードベースは、すぐにメンテナンス不可能でバグだらけになる傾向がある。LLMは良いアーキテクチャの選択をしないけど、私がよく知っている技術を使ったコードベースは基本的にメンテナンス不可能にはならない。両者の違いはすごく大きい。だから、専門分野でLLMを操る有能なエンジニアは、2桁も生産性が上がるけど、何も知らない分野でLLMを操る人は、思考のスピードで技術的負債を生み出しているだけなんだ。

└

ラインはクリアしなきゃいけない。ごめん、ラインは何をクリアしなきゃいけないの？「ライン」に何かしらの制約があるはずだよね。

Hacker Newsで議論の続きを見る

ハクソク