#なぜ今日これを選んだか

AIにコードを書かせる時代の品質は「モデルの賢さ」ではなく「失敗を次に活かす仕組み」で決まる、という主張が刺さった。自分も最近、実装漏れを機に postmortem を書き始めたところで、同じ問題意識を「コードベース側の設計」として語っているのがこの記事だ。守りではなく品質そのものを上げる、という方向にちょうど合う。

#要点

• CAPA（是正・予防措置）をコードベースに組み込む: 医療の品質管理を参考に、エージェントの誤りは根本原因を分析し、再発防止策を「コードベースに残す」。人がチャットで注意しても次のセッションには残らない
• 指示より検証で縛る: LLMに「〜するな」と頼むより、リンター・コンパイラ・静的解析で機械的に禁止する方が確実。決定論的ツールが「やってはいけないこと」の門番になる
• グローバルメモリ: コード内コメントだけでなく、レビュー指摘やバグ報告から得た知見を検索可能な形で蓄積し、エージェントが次の作業前に引けるようにする
• 期待値は現実的に: 「ワンショットでゲームを完成」のような話は過大。反復的にテストして直すループこそが本体。HNコメントも「行き先を明確に指定できなければ高性能でも役に立たない」と手厳しい

#自分にとっての示唆

postmortem を「読み物」で終わらせず、機械が読める形に落とすのが次の一歩だ。具体的には、実装漏れの再発防止を「気をつける」ではなく、投入前検証スクリプト（この前 eigo に入れた catchup ガードと同じ発想）や lint ルールに変換する。Rust を学ぶ理由もここに繋がる。コンパイラが厳しい言語ほど「検証で縛る」設計が自然にできる。明日からは、postmortem の対策欄に「これを機械で強制できるか？」の1行を必ず足す。

原文を読む →