AI時代、ソースは誰のために書くのか（3/4 開発の進め方編）

 これまでの2回で、コードの書き方と技術スタックの選び方を書きました。ただ、ここまでの話の多くは「AIがなくても言われてきた原則の重みが変わる」話でもあります。今回は、AI開発でしか起きない変化に絞ります。

根っこにあるのは、「書くコストがほぼゼロになって、決めることと確かめることのコストだけが残る」というコスト構造の逆転だと思っています。

■決め方が変わる

作り込みが曖昧さを吸収していた

・これまでは、設計書に書ききれていない細かいことを、作り込みの中でエンジニアが判断して埋めていた。手を動かしながら「この場合はどうするか」を決めて、迷えばお客様に確認する。作り込みが曖昧さを吸収するクッションになっていた

・AIはそのクッションにはならない。曖昧なまま渡すと、聞き返さずにもっともらしく埋めてくる

戻せる決定は、作って見て決める

・ただ、修正や作り直しもAIで速くなるので、全部を先に決めきる必要はないと思う

・画面のレイアウト、文言、内部の処理の分け方みたいに後から戻せるものは、作り直しがほぼタダ。むしろお客様は文章の仕様書より、動くものを見たほうが判断しやすい。何パターンか作って見せて選んでもらうほうが、会議で詰めるより早くて正確

・この領域では、決めるタイミングをむしろ後ろにずらせるようになった

戻せない決定は、先に決める

・一方で、コードの作り直しが速くなってもコストが下がらないものがある。データの持ち方、外部システムとの連携仕様、権限やセキュリティの設計、お金の計算ルール、法律や契約が絡む部分

・こういうものは、コードを書き直すのは一瞬でも、データ移行、相手先との調整、再テスト、利用者への周知が付いてくる。ここは今まで通り、むしろ今まで以上に先に決めておく必要がある

・作る期間が短くなったからといって、ここを決める要件定義や設計の時間まで削るのは危ない

本当に怖いのは「気づけないこと」

・作り直しのコストより怖いのは、AIが黙って埋めた箇所に気づけないこと。人間のエンジニアなら質問してきた箇所が、聞かれないまま、それっぽく動く形で埋まっている。作り直しが速くても、作り直すべきだと気づかなければ意味がないし、気づくのが本番データが入った後だと、戻せない決定に化ける

・なので対策は「全部先に決める」ではなく「AIに勝手に埋めさせない」ほうだと思う。仕様が曖昧なところをAIが判断で埋めたら、必ず一覧にして出させる。そうすると、黙って埋められていた箇所が人への質問に変わる。昔エンジニアが作り込み中にしていた質問を、AIに意図的にさせるイメージ

整理すると

・決める量そのものは減っていない。変わったのは、「戻せない決定は先に」「戻せる決定は作って見ながら」と、決め方を使い分ける必要が出てきたこと

・難しくなったのは、決める量が増えたからではなく、「どれが戻せない決定なのか」を見極める判断が要るようになったから

■モデルが依存関係になる

・コンパイラのバージョンを固定するのと同じで、モデルのバージョンも管理対象になる。モデルが更新されると、同じ指示でも書くコードの癖が変わる

・「どのモデルで生成したか」を記録しておく、モデル更新はライブラリのメジャーアップデートと同じ扱いで検証する、という運用が必要になると思う

■ルールは文章ではなくツールで強制する

・コーディング規約を文章で書いても、AIは守ったり守らなかったりする。でもコンパイラ、リンター、静的解析がエラーとして返したものは、かなりの確率で直してくる。少なくとも自分の体感では、文章のルールよりずっと効く

・Javaには、パッケージやレイヤー間の依存ルールを普通のユニットテストとして書けるArchUnitというライブラリがある。これで「このレイヤーからあのレイヤーは呼ぶな」をテストにして、機械的に止める

・ルールをツールに移せば、そのぶんコンテキストドキュメントに書く量も減らせる。ツールで強制できるルールは腐らないので、次回書く「コンテキスト負債」への一番の対策もここだと思う

■並列開発を前提に分割する

・AIエージェントを複数同時に走らせると、同じファイルを同時に触ってコンフリクトする。定数をまとめた巨大なクラス、全種類を列挙する大きなswitch文、中央の設定ファイルが衝突の温床になる

・人間なら「今そこ触ってるよ」で調整できたけど、エージェントはしない。「同時に別々の作業者が触っても衝突しない」が分割の基準に入ってくる。1回目に書いた「部分で完結する作り」は、ここでも効いてくる

■作ってから比べる

設計判断が議論から実験へ

・書くコストがほぼゼロなので、「A案とB案どっちがいいか会議で議論する」より「両方作って計測して比べる」が現実的になる

・1回目の継承の性能の話も、議論するより両方書いて測ったほうが早い。設計の議論が、机上の推論から実験に寄っていく

・上に書いた「戻せる決定は作って見て決める」と同じ考え方。ただし戻せない決定まで「とりあえず作って比べよう」で進めると、比べ終わる前にデータや連携が乗ってしまうので、そこだけは先に決めておく

GCのチューニングも勘から実験へ

・GCのチューニングは、これまで経験者がログを読み解いて、勘でパラメータを決める職人芸の世界だった

・GCログの解析はAIが得意な作業だし、ヒープサイズやGCの種類を変えた設定を何パターンも用意して、負荷をかけて比べるのも安くなる。勘ではなく実験で決められるようになる

・ただし前回書いた通り、AIは古い時代の設定もよく知っている。たとえばCMSというGCはJDK 14で削除されていて、削除後のJDKでCMSを指定するオプションを付けると、警告が出たうえでデフォルトのGCのまま動き続ける（ここは事実）。つまりAIが古い設定を書いてきても起動は失敗せず、ログを見ないと「思っていたGCで動いていない」ことに気づけない

・なので、試す設定は使っているJDKのバージョンで有効なものか、ログで実際に効いているかまで確認する

■「なぜこう書いたか」が会話の中に消える

・AIとのやりとりで決めた設計判断はチャットの中にしか残らない。人間同士ならレビューや会議で残っていた経緯が、どこにも記録されないまま実装だけが残る

・コミットメッセージやADRに「なぜ」を残すのが今まで以上に大事になる。git logがAIにとっての記憶になる

・GCの設定も同じで、「なぜこのパラメータにしたか」が残っていないと、後で誰も触れない設定になる

■レビューする量が人間の限界を超える

・AIは人間が読み切れない量のコードを書く。全部を人が丁寧に読むのは物理的に無理

・AIに一次レビューさせて、人は契約とテストの変更、影響範囲の大きい差分に集中する役割分担になる

・PRを小さく保つことは、AIに課すべき重要なルールになる

■みんなに聞きたい

・AI前提で、要件定義や設計の進め方って変えた？

・AIが勝手に埋めた箇所、どうやって見つけてる？

・エージェントを並列で回してる人いる？作業はどう分けてる？

・モデルが変わってコードの癖が変わった経験ある？

・GCのチューニング、AIに手伝わせたことある？

・AIとのやりとりで決めたことの記録、どうしてる？

次回は最終回、結局品質をどう守るのか、を書きます。