理解の負債：LLM生成コードの時限爆弾

「モデルや理論が必要だと思わないプログラマーと、LLMが自分たちを速くしていると報告している人たちの間には強い相関関係があると思う。」私は、コンピュータや関連技術から完全に離れているときに、ソフトウェアプロジェクトでより多くの価値を生み出せるという経験がある。自分が何を求めているのかが明確だと、コードがどれだけ早く進むかは驚くべきことだよ。この時点でLLMは非常に役立つことができる。なぜなら、その幻覚がすぐに自分の視点でフラグを立ててくれるから。もし自分が何を求めているのかわからなければ、これがどう機能するのかは見えない。私は、毎日何時間も真っ白なキャンバスを見つめる理由が本当に理解できない。LLMはあなたを解放して正しい方向に進ませるかもしれないけど、むしろ無駄な追跡に引き込まれる可能性が高いと思う。私が解決した最後の10/10の難しい問題は、たぶんキッチンで玉ねぎを切っているときに起こった。

「理論構築」 LLMが生成したコードの「理解の負債」をプログラミングを理論構築と結びつけたのは洞察に満ちているね。これはプログラミングの活動を超えて、思考や理解のプロセス全般に当てはまると思う。LLMが生成したコンテンツ、文章や視覚芸術も含めて、これはコードに相当するもので、表面的には最終結果として人々が見るものだ。でも、もし人がその生産に関与していないと、何を意味し、どう機能するのかの理論を構築することはできない。詳細を通じて全体をまとめることができないと、表面的な理解しか得られない。たとえLLMが進化してこの「理論構築」を自分で行えるようになったとしても、人間が関与しない人工的な理解に何の意味があるのか？それは非常に役立つかもしれないし、価値もあるかもしれないけど、最終的には機械に考えさせる方が便利になって、人々は理解するスキルを失っていくかもしれない。

これが、AIコーディングで他の同僚よりも少し成功している理由の一部だと思う。LLMが出る前のワークフローは、何かのクソみたいなバージョンを素早く作って、理解を深めるために再構築する（場合によってはプロトタイプを捨てることも）って感じだった。多くの思想的リーダーがこの一般的なアプローチ（迅速なプロトタイピング、継続的なリファクタリングなど）について語っているけど、多くのエンジニアは抵抗を示して、アプローチを考えた上で「正しく」作りたいと思ってる。あるいは、何かをさっと作り出して捨てずに、最初のクソみたいなものを修正することに苦労している。AIを使うと、このループがずっと楽になる。何かの3つの並行実装を作るのも安上がりだし、システムが面白いと思う機能を追加するのを許可する別のものを作ることもできる。これを比較して、要件や関心の分離、大きなシステムとの統合方法を考えた「プログラムの理論」を構築するのに使える。AIにそれを作らせて、出力をしっかりレビューすれば（何を作るべきか大体わかっていれば、時間もかからない）、すごくうまくいくよ。

完全に同意だね。かつて、元の開発者たちが突然消えて、新しいチームが引き継いだプロジェクトに関わったことがあるんだけど、すべての制度的知識が失われてしまったんだ。元の設計を理解するのに、無駄に時間をかけてしまった。理解が深まるまでにかなりのバグを導入してしまったけど、頭をぶつけながらも多くの設計問題を修正したよ。結局、ほとんど書き直されて、元々計画されていなかったことをするように拡張されたんだけど、そのプロセスは本当に苦痛だった。

プログラミングは「達成したいこととその方法」だね。線形プログラミングや動的プログラミングのように。 > モデルや理論が必要だと思わないプログラマーと、LLMが彼らを速くしていると報告している人たちの間には強い相関関係があると思う。これは面白い予測だね。根本的な原因に関係なく相関が得られると思うよ。ほとんどのプログラマーはモデルや理論が必要だと思っていないし、ほとんどのプログラマーがLLMが速くしていると報告しているから。でも、それを考慮に入れると、逆のことが真実である理由もいくつかあるかもしれない。LLMによって最も速くならないと感じるプログラマーは、主にコードを書くことが貢献だと感じている人たちかもしれないし、正しいモデルを見つけることを仕事と考える人たちは、コードを正しい順序に整えるという雑務がなくなるから、より速くなる可能性がある。

そうだね。業界はドメイン特有の知識やコード特有の知識の必要性、開発者が残ることの価値を軽視してたと思う。開発者が「理論構築」や共有に時間を使うこともね。全てのコーディングチームを入れ替えて、同じ開発ペースで進めると思ったら大間違いだよ。コードが比較的良くて、新しい開発者がそれなりにスキルがあってもね。特に「アーキテクチャモデル」レベルのドキュメントが不足してるときは。まあ、LLMがそれをめちゃくちゃなレベルに押し上げてるけど。もし全てのコーダーが自閉症の天才幼児で、毎月新しい幼児チームに入れ替わったらどうなるんだろう。

LLMのおかげで、僕たちには良くなったよ。ジュニア開発者がコミットするコードの質が向上した。

キャリアの中でいくつかのレガシーアプリケーションに関わってきたけど、プログラミングの他の多くの問題と同じように、この問題の最も重要な解決策は良いモジュール化だと思う。そうすれば、新しいチームがモジュール同士の相互作用を高いレベルで理解できるし、変更が必要なときは関わるモジュールだけを理解すればいい。理想的には一つずつね。だから、全体のアプリケーションの詳細な理論を一度に作る必要はないんだ。LLMを使ってみて分かったのは、良いモジュール化の原則と実践を守れば、LLMがあればあまり知らないコードベースでも作業を始めやすくなるってこと。ナビゲートしたり、「必要な分だけ」理解したり、特定の変更をするのにすごく助けてくれる。でも、これはLLMが自動でやることじゃない、少なくとも僕の経験ではね。やっぱり人間が良い、一貫したモジュール化を強制する必要がある。

プログラマーがモデルや理論が必要だと思わないことと、LLMが彼らを速くしていると報告していることの間には強い相関関係があると思う。僕もランポートに強く同意するけど、なぜAIが元のチームやプロジェクトを引き継ぐチームの「理論構築」プロセスに役立つと思わないのか、ちょっと気になるな。つまり、コードベースやアルゴリズムを理解することについてね？全ての知識を置き換えるわけではないけど、ギャップを埋めることはできると思う。

実際、LLMによって開発者がスピードアップしている（つまり、単にコードの行数ではなく、保守可能な成果物の出力を増やすこと）というのは、彼らが取り組んでいるシステムの理論をしっかり持っている人たちだと思う。少なくとも今のところ、LLMは「どうやって」の部分では素晴らしいけど、「何を」「なぜ」を理解するためのコンテキストが欠けていることが多い（それが書かれていなかったり、彼らのトレーニングデータにあまり含まれていなかったりするから）。