AIが書いたコードは全部読まなくていい――契約とテストで絞る
AI生成コードを同じ密度で読むのをやめ、先に事前条件・事後条件・不変条件を決めて型とテストで外から検証する。人は仕様と高リスク部分の判断に集中する。
#なぜ今日これを選んだか
AIにコードを書かせる量が増えるほど、レビューが追いつかなくなる。「全部読む」でも「読まずに通す」でもない第三の道として、レビューの密度を設計で絞るという考え方が具体的だった。品質を守りで支えるのではなく、仕組みで上げたい自分の方向にそのまま重なる。
#要点
- 「正しい」の条件を先に決める。事前条件・事後条件・不変条件を契約として明示し、型・バリデーション・テストに落とす
- 副作用を隔離し、戻り値以外に何が変わるかをはっきりさせる。純粋にできる部分は純粋にする
- 中身を毎回読まずに使える境界（抽象化）を作り、契約を機械的にテストで確かめる。人間は仕様定義と高リスク部分の判断に集中する
#自分にとっての示唆
AIに実装を任せる場面が日常になった今、自分の価値は「速く書く」ことではなく「何が正しいかを決めて、それを機械が確かめられる形にする」ことに移っていく。モックだらけのテストが緑でも本番で落ちるのは、境界の契約が外から確かめられていないからだ。明日からは、AIに何かを書かせる前に、その関数の事前条件と事後条件を3行で書き、それをテストにしてから実装を頼む。読む密度は、外部とつながる境界と副作用のある箇所だけに上げる。