フロントエンドはエージェントに「状態機械（または reducer）」で書かせる

なぜ効く？

• 取りうる状態と遷移が明示されるので、「ありえない状態」（loading なのに error も表示、など）が入りにくい
• 変更は「状態と遷移の追加」に閉じるので、次にエージェントが触っても壊しにくい
• 遷移ごとに単体テストを書きやすく、検証をエージェントに回しやすい

頼み方の例

• 「このフォームの状態を idle / editing / submitting / success / error の状態機械として設計し、遷移表を先に出して。承認後に reducer（または XState）で実装し、遷移ごとにテストを書いて」
• 既存の useState が増えすぎたコンポーネントには「状態を1つの reducer にまとめ、ありえない組み合わせを型で禁止して」

注意点

• 小さな UI に過剰に入れない。状態が3つ以上・非同期を含むものから
• ライブラリ（XState など）を入れるかはチームの慣れ次第。素の useReducer＋判別共用体でも十分
• 関連: 仕様・手順書の曖昧さを「複数回実装させて」検出する

出典

• @mattpocockuk · 2026-10-16