【CSDN 編集者注】生成AIがソフトウェア開発プロセスに徐々に統合されつつある今日、AIが生成したコードが実際のプロジェクトに登場する機会が増えています。しかし、AIが書いたこれらのコードが、最初から「レガシーコード」と見なされる可能性があると考えたことはありますか？この記事の著者は、自身のエンジニアリング経験から、AIの生成メカニズムを組み合わせ、示唆に富む視点を提案しています。それは、AIが生成したコードは文脈記憶と保守の継続性を欠くため、生まれた瞬間から「他人の古い作品」の状態にあるというものです。これは現在のAIコーディング能力に関する冷静な観察であると同時に、未来のソフトウェア開発のあり方を理解するための新たな視点を提供します。
原文リンク：https://text-incubation.com/AI+code+is+legacy+code+from+day+one
翻訳 | 鄭麗媛
提供 | CSDN（ID：CSDNnews）
ソフトウェア開発において、コードの「改善しやすさ」は、そのライフサイクル段階に大きく依存します。通常、以下のいくつかのケースに分類できます。
書いたばかりのコードが自分のものである場合：「ああ、確かにそう書くこともできるな、難しくないはずだ。」
書いたばかりのコードが他の人のものである場合：「おそらく最近の一時的な状況でそう書いたのだろう。本当に必要なら、少し調整することを検討できる。」
以前に自分が書いたコードである場合：「うーん、当時はそう書くべきだったな。必要なら、今の作業が終わったら優先的に対応しよう。」
以前に他の人が書いたコードである場合：「なぜ彼はそう書いたのだろう？でも触る必要はないだろう、本当に問題が起きてから考えよう。」
全体として、コードの進化速度は、記述からの経過時間と、保守担当者が原作者であるかどうかに依存することが多いです。
実際、この状態は合理的です。安定して検証されたソフトウェアシステムにとって、軽率な「改善」は余計なリスクをもたらすことが多いです。特にシステムの全体像をよく理解していない場合、原作者がその潜在的なロジックと開発背景を最もよく知っているからです。
AIが生成したコードは、どの段階に位置するのか？
では、別の角度から見て、AIが生成したコードは具体的にどのような段階にあるのでしょうか？私の見るところ、それはいくつかの重要な特徴を持っています：
（1）AIが文脈ウィンドウを持っていたとしても、それは「ステートレス」です。つまり、AIはなぜコードがそう書かれているかを推測できますが、当時の作者の具体的な意図を真に「知る」ことはできず、人間の保守担当者のように現実の時間点の記憶を持つこともありません。
（2）AIが生成するコードは、毎回「他の誰かが書いた」ものです。AIは、あなたが書いたコードを初めて読む新人のように、ゼロから文脈理解を構築します。それは、当初の入力がどのように特定の「回路」を経て出力に変換されたかを本当に「覚えている」わけではありません。
（3）AIが生成したコードは、生まれた瞬間からすでに「年老いて」います。「新しいコード」の段階を飛び越え、直接「他人の古いコード」のモードに入ります。時間的な「新鮮さ」もなく、原作者による継続的な保守の恩恵もありません。このようなコードは、最初から「レガシーコード（legacy code）」と見なすことができます。
もちろん、熟練したAI開発者の中には、この問題の解決を試みている人もいます。例えば、入念に構築されたプロンプト、合理的に設計された文脈ウィンドウ、詳細なコメントなどの手段を用いて、AIのステート記憶不足を補っています。しかし全体的に見て、これらのアプローチは慣性に従い、ある方向へゆっくりと最適化しているように見えます。
しかし、私の個人的な推測は――おそらくこれは根本的な問題ではないということです。なぜなら、コード自体がある種の「静的状態」だからです。プロンプトエンジニアリングや文脈ウィンドウの能力が向上するにつれて、コードは長期的な保守よりも「プロンプトで生成」されることが増えるでしょう。将来、「複雑なソフトウェア」のコード量は減少する可能性があり、より多くのロジックが静的な構造ではなく、モデルの推論やプロンプトに依存するようになるでしょう。
この背景において、AIがプロンプトで生成したコードは、短期的/中期的な「移行の架け橋」のようなものです。
味わう価値のある高評価コメント
私は上記の視点をまとめて記事として公開した後、Hacker Newsで熱烈な議論を巻き起こしました。以下は、味わう価値があると思う高評価コメントをいくつか紹介します：
（1）@dang：記事の冒頭は、実際にはPeter Naurが1985年に発表した古典的な論文『Programming as Theory Building』に遡ることができます。ついでに補足すると、NaurはALGOL言語とBNF構文の核心人物の一人です。
Naurの視点では、複雑なソフトウェアシステムは、本質的に開発者集団の心の中で構築された「理論」です。ソースコードとドキュメントは、この理論の低忠実度表現（lossy representation）に過ぎません。なぜなら、コードとコメントだけで、このシステムを構築する際の全ての思考過程を完全に再現することは永遠に不可能だからです。
この意味において、レガシーコード（legacy code）とは、コードやドキュメントといった「遺物」は残っていても、それらを支える「理論」が原作者の退職とともに失われたものを指します。これは、システムに対する「深い改善」を行う権限を失い、修繕や保守しかできないことを意味します。
では、この思想は大規模言語モデル（LLM）時代に何を意味するのでしょうか？
LLMはコードを生成する際に、必然的に「プログラムの背後にある理論」を欠くのでしょうか？これは決着のついていない問題であり、いくつかの可能性が考えられます：
LLMはコード生成時に、すでに何らかの「理論」を暗黙的に含んでいるが、我々がまだ理解できていないだけかもしれない；
おそらくLLMは既存のコードから徐々にこの理論を構築できるか、あるいは将来できるようになるだろう；
おそらくLLMは人間のエンジニアリングチームが必要とするような「理論」を全く必要としないだろう；
もしコードがAIによって生成されるなら、おそらくAIこそが理論を掌握している唯一の存在であり、もはや人間ではないのかもしれない；
あるいは、この「理論」はコードを書く人間ではなく、プロンプトを書く人間の手にあるのかもしれない。
（2）@mrweasel：私と上司は、新しい若い同僚に「あれは当時の書き方なんだ」といつも「弁解」します――ほとんどの場合、これはうまく書けていないコードのインターフェースを隠すためのもので、「当時」とはたった2週間前のことかもしれません。
しかし、時には我々が間違っていないこともあります。なぜなら、奇妙な書き方の中には、極端な境界シナリオに対応するためであったり、古いシステムとの統合のためであったりするものがあるからです――それらはそもそもその時代の産物でした。幸いなことに、我々はまだチームにいるので、どのコードを削除できるか、または少なくとも削除を試みる価値があるかを判断できます。
私は、LLM補助プログラミングがプロンプトを記録し、生成されたコードと一緒に保存できるなら、それは人間よりも技術的負債を管理できるかもしれないと思います。例えば：
もしあなたが、あるコード片が「クライアントがAIX 6で実行されている場合の境界ケースを確実に処理する」というプロンプトによって生成されたと知っているなら、それは多くの疑問に答えるでしょう。たとえ当時は誰がAIXを使っていたかを知らなくても、なぜそのコードが存在するのかは少なくともわかり、まだ削除できるかを判断できます。
（3）@TZubiri：原文で「AIが文脈ウィンドウを持っていたとしても、それは『ステートレス』（stateless）である。つまり、AIはコードがなぜそう書かれているかを推測できるが、当時の作者の具体的な意図を真に『知る』ことはできず、人間の保守担当者のように現実の時間点の記憶を持つこともない。」と述べられています。
この文について、私は言いたい：Chain of Thought（思考連鎖）技術でこの問題は解決できます。
CoTを持たないモデルでも、元のコードを「読む」ことで文脈を再活性化できます。実際、これは人間のエンジニアによく似ています――我々も常に全てのコードの背景を覚えているわけではありませんが、コードを読み直せば、通常、当時の文脈を思い出すことができます。
さて、今日の内容共有はここまでです。良いと感じた方は、共有やいいねを忘れないでください！