ソースコード をagentが書く前提で、エンジニアはソースをどう体系化して管理すれば、十分に長続きする理解を委任しないままソフトウェアを運用できるか？

将棋棋士は必ずAIの評価値をみるだけでなく、新しい戦法の研究では棋譜を並べる。彼らは理解を委任しない。

本質的な人間の認知資源には限りがある。その中で、使われていない分岐。ベルカーブの極端にいるユーザーのための機能。競合他社に追いつくためのとりあえずの機能。これらは人的で限りある資源を技術的、認知的負債の両面で消費する。

ソフトウェアを動かすものは 実行可能なソースコード である。しかしそれを 創出する こと自体が安価になってしまった結果、乖離が発生している。これまで当たり前にあった「書き手の十分な理解」と出てくるソースコードの非対称性である。

Agenticコーディング以前は適当な理解で仕立てたコードでは要求や非機能要件を満たすことが原理的にできなかった。当たり前だが非対称性を紐づけていたのは「十分に長続きする理解のための書き手の血肉」にあった。

シーケンスダイアグラムやER図、包括的なドキュメンテーション。コードベースの空間認識やある種の概念モデルへの紐づけ。これらはソースコードに 結果として 閉じ込めた手前で、その過程で生まれてくるものである。畳み込まれ収束したソースコードの手前には、発散した大きなストーリーがあり試行錯誤がある。

これはただ綺麗なソースコードだけを見るだけでは構造的に生まれず、ある種発散したカオスを文章化や図式化を通して収束させ生じるものである。発散から収束までの過程を辿るのが十分に長いこと理解するという行為そのものである。「要求を加味した仕様を咀嚼し機械語まで翻訳する」といえば、ソフトウェアの工程に具体化できよう。

ソフトウェアは要求を最も荒い粒度として、実行可能で最も冗長な記述の塊である。冗長な規約文章は99%の人は読まず、ハイコンテキストな理解まで昇華させ不必要な所を意図的に忘却/無視する。十分な理解を抜きにこの昇華も忘却も行えないのだ。

「十分に長続きする理解を持った実装者はトークンの浪費を回避し、かつ責任説明を担保できる」という経済性やSLAメリットを持つのにもかかわらず、その理解に達するのは名人芸として十分に話されていないと思われる。これを体系化して仕組み化するにはどうすべきか？デジタルなものづくりの実装者、そして組織づくりをする立場の人に問われていると思う。

この過程を名人芸として体系化することなく、この議論を抜きにして「コードを書いた人、マージした人が責任を持て」だったり「ソースコードを書く時間が圧倒的に短くなったから、大量の機能を同じ工数で実装しきれるはずである」と指示するのは中長期で間に合わなくなってくると思う。速度を取った10xではなく、質を取った2xを目指すべきでなかろうか。