ニュース一覧AIにコードをより遅く、しかしより正確に書かせる方法:マルチモデルPRレビューでバグ発生確率を最小限に抑える
動區 BlockTempo2026-05-26 03:34:37

AIにコードをより遅く、しかしより正確に書かせる方法:マルチモデルPRレビューでバグ発生確率を最小限に抑える

ORIGINAL如何讓 AI 程式寫得更慢,但更正確:多模型 PR 審查,讓 Bug 機率壓到最低
AI 影響分析Grok が分析中...
📄原文全文· trafilatura により自動抽出Gemini 翻譯1534 文字
元Microsoftシニアエンジニアの Nolan Lawson は、Claude、Codex、Cursor Bugbot の3つのモデルを同期させてPRをレビューし、クロス検証によって誤検知率をほぼゼロにまで抑えている。 (前回のあらすじ:Claude Code は週次の Token 使用上限を50%引き上げると発表!2ヶ月間にわたり Anthropic は開発者エコシステムの獲得に動く) (背景補足:Stripe が AI Agent による全自動決済テストを開始:x402 を介して Base チェーン上の USDC 決済をサポート) 我々は AI coding の利点が「大量のコードを素早く生み出す」ことだと知っているが、その正確性については議論の余地がある。元 Microsoft、Salesforce のシニアエンジニアである Nolan Lawson は最近、ブログで新しいワークフローを記録している。彼は複数の大規模言語モデルを同期させて、すべての pull request(コードマージリクエスト、簡単に言えば新しいコードをプロジェクトに送り込むあらゆる動作)をレビューする。その目的は、より多くのコードを素早く生み出すことではなく、クロス検証によって本物のバグを見つけ出すことにある。 このワークフローによって彼のコード生産量は増えなかったが、コードの品質は明らかに改善された。 Anthropic が今年立ち上げた Glasswing 計画(Mythos システムの公開アップデート)が、このロジックに直接的なデータ基盤を提供している。 このシステムは LLM agents に、実在するオープンソースのコードを大規模にスキャンさせる。結果として、1,000を超えるオープンソースプロジェクトをスキャンした後、システムは6,202件の高深刻度または致命的な脆弱性を発見したと推定し、合計23,019件の脆弱性(低深刻度を含む)が確認された。そのうち、独立した情報セキュリティ会社によって一つひとつ検証された1,752件の脆弱性のうち、90.6%が本物の問題であると確認され、62.4%が高深刻度または致命的レベルに属していた。 これらの数字は、根本的な転換を物語っている:バグを見つけることはもはやボトルネックではなく、検証と修正こそがボトルネックなのだ。 Anthropic は研究報告書の中で明確に記している:「ソフトウェアセキュリティの進歩は、かつては脆弱性を見つける速度によって制限されていたが、現在は検証、開示、修正の速度によって制限されている」。言い換えれば、AI は問題のボトルネックを「発見」から「処理能力」へと押し進めたのだ。 Lawson の核心的なやり方は、単一のモデルに依存するのではなく、異なるベンダーの複数のモデルを同時に走らせて PR レビューを行わせることである。 彼のツールの組み合わせには、Claude code、OpenAI の Codex、そして Cursor Bugbot が含まれており、これら3つが同じ pull request に対して完全に独立したレビューを同期的に行い、その後すべての結果を集約して、critical(致命的)、high(高)、medium(中)、low(低)の4つの深刻度レベルに従って並べて出力する。 このマルチモデルによるクロス検証の設計には、ある重要な特性がある:単一のモデルでは誤検知が出やすいが、異なる訓練データとアーキテクチャから来た複数のモデルが同時に同じ問題を指摘するならば、誤検知率は大幅に低下し、同時にカバレッジは向上する。Lawson 自身の言葉を借りれば:「誤検知率はほぼゼロで、見つけたバグのカバレッジは非常に高い」。 彼の意思決定プロセスはかなり明確だ。すべての critical と high の問題は必ず先に修正する。medium と low については「修正コスト」と「実際の影響」の比率を個別に評価し、見合わないものは直接スキップして開発リソースを浪費しない。もし1つの PR に critical の問題が多すぎる場合は、根本的な問題のある基盤の上に継続的にパッチを当てるのではなく、丸ごと諦めてやり直す。 このワークフローを使った後、Lawson の実際の結果はこうだ:コード出力量(行数)は増えなかったが、むしろ既存の古いバグを掘り当てることが多くなり、unit tests(単体テスト、簡単に言えば各小機能を個別に検証する自動化テスト)を書かざるを得なくなり、古い問題の修正に費やす時間が新機能の推進よりはるかに多くなることがしばしばだった。 これは彼が予期した結果ではなかったが、別の角度から見れば、これはコードベースの健全性が体系的に補強されているシグナルなのだ。 Lawson はこの働き方を「より質感のある vibe coding」と呼んでいる。慎重で、方法論を持ち、品質志向だ。 開発ツールの普及は通常、「速度」をセールスポイントの最前面に置くが、エンジニアが本当に解決すべき問題は、決して速度だけではない。すべてのコードの行にはそれぞれの保守コストがあり、それぞれの問題発生確率がある。AI を使ってコードを書くスピードは遅くなるが、コードの一行一行をより長く生存させ、問題が発生する確率をより低くするのだ。
データステータス✓ 全文抽出済み原文を読む(動區 BlockTempo)
🔍過去の類似イベント· キーワード + 銘柄照合1 件
💡 現在はキーワード + 銘柄照合(MVP)を使用しています · 今後 embedding セマンティック検索へアップグレード予定
原始情報
ID:f2feed2ef3
ソース:動區 BlockTempo
公開:2026-05-26 03:34:37
カテゴリ:zh_news · エクスポートカテゴリ zh
銘柄:未指定
コミュニティ投票:+0 /0 · ⭐ 0 重要 · 💬 0 コメント