Parsimony: AIコーディングエージェントが追加するコード量を測定するオープンソースのベンチマーク

Parsimonyは、AIコーディングエージェントがタスクを解決する際に追加するコード量を測定するオープンソースのベンチマークです。タスクを解決したかどうかだけでなく、どれだけのコードを追加したかを評価します。既存のベンチマークが公開しているパッチを再利用し、行数ではなく構文レベルの「コーディングユニット」を数え、削除されたコードを差し引いて、DeepSWE Python、JavaScript、TypeScript、Go、SWE-bench Verified、SWE-bench Live Lite、SWEeper-Bench PHPのリーダーボードでモデル間で比較できる正味の数値を算出します。

このプロジェクトの動機は、既存のベンチマークが解決率とコストのみを測定し、過剰なコードを罰しないことです。過剰なコードは長期的にコードベースを扱いにくくします。

Parsimonyがパッチをスコアリングする方法

Parsimonyは、コーディングユニット（文、呼び出し、比較、名前、リテラルなどの構文要素）を数えます。行数ではなく構文要素を数えることで、コードを少ない行に詰め込んでも評価されず、削除されたコードが差し引かれるため、報告される数値は正味の値になります：正味ユニット = 追加 − 削除。

Parsimonyは何も実行しません。公開された各パッチがタスクのコードに適用され、変更された各ファイルの両バージョンが解析されます。テスト、ドキュメント、生成ファイルはカウントから除外されます。合格/不合格の結果は、ソースベンチマークの公開結果から取得され、テストは再実行されません。

プロジェクトのMethodセクションには「Pythonのみが測定される」と記載されていますが、サイトにはJavaScript、TypeScript、Go、PHPのリーダーボードも公開されています。これはソースページの明らかな矛盾であり、文書化された制限ではありません。

リーダーボードと再現性

Parsimonyは7つのリーダーボードを公開しています：DeepSWE Python、DeepSWE JavaScript、DeepSWE TypeScript、DeepSWE Go、SWE-bench Verified、SWE-bench Live Lite（「Live Python」として表示）、SWEeper-Bench PHP。

各リーダーボードは、プロジェクトのGitHubリポジトリ内のレポートとマニフェストにリンクし、マニフェストとデータセットの両方にSHA-256ハッシュを提供します。例えば、DeepSWE Pythonマニフェストのハッシュはc16b15f80c140ffb4f0a548886962dda4173a02893a65b7faa1d6796940ecf65、データセットのハッシュは41a44998c70248e0a3e2a4cf43a8838b70248537d1f3a458838f2f7e09ecef8aです。自己実行リーダーボードには、使用されたDeepSWEコミット0b9fabbb63b9104d678fe965e1632f2dd9eaa2eaも記録されています。

DeepSWE Pythonの結果：34タスクで26モデル

メインのDeepSWE Pythonボードは、34のDeepSWEタスクで26モデルをカバーし、モデルあたり136回の試行（タスクあたり4回）があります。モデルは、解決したタスクで追加された平均正味ユニット数でランク付けされ、少ない順に並びます。サイトは、失敗した試行を含む2番目の平均、DeepSWEから取得した解決率、および2026-10-08日付のArtificial Analysis Intelligence Indexも報告します。これはモデルと推論努力によって一致する外部スコアであり、ランキングには影響しません。

サイトの表は数値列にラベルを付けていません。以下のラベルは、サイト自身のランキング指標と解決/測定カウントの説明に従っています。

ランク モデル 平均正味ユニット（ランキング指標） 平均正味ユニット（失敗試行含む） 解決率 AAインテリジェンス指数 測定数
1 Gemini 3.1 Pro Preview (high) 1479.5 1156.3 8.1% 29.7 11/11
2 Claude Fable 5 (xhigh) 1557.5 1509.1 74.3% — 97/101
3 Gemini 3.5 Flash (high) 1621.5 1707.6 29.4% 32.6 38/40
4 Claude Opus 4.8 (max) 1621.9 1592.2 63.2% 41.8 83/86
5 Kimi K3 (max) 1641.2 1601.1 67.6% 43.6 89/92
6 Claude Sonnet 5 (max) 1665.9 1563.5 59.6% 38.2 78/81
7 Claude Sonnet 4.6 (high) 1684.5 1587.9 29.4% — 36/40
8 Qwen3.8 Max (xhigh) 1697.8 1770.5 55.1% 45.4 74/75
9 GLM-5.2 (max) 1733.2 1591.3 41.9% 33.7 53/57
10 Kimi K2.7 Code 1737.3 1600.1 24.3% 25.8 32/33

ランク付けされたボードの最下位は、ランク26のMuse Spark 1.1 (xhigh)で、平均2562.3正味ユニット、解決率52.9%、ランク25のMuse Spark 1.2 (xhigh)で、2484.1正味ユニット、解決率50.7%です。Claude Opus 5 (max)はランク23で、2183.4正味ユニット、解決率74.3%です。

ボード上の2つのモデルにはArtificial Analysisスコアがありません：Claude Fable 5 (xhigh)とClaude Sonnet 4.6 (high)です。

自己実行モデルは表示されるがランク付けされない

Parsimonyはまた、著者が個人的に最初の3〜10のDeepSWE Pythonタスクで実行したモデルのフェード表示セットも表示します。OpenAIモデルにはpi、AnthropicモデルにはClaude Codeを使用し、各タスクの独自テストで評価されます。これらの実行は明示的に検証されておらず、ランク付けもされていません。

そのセットでは、GPT-6 Luna (high)が平均1076.3正味ユニット、解決率15.0%（3/3測定試行）で最低の平均を示し、GPT-6 Astra (high)は1103.0正味ユニット、解決率66.7%（4/4測定試行）です。GPT-5.6 Sol (high)は自己実行セットと公開ボードの両方に表示されます。サイトは、著者の実行が公開実行の0.88倍のコードを追加したと注記しています。

指標の明示された限界

Parsimony自身のLimitsセクションは、この数値が意味しないことについて異常に率直です。

  • 小さいことが常に良いとは限らない：ユニットはサイズを測定し、可読性や設計を測定しない。
  • より多くのコードを書くモデルは、より多くのタスクを解決する傾向があり、26以上のモデルを含むボードではスピアマン相関が0.33〜0.60です。
  • すべてのモデルが同じエージェント（mini-SWE-agent）を使用しますが、エージェントはそれでも書かれるコード量に影響します。

サイトは、同じ関数の2つの実装でサイズと可読性の違いを説明しています。foundフラグを設定するループベースのhas_negativeと、1行のany(value < 0 for value in values)バージョンは同じ結果を返しますが、短いのは一方だけです。

コミュニティの反応：parsimony対可読性

Hacker Newsの議論では、低いユニット数を良いコードの代理として扱うことに反対しました。最も直接的な反対意見は、著者自身のランク付けされていない実行で勝ったモデルが読みにくいコードを生成するというものでした。

「一方で、LLMがコードベースにまき散らす冗長さを測定し減らすべきだという点には完全に同意します。他方で、Astraがこのベンチで『勝っている』という事実は、私にとっては良いシグナルではありません。なぜなら、Astraは基本的に読めないコードを生成するからです。Astraはコードゴルフをします。私自身の顕示的な好みは、Astraの不可解さよりも、Claudeの過剰なコメントとテストを選ぶということです。」 — fastball

2番目のスレッドは、測定ではなく実用的なテクニックを求めました。あるコメンターは、エージェントが生成するコードの複雑さと冗長さを減らす方法があるかどうかを直接尋ね、それをベンチマークの問題ではなくコード品質の問題として捉えました。

3番目のテーマはメトリクスのカバレッジでした。あるコメンターは、循環的複雑度を補助的な可読性メトリクスとして求める一方で、AI関連およびAI生成コードがそれに苦しんでいるのをますます見かけると述べました。別のコメンターは、より少ないコーディングユニットが、パッチを読まなければならない人間のレビュー作業を実際に減らすかどうか疑問視しました。

4番目のテーマはモデルのカバレッジでした。あるコメンターは、ベンチマークには一般の人がローカルで実行できる最高のコーディングおよびライティングモデルを含めるべきだと主張し、現在の候補としてQwen 3.8 27B（Q4で約28GBのRAM）を挙げ、オープンウェイトと主要な商用モデルのギャップが見えるようにすべきだと述べました。同じコメンターは、ローカルモデルは1年以上前よりもすでに優れており、テキストから画像やテキストから音声へのモデルと同じ比較を引き出しました。

あるコメンターは前提を完全に退け、人々がベクトル空間が動作するスケールを理解すればコード量は重要でなくなり、複雑さはAIシステムにとって大きな問題ではないと主張しました。

ベンチマークをブックマークすると言ったコメンターは、測定の観点から価値を捉えました：測定できないものは管理できず、測定を抽象構文レベルに移すことでコメントやフォーマットのノイズの層が取り除かれると述べました。また、この分野のヒューリスティックはコード生成とパイプラインの最適化の余地を残しているため、より多くの実体験を聞きたいと付け加えました。

独自のベンチマークを追加する

Parsimonyは外部の結果を受け入れます。ユーザーはサンプルファイルをダウンロードし、自分のコードサイズの数値を入力して、同じチャートとテーブルを取得します。ファイルはブラウザ内に留まります。形式と共有手順は、プロジェクトのリポジトリのdocs/custom-benchmarks.mdに文書化されています。

Sources

関連