AIへ大きな実装を丸投げしない：作業を小さく分ける

「認証機能を全部作って」と依頼すると、設計、依存追加、DB変更、画面変更が一度に混ざります。AIへ渡す仕事は、一つずつ合否を決められる大きさに分けましょう。

今回やること

AIへの作業を成果決定、調査、契約と境界、一つの実装、検証、人の差分確認へ分け、範囲外なら止める図

課題提出後に講師へ通知する機能を例に、AIへの依頼を次の順へ分けます。

いきなりコードを書かせず、現状と未決定事項を出させます。

目的: 課題提出後に担当講師へ通知する。
まだ実装はしないでください。
現在の提出処理、担当講師を決める場所、既存テストを調査し、
変更候補のファイルと未決定事項だけを報告してください。

調査結果を読んでから、通知先が未設定ならどうするか、メール失敗で提出自体を失敗にするかを決めます。これはAIに推測させず、人が決める仕様です。

実装を頼む時は、目的・触ってよい範囲・完了条件を揃えます。

目的: 提出IDと講師IDを持つ通知記録を保存する。
変更してよい範囲: 通知記録のモデル、保存処理、そのテストだけ。
完了条件: 同じ提出を再処理しても記録は1件だけになるテストが通ること。
触らない範囲: 認証、画面、メール送信、依存パッケージ。

「バックエンドを作る」のような依頼では、どこまで変わってよいかも、何を確認すればよいかも分かりません。作業時間ではなく、失敗しても戻す場所を特定できる境界で分けます。

次の3点がそろえば、その段階は完了です。

AIが許可していない依存更新や画面の整理を始めた場合は、差分をそのまま採用せず、依頼文の境界を狭めてやり直します。

型の追加と、その型を使う一行だけを別タスクにすると、確認より引き継ぎが増えます。一つの結果を確認するために必要な最小範囲は、同じ依頼に含めます。

通知なら、正常な提出だけでなく、同じ提出の再処理、通知先がない場合、送信失敗時の扱いも仕様と照合します。テストは「何を守るか」を示す証拠です。

「プロフィール画像を追加する」を、次の5個以内の仕事に分けてください。各仕事に、入力・完了条件・触ってよい範囲を一行ずつ書きます。

公開範囲や削除後のファイルをどうするかが未決定なら、実装に混ぜず「決める仕事」として分けられれば正解です。