Opus 5のSlopCodeBenchでのベンチマーク

SlopCodeBenchでのOpus 5のベンチマーク私たちは以前、モデルのコードベース品質維持能力に関する良いベンチマークがないという趣旨のことを書いてきました。それは完全には真実ではありませんでした。私は良いリードを埋もれさせるのが大好きです。先週金曜日、私はUW Madisonの@GOrlanskiの研究室による、新しめの（2026年3月）長期間コーディングベンチマークであるSlopCodeBenchを調査しました。これは、コーディングベンチマークについて私が最も気になる点、つまり「より大きく」より複雑なベンチマークでさえ、問題全体を事前に開示してしまうという点に対処しています。 対照的に、SlopCodeBenchの各チャレンジには複数の「チェックポイント」があります。モデルは問題全体を事前に知ることはなく、新しい要件が明らかにされるにつれて、コードベースを時間とともに進化させる必要があります。これは良い論文です。それほど長くはありません。読むべきです。 このベンチマークのクールな点は、飽和していないことです。実行時点では、利用可能な最高のモデルであるGPT-5.4とOpus 4.6は、それぞれ11%と17%の厳格合格率を達成しました。 slopcodebenchでのopus 5のベンチーミング 金曜日、私は3つのClaudeモデル（Opus 4.8、Sonnet 5、Opus 5）をSlopCodeBenchのサブセットで実行し、6時間ライブで監視しました。Opus 5は技術的には勝利しましたが、私の意見ではどれもあまり良い仕事はしませんでした。Fableと5.6 Solを加えて、より多くの結果を近日中に投稿します。大きな見出しは、私が実行したベンチマークの小さなサブセットでOpus 5が24%を達成したことです。これは、元の論文のOpus 4.6の17%の厳格合格率からそれほど高くありません。 テストされたすべてのモデルは、各チャレンジの過程で、冗長性、複雑性、およびその他の多くのコードスメル指標において、かなり顕著な増加を示しました。Opus 5は、同じチャレンジセットの過程でOpus 4.8の5倍の関数/呼び出し可能オブジェクトを記述しました。 この23%の合格率に対する私の個人的な解釈は、SlopCodeBenchがついに私がこれまで感覚だけでしか主張できなかったことに対して、ある種のシグナルを与えてくれたということです。つまり、実際のソフトウェアエンジニアリングの作業、一度に1つの問題を作成していくという作業においては、今日のモデルは、指示なしでは信頼できないということです。 ベンチマークサブセット Claudeにリポジトリから3つの問題を選ばせました。合計17のチェックポイントがあり、簡単な/中程度の/難しいとラベル付けされた問題の組み合わせです。 circuit_eval — 簡単（8チェックポイント） database_migration — 中程度（5チェックポイント） dynamic_config_service_api — 難しい（4チェックポイント） 最後に付録に17のチェックポイントすべてが詳細に説明されていますが、ここではすべてを記載しません。 そして、それらを3つのモデルすべてで並列に、チェックポイントごとに新しいコンテキストウィンドウを使用して実行しました。すべてのモデルは同じプロンプトを受け取り、Claudeコードハーネスで実行されました。 私が気にかけることにしたメトリックは、厳格合格です。新しいものはすべてグリーンであり、前のチェックポイントから引き継がれたすべての回帰テストを含みます。モデルがチェックポイントを失敗するのは、ソリューションに欠陥がある場合です。欠陥は、モデルの出力（実行するためのCLI、またはAPIサーバーを操作するような場合もあります）を取得し、生成されたエントリーポイントに対して保持されたブラックボックステストのセットを実行することによって検出されます。 モデルがck1のコードを記述 Evalハーネスがck1に対してブラックボックステストを実行 モデルがck2のコードを記述 Evalがck1とck2のブラックボックステストを実行 など 繰り返しになりますが、厳格合格基準は、モデルがチェックポイント4で何かをしくじった場合、その失敗したコード部分が引き継がれるため、後続のチェックポイントを通過できないことを意味します（モデルがチェックポイント6でチェックポイント4で壊れたものを誤って修正しない限りですが、実際にはそのようなことは起こりませんでした）。 9回のテスト実行すべてにおいて、どのモデルも「簡単」とマークされた問題でさえ、チャレンジの最後まで到達することはできませんでした。 sonnetの最初のチェックポイントを実行している間はコストが高かったですが、問題1の終わりまでに、sonnetは3つの中で最も安価になりました。（基本が構築され、作業がメンテナンスに移行すると、コスト削減が効果を発揮し始めたようです。） 最初​​のチャレンジでは、前世代のモデルは着実に欠陥を蓄積しました。Opus 5は、チェックポイント4と5でそれぞれ1つの欠陥を抱えました。 最初の2時間、Opus 5は厳格合格を達成した唯一のモデルでした。3回連続で開始しました。物事は進むにつれて進化しました。Claudeは熱心にHTMLを更新しました。 他のモデルと比較して、Opus 5は問題1（circuit_eval）で技術的に優れていました。しかし、最初の3つのチェックポイントをクリアした後、後続のすべてのソリューションには少なくとも1つの欠陥（テストケースの失敗）がありました。 最終結果 成功の定義を「欠陥なしで最終チェックポイントに到達すること」とすると、Opus 5は3つの問題すべてで失敗しましたが、他のモデルよりもわずかに失敗の程度が低かったです。 コスト対欠陥レポートについて、私はClaude特有の表現を本当に嫌いますが、これは残すことにしました。1ドルあたりで正確性が購入されました。しかし、誰も十分な量を購入しませんでした。（明らかに、この小さなサブセットのベンチマークでは、より多くのお金を費やすことがより高い合格率につながることを決定的に示すことはできません。） 厳格合格に関しては、Opus 5は4回（24%の合格率）達成しました（circuit_evalの最初の3つのチェックポイント、およびdatabase_migrationのチェックポイント1）。Opus 4.8とSonnet 5はどちらも1回の厳格合格（6%の合格率）を達成しました。これはOpus 5が達成したdatabase_migrationのチェックポイント1と同じです。したがって、勝者は17のうち4をクリアし、そのうち3つは1つの問題の最初のチェックポイントでした。 次のフロンティアのモデルのために、飽和していないベンチマークがあるようです。@GOrlanskiとチーム、素晴らしい仕事です。 スロップメーター 私はまだ「リンティングでスロップを洗い流す」という考えに完全に納得していません。なぜなら、特定のコードベースチェックポイントの「保守性」を決定論的に解析することがまだ可能であるとは考えていないからです。しかし、コード品質メトリックに注目するのは興味深く、おそらく方向的には正しいでしょう。 SlopCodeBenchを使用すると、各チェックポイントの後にさまざまな品質メトリックの結果が得られます。結果ファイルには41個あります。大まかにグループ化されています。 サイズ — ソース行数、ファイル数、関数数、メソッド数、クラス数、ステートメント数、およびそのチェックポイントで追加または削除された行数 複雑性 — サイクロマティック複雑度の平均、最大、分散、高帯域および極端帯域に入る関数の数、複雑度の集中度、最大ネスト深度、平均関数長 重複 — クローンされた行数、およびソースに対するクローン行の割合 分解 — 単一使用関数、トリビアルラッパー、未使用変数、シンボルあたりの行数 ルール違反 — リンターエラーとその自動修正可能性、テストスロップルールに対するast-grepヒット、およびフラグ付けされた行の割合 冗長性 — 依存関係グラフの伝播コスト（変更がどれだけ波及するか）、循環依存関係の質量、依存関係エントロピー（おそらく私にとって最も興味深いもの） これらのそれぞれは、各チェックポイント後の現在のコード状態を使用して決定論的に計算されます。 以下のチャートは、circuit_evalチャレンジのck1スコア対ck8におけるモデル間のばらつきを示しています。（つまり、チャレンジチェックポイントのライフタイム中にスロップインジケーターがどれだけ増加したか。） 最も興味深いのは、ほとんどのメトリックがモデルを区別しないことです。これらの測定値が繰り返し可能であり、判断にモデルを使用しないことを気に入っています。しかし、それらのいずれかと「このコードベースは変更や進化が容易であるか」との関連はまだ確立されていません。 より多くの正確性が、はるかに多くのコードの代償を払ってきました。 しかし、その多くは「より多くのテスト」でした。実際のプロダクションコードの量は、Opus 5対Opus 4.8で約1.8倍です。 私の推測は…直接的にあまり良い結果につながらなかった高価な冗長性です。これがモデルのシグナルなのか、それとも「これは本当に難しい問題であり、これだけのコードが必要とされる」というだけなのかを知るために、さらに深く掘り下げる必要があります。 書かれたコードのほぼすべてがスロップメーターに引っかかりました。 すべてのモデルで、コード行の大部分がベンチマークのスロップルールの少なくとも1つに引っかかりました。3つの問題全体の平均： opus 4.8 — 98% opus 5 — 93% sonnet 5 — 89% そして具体的には、冗長すぎるとフラグ付けされた行は、すべてのモデルで軌跡全体で増加し、ck1で約65%からck8で80%近くになります。Opus 5でさえです。 実際、これはコード品質測定値の一部が少し攻撃的すぎる兆候であると私は言うでしょう。私は調べました