AI にゼロから code を書かせるべき時と、review/refactor だけに使うべき時はいつですか？

Question

Accepted Answer

経験則は、間違いが安く明らかな場所では AI に**書かせ**、間違いが高くつく、または subtle な場所では **review/refactor** に使うことです。決め手は、output を verify する cost です。

## ゼロから書かせてよい場合

- **Greenfield と boilerplate** — 新しい util、config file、CRUD endpoint、regex。壊す hidden context がありません。
- **不慣れな API/library** — AI はあなたが知らない library surface を知っており、あなたは docs で verify します。
- **Throwaway/prototype code** — perfection より speed が重要です。

これらでは bug の cost が低く、結果を上から下まで読めます。

## review/refactor だけに使う場合

- **Business-critical logic** — billing、auth、money math。もっともらしい誤答は危険です。
- **Subtle code** — concurrency、security、edge-case-heavy algorithms のように、「正しく見える」と「正しい」が違う領域。
- **Large existing systems** — AI は codebase が依存するすべての invariant を見られないため、生成 code の挿入は silent breakage の risk があります。

ここでは AI を **second pair of eyes** として使います。AI が提案し、あなたが決めます。

```text
                 Cost of a bug LOW          Cost of a bug HIGH
New code          ✅ let AI write           ⚠️ AI drafts, you verify hard
Existing code     ✅ AI refactors           ✅ AI reviews, you write the change
```

## Tradeoffs and risks

ゼロから書かせるのは速いですが、AI は API を invent したり（**hallucination**）、見えない context を missed したりします。review は安全ですが遅く、与える context の質に依存します。どちらの場合も、あなたが **accountable author** です。AI は tool であり、commit の署名者ではありません。

## なぜ重要なのか

ここを見誤ると AI-assisted dev は失敗します。完全に verify できない critical logic を AI に生成させたり、AI が数秒で作れる trivial boilerplate を手で書いたりするからです。mode（**write** vs **review/refactor**）を **間違ったときの cost** に合わせることで、安い作業では速く、危険な作業では慎重でいられます。問われている skill は AI prompt ではなく、verification effort をどこに使うかの judgment です。