積み上がる技術的負債：止まらない「技術の塔」の崩壊危機

システムが成長するにつれ、メンテナンスという名の塔が天井知らずに高くなっていませんか？場当たり的な修正を繰り返した結果、少しの変更で崩れ落ちそうな不安定なアーキテクチャになってしまっている現状。そろそろ、この高く不安定な塔を見直すタイミングかもしれません。

「AI支援プログラミングは、より優れたツールを得ることで、より野心的なソフトウェアを構築できるようになる」という魅力的な考え方があるよね。個人のレベルで見れば確かにそうだし、エージェントを使える開発者がコードベースを変更する能力が飛躍的に高まるのは疑いようがない。でも、大規模なソフトウェアプロジェクトの限界は、個人のコーディング速度だけで決まってきたわけじゃないんだ。プロジェクトの限界は、関わっている人たちが変更対象のシステムに対する理解をどれだけすり合わせられるか、その調整にかかっている。

本当にその通り。2022年11月30日以降、すべてが…もっと複雑になってしまった気がする。

ソフトウェアの合成可能性（コンポーザビリティ）はテトリスに似ているって、ずっと言ってきたんだ。ちゃんとラインを消していかないといけないからね。

それこそが「塔が積み上がっていく」という比喩を文字通りに体現していると思うんだけど、エージェントを安易に使う人たち（あるいはスキルが低い、経験の浅いエンジニアたち）は、まさにその原則を破ってしまっているように見える。

エージェントは、特にこちらが指示を出せば、内部で物事をまとめ上げるのが上手くなってきている。でも残念ながら、Fableや5.6 Solのようなツールを使ったとしても、そのアーキテクチャの直感は、私が反射的にやってのけるレベルにはまだまだ程遠い。

確かにエージェントを使って作業を何度も見直し、優れた抽象化へと練り上げていく（アニールする）ことは可能だ。自分のコードベースでも似たようなことはやっている。でも、「ソフトウェアが将来どう進化するか」を考慮した高度なアーキテクチャや、その繊細な予測といった部分は、今のところエージェントの手の届かない領域だね。

ただ、エージェントが今の時点でどれだけ情報を頭に保持できるかという制約の問題なだけじゃないか、とも思う。どんなにうまく言語化して高密度に情報を与えても、人間ならできるような「世界についての質が高く、疎で、ズーム可能なモデル」を頭の中に構築させることは、今のセットアップではまだ難しいから。

とはいえ、こうして繊細な議論ができるようになっていること自体、明るい兆しだとは思うけどね。

エッセイへの直接的な返信じゃないんだけど、エージェントによるプログラミングって、実際のプログラミングよりもマネジメントに近いんじゃないかという気がしてきたんだ。マネージャーは一般的に、IC（個別の貢献者）が何をしているかを高いレベルで把握しているだけで、監督下のICがやっていることの詳細すべてを理解する時間や帯域幅、あるいは能力を持っていないことも多い。ソフトウェア開発がエージェント化されていくにつれて、ソフトウェアエンジニアの役割は技術職からマネジメント職へとシフトしていくのかもしれない。

「ソフトウェアプロジェクトの共通言語は英語やPythonではなく、概念が何を意味し、境界線はどこにあり、どの不変条件が重要で、誰が何を所有し、なぜそのシステムがその形をしているか、という共通理解である。この言語がひとまとめに書き出されることは稀だ。ドキュメントやコードだけでなく、コードレビューや議論、そして誰かに変更を説明しなければならない経験の中に生きている」

本当にその通り。私はChristopher Alexanderの「パターンの言語（Pattern Language）」という概念が大好きなんだ。まさにこの問題を扱っているからね。彼は自分の領域に合わせて独自のパターンの言語を開発することを推奨していて、それが有名なGoFの『デザインパターン』という本にも繋がっている。

最近は、AIに対してプロジェクトごとに3つのパターンの言語（ビジネス領域、プロダクト領域、技術領域）を維持するよう指示する実験をしているんだけど、これがかなりうまく機能している。AIが計画時にそのパターンの言語を参照し、実装やレビューの過程で修正していく姿を見るのは最高にクールだよ。

100% AIでコーディングしたプロジェクトを整理し、ドメイン間での整合性を保ち、開発しやすく維持できているのは、このおかげだと思っている。

私もバベルの塔とブリューゲルの絵の話を思い出すけれど、そこから得られる示唆はもう少し悲観的かもしれない。

システムが隆起し、広がりを見せる中で、近視眼的なエージェントたちがこの計り知れず巨大な全体像の片隅で、それぞれの小さな領域を開発している様子が目に浮かぶ。片側には50個もの胸壁がある塔があり、反対側にはなぜか奇妙な片持ち梁の小塔が突き出ていて、理由は誰にも分からないがパティオの上には実用的な日干しレンガの屋根があり、その横の踊り場にはわらぶき屋根がある…そんな光景だ。

個々の設計としては成立していても、全体を統括するようなポリシーや判断力が欠けている、そんな巨大でグロテスクな「ファットバーグ（脂肪塊）」のような代物だ。

いわば、全体を貫く言語が欠けているんだよ。

言語を確立し維持するには、どんな大きな組織であれ規律が必要だ。成功している組織の社内用語や軍隊用語を見ればよくわかるだろう。

私たちは「ガスタウンの市長たち」（彼らもまたその下のゴーレムたちと似たような言葉を使っている）と同じ言語で話すという問題を克服したと「感じて」いるかもしれない。でも、すべてが完成した時に神様が私たちを謙虚にさせるはずだ。玉座から完璧に伝えたと思っていたはずの理解が、実は想像していたほど共有されていなかったことに気づかされるんだよ。

このエッセイの核心的な主張は「Lisp Curse」や「Bipolar Lisp Programmer」を思い出させるね。

もう何年も読んでいないけど、議論の要点は「Lispはあまりにも簡単にモノを作って自分の欲求を満たせるからこそ、Lispプログラマーが協力して非自明な汎用ツールを作る強力な動機が生まれない」というものだったはず。それゆえに、何かを達成するのにより多くの努力を必要とする言語と比べて、Lispの公開ソフトウェアの状況が貧弱になってしまうという話だ。

ArminがAIコーディングについて指摘していることも、これと非常に似た議論だと思う。

アナキン：「エージェントを使える開発者は、コードベースを劇的に変えられるようになるんだ」
パドメ：「より良いものにするために、だよね？」
アナキン：（黙って見つめる）
パドメ：「より良いものにするために、だよね？」

「これは聖書の話とは違う。バベルでは共通言語の喪失が建設を止めたが、AI支援エンジニアリングでは、共通理解が崩壊した後も建設が続いてしまう。即座に破綻しないということが、この状況を奇妙で方向感覚を失わせるものにしている。塔は崩れないから、私たちは何を失ったのかに気づかない。ただ、積み上がり続けるだけだ」

著者がこれを良いことだと思っているのか悪いことだと思っているのかは分からないけれど、私の目には明らかに悪いことのように見える。トマトが果物だと知っているのが知性で、それをフルーツサラダに入れないのが知恵だ。AIは知恵を一切持たない知性の究極形態。いや、そもそも知性ですらなく、知性の幻影だ。AIがやっていることを人間が理解できなくなったなら、それは立ち止まって、自分たちが作り出しているものを制御する知恵を私たちが持っていないことを認めるべき時なんだと思う。

コミュニケーションは危機に瀕しているんだろうか？ もしかしたら、これまで以上に人々の注意を必要とし、関与や貢献を強要してくるようなものになっただけかもしれない。

LLMは、文字や言葉、インターネットに次ぐ、あるいはそれらと同等以上に強力な史上最強のコミュニケーションツールだ。電話やメールよりも重要かもしれない。

この新しいインフラの形で「理解」がいつでも手に入るようになった今、塔（コードベース）とその中での私たちの調整作業は、チームや管理者の意志に従って、上へ下へ、横へと非常にカスタマイズ可能になっている。

あなたのアーキテクチャの好みや直感、抽象化の専門知識は、LLMが完全に模倣するにはサンプルサイズが足りないかもしれない。でも、もし望むなら、LLMはあなたの承認に合わせて調整を重ね、それに近づいていくことができる。

塔が完成したら、次はどうするつもり？

「バイブコーディング（vibe coding）」が生成されたコードを読むことを特に避ける理由は、Pythonファイルの中に潜むホラーを一度見たら忘れられなくなるからじゃないかと、最近強く思うんだ。

コードは「広い意味では」要求通りに動く。でも、ゴール達成のために複数の選択肢がある場面では、一貫性なく選択がなされているんだ。

あるユーザー入力には奇妙なバリデーションが適用されているのに、別の場所では適用されていなかったり、理由もなく3段階もデータをソートしたり小文字化したりしている。CSVの1行目がヘッダーだと分かっているのに、列のラベルがハードコードされた文字列になっていたり、データクラスを扱う関数なのに半分は普通のクラスとして定義されていたりする。

もしあなたがそれを見て、いつか手動で更新・メンテナンスが必要になるかもしれないと思ったら、こうしたゴミを修正せずにはいられない。でも、それを修正するだけで、AIで節約したはずの時間の多くが吹き飛んでしまうんだ。