特に production code で、AI の回答が trust できるかをどう判断しますか？

Question

Accepted Answer

AI の回答は、**知識はあるが unreliable な colleague からの confident draft** として扱います。有用で正しいことも多いですが、それ自体は authority ではありません。trust は output の説得力ではなく、*verification* から生まれます。

## core mindset

**Confidence is unrelated to correctness.** LLM は真実かどうかに関係なく fluent text を生成します。next-token predictor であり fact store ではありません。hallucinated API と real API は同じように読めます。したがって tone で trust を判断できません。confirm できるものだけで判断します。

## practical checklist

- **Run it.** code では execution が最も強い signal です。tests、type checker、linter、compiler。実 test suite を pass する code は、見た目が正しいだけの code より trust できます。
- **hallucinated APIs を確認する**。function、method、flag、import が docs や installed version に実在するか verify します。
- **authoritative sources と照合する**。official docs、standard、source code と cross-check し、model 自身の言い換えを根拠にしません。
- **edge cases and security を考える**。null/empty inputs、concurrency、error paths、injection、authz。AI は happy path を扱い dangerous corners を落としがちです。
- **confirm できるものを優先する**。test や lookup できる approach を、opaque な clever solution より選びます。
- **critical paths では human review を必須にする**。auth、payments、data deletion、migrations、infra は、見た目が良くても system を理解する人間が approve します。

## quick rule

```text
Verifiable + verified        → trust
Verifiable + not yet checked → verify before using
Not verifiable               → don't depend on it
```

## なぜ重要なのか

production では、明らかに壊れた answer より、*正しく見える* wrong answer の方が危険です。AI がより多くの code を書くほど、bottleneck は *generating* から *validating* に移ります。senior judgment とは、fluency が evidence ではなく、model の confidence が correctness について何も語らないと知り、tests、sources、human review で trust を獲得させることです。