AIを使ってより良いコードをよりゆっくり書く: バグ発見ワークフロー

AIによる粗製濫造にうんざりしている開発者には、Nolan Lawsonの別のアプローチが役立つかもしれません。LLMを使って、より遅く、より良いコードを書く方法です。重要なのは、複数のエージェントをPRレビューに投入し、重要度順にバグを見つけ、体系的に修正することです。

仕組み

Lawsonは、別の記事の核心的な洞察から派生したClaudeスキルについて説明しています。PRレビューに使うモデルが多ければ多いほど、幻覚や偽のバグが減るというものです。このスキルは、Claudeサブエージェント、Codex、Cursor Bugbotの3つのエージェントを実行し、PR内のバグを致命的/高/中/低の重要度でランク付けします。終了後、結果を確認し、誤検出を除外して、最終レポートを作成します。

「バグ」の定義は自分で決めます。Lawsonの定義には、KISS/DRY原則、アクセシブルなHTML/JSX、適切なSQLインデックスなどが含まれます。偽陽性率はほぼゼロで、このスキルは常に大量のバグ（致命的なセキュリティ問題から誤解を招くコメントまで）を発見すると主張しています。

典型的なワークフロー

• エージェントに致命的および高重要度のバグをすべて修正させ（適切な解決策をガイドしながら）、残りがなくなるまで繰り返す。
• 修正の労力（例：狭いエッジケースのために100行）に見合わない中重要度はスキップする。
• 致命的なバグが多すぎてアプローチ自体が誤っている場合は、PRを破棄する。

レビュープロセスでは、既存のバグが見つかることも多く、単体テストの作成や微妙な欠陥の修正といった、本筋からそれた副次的な作業が発生します。これは10倍の生産性を謳う粗製濫造開発とは正反対ですが、コードベース全体の健全性を向上させ、障害モードへの理解を深めます。

AIコーディングに懐疑的な人には、この記事は説得力を持たないでしょう。しかし、自分でもよく理解しないまま数百行のPRを量産しているなら、Lawsonは立ち止まるよう勧めます。エージェントにPRの動作や失敗の可能性を尋ねたり、Mermaidチャート付きのMarkdownドキュメントを書かせたり、Matt Pocockの/grill-meスキルを使ってPR全体を完全に理解するまで試してみてください。

Hacker Newsでの関連議論: HNスレッド（748ポイント、288コメント）。