Using AI to write better code more slowly

📄 Summarized by Claude Sonnet 4.6

2026-05-25

どんなもの？

LLMを使ったAIコーディングは「低品質なコードを高速に生産する」ためのツールだという通説に反し、むしろ「高品質なコードをゆっくり書く」ためにも同様に有効だと主張するエッセイ。Nolan Lawson（Socketエンジニア）が自身のコードレビューワークフローを紹介し、バイブコーディングの別の形を提案する。

先行研究と比べてどこがすごい？

AnthropicのMythosプロジェクトや複数モデルを用いたPRレビュー手法（Milvusブログの知見）を実践に取り込んでいる点が特徴。単一モデルによるレビューではなく、複数の異なるLLMエージェントを並列実行して結果を統合することでハルシネーションや偽陽性（false positive）を排除する仕組みを個人ワークフローに落とし込んでいる。

技術や手法のキモはどこ？

筆者が構築したClaudeスキルの構造が核心：

Claudeサブエージェント・Codex・Cursor Bugbotの3エージェントを並列実行し、バグを critical / high / medium / low でランク付け

全エージェントの結果が揃った後に、メインエージェントが偽陽性を除外して最終レポートを生成

スキルにはKISS原則・DRY原則・アクセシブルなHTML/JSX・SQLインデックス適切化なども判定基準として定義

コメントの間でコンテキストをリセットすることで各エージェントの独立性を保つ（レビュアーが先行結果に引きずられるのを防ぐ）

発見されたバグへの対処方針：critical/highは全修正→繰り返し、コスト対効果が低いmediumはスキップ、criticalが多すぎる場合はPR全体を廃棄

どうやって有効だと検証した？

筆者の個人的実践とコメント欄での他エンジニアの追認（heckjによる「複数スウィープ＋コンテキストリセット」の有効性報告）が根拠。定量データはなく、経験則・ケーススタディベース。偽陽性率がほぼゼロに近いと報告している。

議論はある？

速度トレードオフ：この手法では「10x生産性」は得られず、むしろベロシティが下がる可能性がある。PRに含まれない既存バグの修正やユニットテスト作成に脱線することも多い

定量根拠の欠如：実証データではなく個人経験に基づいており、再現性・一般化可能性は不明

対象読者の限定性：AIコーディング懐疑派を説得する意図はないと明言しており、すでにエージェントを活用している開発者へ向けた提案

コメントから：レビュアーを「フロントエンド／バックエンド／インフラ」などドメイン別アーキタイプに分割する手法も有望という示唆あり（実証未）