09 苦労と学び — 計画どおりにいかなかった話

自動開発フレームワークの開発自体も、AIと人間の協働で進めています。この章では、うまくいかなかった実例と、そこから得た学びを正直に書きます。

学び1: 「テストが通る」は「正しい」ではない

書き換え確認の仕組みを作ったとき、テストは全部成功していました。ところがテストはテスト用の通路を使っていて、本番用の通路は最初から壊れていた——という実例がありました。複数のAIに「弱点を探して」と頼んだところ、この乖離を見つけられました。

学び: テストの通過は中間指標にすぎない。完了の前に、本当の効果を1コマンドで実測する習慣が必要。

レビューで「ここが文字単位で壊れている」という重大指摘が来たことがあります。しかし実際のコードを開いてみると、その主張は誤りでした。指摘の数や severity ではなく、実コードとの突合だけが判断材料です。

学び: AIのレビューは強力だが、quote（引用）が一致しても主張が間違うことはある。検証は必ず自分の手で。

実装計画書（plan）のサンプルコードには、過去の設計とズレた旧い契約が残っていました。機械的に写すのではなく、既存コードとの突合を必ず挟むルールにした結果、毎タスクで5件前後の計画側ズレを捕捉しています。

「人が指摘するまで気づかなかった」パターンが複数回あったため、指摘されたものはテストやhook（機械の見張り役）に変換して再発を構造的に防ぐ運用を徹底しています。

<details><summary>▶ 技術的にどうなっているか</summary>

</details>