マージする前に、AI生成コードをレビューする方法
流暢なコードは正しいコードではありません。AIパッチは提案です。急いだ同僚の変更と同じレビューを生き延びる必要があります。
Deni AIチーム
自信ではなくパッチを見る
AI生成コードは、コメント、移行計画、安全だという落ち着いた説明つきで来ることが多いです。その包装は証拠ではありません。証拠は実行できる差分です。
生成パッチは、リポジトリを見たことがない人のプルリクエストと同じに扱います。境界は推測だと仮定し、そうでないことを証明します。
正しいファイルに触れましたか？
パッチを書く前に、ファイル名を言わせてください。関係ないモジュールへ迷うなら、下書き全体をスケッチとして扱います。範囲の誤りは、論理の誤りより安く見つかります。
すぐ実行できますか？
変更を貼ってテスト、型、アプリを回せないなら、パッチではありません。パッチの説明です。文章を差分のようにレビューしないでください。
何を捏造しましたか？
貼った抜粋にない新しいヘルパー、フラグ、環境変数、エンドポイントを見てください。捏造APIはコーディングモデルの既定の失敗であり、珍しいバグではありません。
書き直したほうが速いですか？
下書きが既存の流儀と争い、テストを無視し、ファイルごとに一段落の掃除が要るなら捨ててください。悪いAIパッチへの忠誠は、失敗するテストから始めるより時間がかかります。
安く済むレビューの順番
まず、意図する振る舞いを一文で確認します。モデルとその一文を共有できなければ止めてください。さらにコードを頼むと、誤解が装飾されるだけです。
次にファイル一覧と公開API。良いパッチは退屈です。振る舞いを載せられる最小面だけ変えます。悪いパッチは、新しい考えを入れるために隣をリファクタします。
3番目に、失敗しうる最小の確認を走らせます。単体テスト、型検査、その変更が触る画面。読んだだけで走らせないことが、捏造ヘルパーを生き延びさせます。
セキュリティは後回しではない
新しいネットワーク呼び出し、緩んだ認証、ログに出る秘密、頼んでいない依存を引く貼り付けに注意してください。モデルは「話の中では動く」を最適化します。あなたの脅威モデルではありません。
認証、課金、ユーザーデータに触れるなら、人のレビューが製品です。モデルはパッチを提案できます。リスクは引き受けられません。
マージ前の確認
- 振る舞いは、合意できる一文になっている。
- ファイル一覧は小さく、パッチの前に名前がある。
- リポジトリに根拠のない新しいAPI、フラグ、環境変数が増えていない。
- テストか手動の経路を、説明だけでなく実行した。
- 明日チャットが消えても、変更を理解できる。
マルチモデルの作業場との関係
Deni AIではコーディング向きのモデルから始め、最初の答えが制約を説明できないときだけ切り替えます。ワークスペースはその切り替えのためです。型検査の代わりではありません。
コードだけでなく事実や引用の検証方法が必要なら、AIの答えを検証するガイドを使ってください。習慣は同じです。失敗を名指しし、チャットの外で確認する。
よくある質問
テストもモデルに書かせるべきですか？
書けます。そのあと実行してください。同じ推測で作ったテストは、同じ死角を共有します。説明できない緑より、理解できるテストを優先してください。
コーディングモデルだけで足りますか？2つ目が要りますか？
最初のパッチはコーディング向きのモデル。タスクが曖昧、または最初の答えが制約を言えないときだけ2つ目を使います。2モデルを走らせても、コード実行の代わりにはなりません。
AIコードをレビューする価値がないのはいつですか？
期待する振る舞いを言えないとき、またはすでに知っている1行の変更のときです。レビューコストが、自分で書くコストを超えてはいけません。