mskbhd氏のOSSは、業務ルールをプロンプトではなくモデルに一度だけ書き込み、以後すべての操作に強制適用する。だが宣言の中身が正しいかどうかは、著者自身がChatGPTに自己評価させて初めて怪しいと分かった。強制できるものと、検証が要り続けるものは別だった。
飯沼亜紀氏は、組織で「アウトプットだけが唯一の確定事実になる」構造を、時間軸と確定性のズレとして図式化した。この週に自分たちが送った5件のPRのWhy欄を読み返すと、そこに書かれていたのは価値の仮説ではなく、実装の理由だった。
松尾研究所の浮田氏は、社内知識をSkillsとして構造化することで、Agentの正解率を33%から96%まで引き上げた。だが重大な失敗の発生率は15.6%で下げ止まった。この記事を書いている自分たち自身にも、同じ種類の下げ止まりが起きていた。
ナレッジセンスCTO須藤氏は、レビュー役に反論役を対置し、反論には証拠を義務付けることで指摘の精度を3ポイント上げた。だがその実験が測っているのは、証拠を求めたことの効果であって、示された証拠そのものが正しいかどうかではない。
TRIBEAU CTO小尾氏のtext-to-SQL基盤は、クエリ一つひとつにレビューを置かなかった。手を抜いたわけではなく、一時的な問いと永続するコードの境界を見極めた結果だった。ただしその境界の内側に、まだ誰も確かめていない場所が一つ残っている。
interview-dev-loopは実装前の曖昧さを閉じた集合にして質問に変える。Parryは実装後の曖昧さをPRの四軸にして人間に渡す。役割分担で済むと思いかけたが、この記事の題材を選ぶ自分たちの作業で、その集合の外にある見落としを一つ見つけてしまった。
Armin Ronacherは「ハーネスループ」で人間の理解が失われることを警告した。Parryの四軸がその防波堤になっていると思いかけたが、自分たちの運用記録を読み返すと、止めていたのは記録の中身ではなく、通れない関所の有無だった。
伊林義弘氏の4分離設計は、Parryの四軸とほぼ一対一に対応するように見える。だが記録の読み手がセッション内のAI自身か、セッション外の人間かで、同じ形の記録は違う問題を解いている。
DDDのユビキタス言語が組織で定着しないのは、辞書として固定しようとするからだ。ドメインが発見し続けるものであるように、PRのWhyもテンプレートに固定した瞬間から形骸化が始まる。
ログラスCTOの「動くだけのその先へ」は、仕様の正しさをハーネスと三層構造で担保する。だが仕様が正しくても、複数ある実装のどれを選んだかという理由は、その三層のどこにも残らない。
意図負債という言葉は、1985年のNaurの論文まで遡れる。t-wadaの資料と、blog-prod-posts自身の一次データから、その系譜と実在を検証する。