昨日から今日にかけて、アプリ全体の操作に「誰が実行したか（actor）」を渡して認可するように直す作業をしていた。
やったことは単純で、「この操作は誰の権限で行われたのか」を引数として明示的に渡し、呼び出し側全部でチェックするようにしただけ。理屈は1行で説明できる。
でも実際にやってみると、これが本当につらかった。数字で見るとこんな感じ。
actorを新たに引数に追加したメソッド数: 26- コミット数: 30
- 変更したファイル数: 64
- 変更行数: +2140 / -1239
実装は生成AI、人間はdiffを見るだけ
正直に言うと、この作業自体は自分の手でほとんど書いていない。実装は生成AIに任せて、自分がやったのはひたすらdiffを目で追うことだけだった。
これは意図的な方針。認可周りは間違えると「他人のデータが見える・操作できる」に直結するので、AIが書いたコードを機械的に信用するわけにはいかない。かといって全部自分の手で26メソッド分書き直すのも非現実的。だから「実装はAI、レビューは自分の目」という役割分担にした。
ただこの方針、想像以上に大変だった。生成AIは油断すると一気に大量のファイルを変更しにくる。差分が大きすぎて自分の目で追いきれない。「1メソッドずつ、1コミットずつに分けて」「このクラスだけに留めて」と、粒度を細かく保つよう何度も指示を出し直す必要があった。AIにとっては一括でやった方が効率的なはずなのに、人間のレビューのボトルネックに合わせて歩幅を落としてもらう、という綱引きが地味に疲れる作業だった。コミットが細かく刻まれているのはその結果。
後悔していること
一番後悔しているのは、最初の設計の時点でactorを前提にしておかなかったこと。最初から「操作には必ず実行者が伴う」という前提で設計していれば、こんな横断的な手直しは要らなかった。後から通すコストは、最初から入れておくコストの何倍にもなる。骨身に染みた。
もう一つの後悔は、これに生成AIのクレジットをかなり消費してしまったこと。機械的な変更とはいえ範囲が広く、粒度を小さく刻みながら26箇所分やり直させたので、想定より費用がかさんだ感覚がある。設計をミスった分のツケを、AIのコストで払っている、という気分は拭えなかった。
それでも良かったと思うこと
とはいえ、それを差し引いても評価すべきだと思っているのは、この規模の横断的変更を1日程度で完了できたこと。64ファイル・2000行超の変更を、人力だけで、しかも一つずつ目視確認しながら進めていたら、何日かかったかわからない。クレジットを消費した後悔はありつつ、それで得たスピードは素直にすごいと思う。
そして、一人だったら心が折れていたと思う。26メソッド分、機械的とはいえ延々と同じパターンの修正を確認し続ける集中力は自分一人では続かなかった。生成AIが一緒にいてくれたから、「次、次」と淡々と進められた。
次
横断的関心事（認可、ロギング、監査証跡あたり）は後乗せすると全身に効いてくる。そして生成AIに実装を任せるときは、「速く終わらせる」より「人間が検証できる粒度を保つ」ことの方が結局は近道になる。次に似た匂いを感じたら、今度こそ最初から入れる。