AIを、可読性・バグ・セキュリティについて厳しいレビュアーに仕立て、その指摘に対して自分の選択を弁護することで判断力を磨こう。
このレッスンを Kodokon で開く同僚によるコードレビューは、この分野で成長を加速するものとして最もよく文書化されたもののひとつだ - そして一人で働くとき最もアクセスしづらいもののひとつでもある。AIは、ひとつの条件のもとで、24時間いつでも使えるレビュアーを提供してくれる。その条件とは、あなたがそれを設定しなければならないということだ。デフォルトでは、モデルは従順だ。あなたの努力を褒め、些細なことを2つ指摘し、「全体としてよくできている」と結論する。それはレビューではなく、肩を叩いているだけだ。裏返しの間違いは「私のコードをきれいに書き直して」と頼むことだ。あなたは自分では考え抜いていないコードを手にし、何も学ばない。正しいやり方はこうだ。構造化された批評を要求する - 可読性、バグ、セキュリティ - 較正された深刻度と根拠つきで。
あなたは、チームのコードレビューにおけるような、厳しいシニアレビュアーです。あなたの目的は私を上達させることであって、私に手加減することではありません。
これが私のコードです([言語]、コンテキスト: [何のためのものか、そのプロジェクトの制約]):
[コードを貼り付け]
以下の3つの軸で分析してください:
1. 可読性: 命名、構造、不要な複雑さ、意図の不明瞭さ。
2. バグ: 未処理のエッジケース、握りつぶされたエラー、一貫しない状態、並行性。
3. セキュリティ: 検証されない入力、インジェクション、露出した機密データ、権限。
出力形式: 指摘ごとに - 該当する行またはブロック、軸、深刻度(ブロッカー / 重要 / 軽微)、そして「なぜ」を1文か2文で。
制約: 私のコードを書き直さないでください。指摘は最大8件まで、最も深刻なものを先に。コンテキストによっては議論の余地がある選択を弁護できる場合は、それを欠陥として数える代わりに、その旨を明示してください。深刻度の順に並べた8件までの指摘という上限に注目してほしい。これがないと、25個のあら探しが返ってきて、抜けた入力検証が命名の好みと同じ重みになってしまう。弁護できる選択についての条項にも注目しよう。これはモデルに、客観的な欠陥と議論の余地のある慣習とを区別することを強いる。次に来るのが最も鍛えられる部分、ほとんど誰もが飛ばしてしまう部分だ。自分の選択を弁護すること。レビューは適用すべき判決ではなく、対話だ。ある指摘が不当に思えたら、反論しよう。あなたの理由が通れば、それをようやく言葉にできたことになるし、崩れれば、その「選択」が単なる習慣にすぎなかったと気づくことになる。
あなたの指摘の[X]番を改めて取り上げましょう。あなたは[指摘を言い直す]と考えています。
私は同意しません。理由は以下のとおりです: [あなたの論拠 - 計測したパフォーマンス上の制約、コードの他の部分との一貫性、意図的な単純さ、締め切り…]。
1. 私の各論拠を正直に評価してください: どれが通り、どれが後付けの正当化ですか?
2. 私の立場に対して考えうる最も強い反論を、同意しない経験豊富な同僚がするように挙げてください。
3. 結論を出してください: 私の具体的なコンテキストにおいて、この変更はそのコストに見合いますか? はいかいいえで答え、そのあと3文以内で根拠を述べてください。
私を正しいと証明しようとしないでください: 私の論拠が弱いなら、はっきりそう言ってください。AIレビューの典型的な罠が2つある。1つ目の罠: 確信をもって届けられる誤警報だ - モデルは、あなたのアーキテクチャでは起こりえない競合状態を指摘したり、あなたの言語のバージョンでは実はバグではない「バグ」を指摘したりする。すべての指摘を、全コンテキストにアクセスできない優秀な同僚から来たものとして扱おう。もっともらしいが、検証が必要だ、と。2つ目の罠: セキュリティ劇場。AIは古典的なパターン(SQLインジェクション、XSS、平文の秘密情報)を見つけるのはとても得意だが、ビジネスロジックの欠陥は見逃す - あるルートに欠けている認可チェック、悪用可能な中間状態など。AIレビューは補完するものであり、監査もあなたのドメイン知識も置き換えはしない。