1. メンバーへのレビュー指摘 ≒ AIの改善
AI駆動開発において、メンバーへのレビュー指摘は、その指摘されたメンバーの知識だけの問題ではなく、
開発環境がうまく整備されていないという場合があります。
レビュー指摘だけで終わらず、開発環境の整備によってよりそのチームでのコード品質向上につなげられると考えています。
2. 指摘からの改善できる観点
コードレビューで指摘となるのは、命名規約、共通関数の使用など様々あります。
これらの指摘をする必要がないように、
AI駆動開発での改善と聞くとまずAIプロンプト系の調整が思い浮かぶかと思いますが、
静的解析系の改善も場合によっては役に立つかと思います。
以下改善観点です。
AIプロンプト系の改善
規約・方針・手順を、AGENTS.md・CLAUDE.md・skill・rulesといった、AIが読む形式で、記載。
次回以降は指摘することなく良いコードを書いている可能性が高いです。
同じAIを使っている限りは整備できていれば効果的です。特有のAI特有の指示ファイル系はそのAIでしか使えないため、メンバーが他のAIを使ったりすると意味は薄くなります。
静的解析の強化（型・コンパイル・lint）
機械で強制できるものはここに寄せます。型で表せるルールは型にする、禁止したい書き方やAPIはlintルールにする。壊れればコンパイルやCIが通らないので、人もAIもすり抜けられません。
AIはこのエラー結果などを読んで修正することで、PR作るときにはこれらが解消した状態で出せます。
※ただ抑制設定などをAIが書けてしまって無理やり通ったように見せるなどもあるので、抑制自体も制御するかどうかも考慮が必要です。
3. 静的解析(自動コード生成など)かAI調整か
基本的には、静的解析でできるものは静的解析でチェックさせ、自動修正までできるものは、そのツールでやらせるのが良いと思います。
AIはどこまでいっても確定的ではないので、従来の静的解析系でチェックさせるべきです。
context windowの拡大や、セッション要約、skillsやrulesなどの条件付きプロンプト読み込みによって、
文脈保持や理解という観点では、だいぶAIもましになっていますが、
やはり確定的ではないです。
静的解析で制御が難しい場合は、AIに寄せるという形が良いと思います。
また静的解析だけでなく、自動コード生成系も有効です。
4. さいごに
個人のレベルや知識だけを問題にするだけでなく(個々人のレベルももちろん大事ですが)、
「誰が書いても一定水準になる環境」をどう作るかが重要です。(AIによってその水準が引きあがったと思いますがより高めるために。)
特に未経験や非エンジニアに開発をやらせるような環境であればなおさらその意識があると良いかと思います。後は新しい言語フレームワークに挑戦などの環境など。
その作られた開発環境は
その人がいなくなっても恩恵を受けられる、継続的な価値になると思っています。