AIコーディング、速さよりレビュー設計が論点に

Nolan Lawsonの記事は、AIコーディングを単なる高速化の話に閉じ込めない。LLMはコードを速く出す道具にもなるが、同じくらい重要なのは、コードを遅く、しつこく検査する役割だ。生成量ではなく、欠陥をどれだけ早い段階で見つけられるかに価値を置く。

提案されている流れは、複数のモデルやツールを同じPRに当て、バグ候補を集めたうえで人間が整理するものだ。Claudeのsub-agent、Codex、Cursor Bugbotのように性格の違うレビュワーを並べると、単一モデルの誤検知や見落としを減らしやすい。重要なのは自動修正ではない。優先順位付け、再現確認、プロジェクトの設計方針との整合性を人間が見る点にある。

Hacker Newsのコメントでも、実務の細部が話題になった。設計を音声やチャットで詰め、仕様に落とし、実装後に別セッションのモデルでエラー処理や並行処理、境界条件を確認するという使い方が共有された。一方で、エージェントが目標へ急ぎすぎると、開発者が普段コードを書きながら行う小さな設計判断が抜け落ちるという懸念も出ている。

ここから見えるのは、AIコーディングを一つの作業として扱わないほうがよいということだ。草案作成、コードレビュー、テスト観点の洗い出し、セキュリティ確認、設計への反論はそれぞれ別の仕事である。モデルに任せる範囲を分ければ、速さだけでは測れない価値が出る。遅いレビューの反復は手間に見えるが、本番前に不安を見つけるための現実的な工程でもある。

出典はNolan Lawsonの記事。コミュニティでの議論はHacker Newsスレッドで確認できる。