現在は2026年2月3日、午前9時です。
Opus 4.5に、資本持久戦の実験リポジトリの技術的負債を一部返済させました。この技術的負債もまた、Opus自身が生み出したものです。
以前に私が述べた「AIプログラミング実践の考察：OOPと過剰な互換性を避ける」という記事でも触れたように、AIは現在、オブジェクト指向プログラミング（OOP）のコードを書くのに適していません。オブジェクト指向プログラミングは、ビジネス領域に対する深い理解とモデリング能力を要求しますが、AIは現時点ではこの点を満たすことができません。現在、最先端モデルであるOpus 4.5も例外ではありません。
AIは、特定のプロセスを通じて技術的負債を返済することができます。これはまさに「借りたものは返す」ということであり、少なくとも私がAIの書いた質の低いコードのツケを払わなくて済むのは良いことです。
OOPと過剰な互換性の問題を再度強調します。
プログラミングの本質は、この世界をモデル化することであり、認知科学の問題に属します。ほとんどのプログラミングタスクでは、多くの業務に特有の問題を処理する必要があります。実験的なコードはなおさらであり、タスク自体がしばしば新規性を要求するため、AIはユーザーが突然提示する新しい概念を理解できず、その結果、その新しい概念を正しくモデル化できず、誤ったコードを生成してしまうことがあります。一方、十分に認知された少数のタスクについては、通常、優れたモデル化がなされたコードが既に存在します...なぜ再び車輪を再発明する必要があるのでしょうか？
過剰な互換性は、本質的に、AIがそのコードがまだ有用かどうかを知らず、安易に削除することを恐れるために生じ、結果としてコードが肥大化し、保守が困難になります。オブジェクト指向における状態やメソッドは、たとえ誰も使用していなくても、将来的に有用である可能性があると考えられ、保持されてしまいます。その影響はOOM（メモリ不足）に似ていますが、OOMがプロセスのクラッシュをもたらすのに対し、過剰な互換性は認知の崩壊をもたらします。これは見えない落とし穴です。
認知の発達は螺旋状に上昇する過程です。AIであれ人間であれ、一足飛びに達成することはできません。螺旋状に上昇する過程で、機能と負債をどのように維持するかは重要な課題です。興味深いことに、コード、あるいは実験そのものが、私たちの認知を深める助けとなり、その深まった認知が、より良いコードを書く手助けとなります。
私はこれらの考察を記録し、将来の振り返りに役立てます。今、Opusが作業をしてくれるのを待ちながら、自分の考えを記録するのは、実に素晴らしい体験です。
