AI-generated code を盲信しないために、どのように review しますか？

Question

Accepted Answer

AI-generated code は、**自信はあるが fallible な author からの draft** です。正しく見えて compile することも多いですが、subtle bug、invented API、security hole を隠している場合があります。discipline のある review が speed と risk の balance を保ちます。

## review checklist

- **every line を読む**。skim すると、後で説明できない bug を ship します。例外はありません。
- **actual problem を解いているか verify する** — 似た問題ではなく本当の問題。AI は correct ではなく plausible に最適化します。
- **test と linter を走らせる**。気にする case の test を追加します。AI 自身の test も盲信しません。
- **edge case を確認する** — empty input、null、large values、concurrency、boundary conditions。
- **security を確認する** — SQL/command injection、unsanitized input、code 内 secret、unsafe deserialization。
- **performance を確認する** — accidental O(n²) loop、N+1 query、unbounded memory。
- **API が存在するか確認する** — AI は実在しそうな method name や library function を hallucinate します。
- **理解していない code を貼らない**。説明できない code は maintain も debug もできません。

## 実用的な flow

```text
1. Read the diff fully  →  do I understand every line?
2. Does it solve the real problem, including edge cases?
3. Run: tests + linter + type checker
4. Scan for security + performance red flags
5. Only then: commit (with a message that reflects what it really does)
```

AI は速い junior developer のように扱います。helpful で productive ですが、land する前に必ず output を review します。shipped code の責任は model ではなくあなたに残ります。

## なぜ重要なのか

AI code の危険は明らかに壊れていることではなく、casual glance を通過しながら bug や vulnerability を抱えたまま *plausibly* broken であることです。every line を review し、test を走らせ、理解していない code を ship しないことが、AI を force multiplier として使うことと、説明できない technical debt/security risk を静かに積むことを分けます。