在庫処理の修正が注文明細の順序を破壊

よく知られた問題だ。人がコードを読む速度はAIが生成するコードに追いつかない。提案される姿勢は、変更後も残すべき性質をあらかじめ決めてLawsとして書き、コードから読み取る具体的な事実としてAtomsを定義することにある。ArchMapはその観測をソース位置とともに記録するため、疑わしい値はコードまでたどれる。

django-oscarの事例はその重要性を示す。在庫ロックの順序を揃えるための変更が、両処理が同じループを共有していたため注文明細の作成順も変えた。L1（在庫はstockrecord順に割当）とL2（注文明細はバスケット順に作成）に対し、変更前のコードはL1を満たさずL2を満たした。並べ替え後のコードはL1を満たしL2を満たさなかった。ループをPR #4594とPR #4598で分割して初めて両方のLawsを満たした。

これは代数アーキテクチャ理論（AAT）につながる。Lawsを方程式とみなし、その解空間がソフトウェアを満たす状態を表すとし、許容される変更範囲内で診断や修復候補を探索する方法を説明する。ライスの定理などの限界も認め、有限または線形モデルに限定すれば判定と修復が計算可能になると述べる。