コーディングは解決されたのか？ コードの「ずさんさ」を測定する

コードの「ずさんさ」を測定する

LLMはコード生成においてほぼ完璧になりましたが、それで終わりではありません。コードが形式的に正しかったとしても、それが不必要な抽象化を導入したり、重複を生み出したり、全体的に悪い決定を下したりしていないとは限りません。これは画期的な発見ではなく、プロジェクトを「フィーリング」でコーディングしてきたほとんどの人は、機能を追加するたびにコード行数（LOC）が爆発的に増加することがあると気づいています。

これにより、人間の介入能力が失われます。なぜなら、月に数百万行のLOCを追加するプロジェクトでは、人間が追いつくのが困難だからです。[1] 人によっては、エージェントがそれを処理してくれると信じているので、それは問題ではないと言うかもしれません。残念なお知らせですが、エージェントも実際にはその「ずさんさ」に対処できません。

物理学のバックグラウンドから来た私は、問題解決において常に実験的・定量的アプローチを取ってきました。Earendilでコードの「ずさんさ」を測定する方法を突き止めるというタスクを与えられたとき、私の自然な本能は、まず文献を深く掘り下げ、次に他の企業が何をしているかを確認することでした。

率直に言って、いくつかの洞察に富んだ研究論文を除けば、業界が現在どれほど「フィーリングベース」であるかに失望しました。私の研究やX（旧Twitter）では、「エンドツーエンドのコーディングエージェント」、「コードを提案するだけでなく、それをデプロイするAI」、「人間レベルのコストなしで人間レベルの評価」といったメッセージに絶えずさらされていました。これらはすべて良い物語と同様に、真実の一端を含んでいます。

LLMはほぼ完璧に正しいコードを書くことができます。これは、コードのスケーラビリティと検証可能性によるものです。LLMにコードを生成させ、そのコードを隠されたテストでチェックさせるのは非常に簡単で、明確な報酬信号が得られます。それとは対照的に、このコードの「ずさんさ」をチェックするには、しばしば人間の直感とセンスが必要であり、一般的に非常に難しいタスクです。なぜそうなのかを最もよく説明するには、測定可能な「ずさんさ」の可能性のある方法を検討するのが最善だと考えます。

AIを審査員にする: これは、業界でコード品質を評価する最も一般的な方法であり、私の観察ではほとんど機能しません。最も単純な方法、つまりモデルに1から10のスケールでコードの良さを尋ねることは、基本的に乱数生成器と同等です。より洗練されたアプローチ、つまり2つのソリューションAとBを与え、どちらを好むかを決定させるという方法は、モデルがソリューションの名前を変更すると好みが変わるという欠点があります。ここでは少し皮肉を言っていますが、大規模なモデルではその効果はそれほど顕著ではありませんが、要点は依然として有効です。LLMに自分が書いたコードを評価させることは、適切な評価の代わりにはなりません。ルーブリックを使用したり、LLMにテストを書かせたりする興味深いアプローチがいくつかありますが、それでも「ずさんさ」を完全に排除するにはほど遠いです。

人間がAIを審査する: ソフトウェアエンジニアの品質に大きな多様性があるという事実を無視すれば、コードを人間が読める状態に保つための最良の解決策となるでしょう。ただし、AIのトレーニングや、複数のモデルプロバイダーとハーネスを備えた大規模なベンチマークにはスケーラブルではないという欠点があります。[2]

最も簡単な方法: 私の研究とテストでは、LOC数の変化を取ることが「ずさんさ」の指標として驚くほど効果的であることがわかりました。皮肉なことに、それを最適化し始めると、意味のある尺度ではなくなるという注意点があります。

次の2つの尺度は、論文SlopCodeBenchで紹介され、レガシーコードベースとLLMによる「ずさんさ」をうまく分離できたため、有望に見えました。

冗長性 (Verbosity): 重複した、または不必要に冗長な行の量を測定しようとします。[3]

\mathrm{Verbosity}=\frac{|\text{AST-Grep flagged lines}\cup\text{clone lines}|}{\mathrm{LOC}}

劣化 (Erosion): コードベースの質量が、少数の大きくて複雑な関数にどれだけ集中しているかを測定しようとします。

\mathrm{mass}(f)=CC(f)\sqrt{\mathrm{SLOC}(f)}

ここで、fは関数、SLOCはソースコード行数、CC(f)は関数のサイクロマティック複雑度です。

\mathrm{Erosion}=\frac{\sum:,CC(f)>10}\mathrm{mass}(f)}{\sum\mathrm{mass}(f)}

劣化は、サイクロマティック複雑度が10を超える関数の質量と、すべての関数の質量の比率です。

SlopCodeBenchの評価中に生成されたコードの平均冗長性と劣化を、確立されたリポジトリのセットと比較すると、顕著な違いがあります。平均して、リポジトリの冗長性は0.15 ± 0.06であり、エージェントのコードは0.33 ± 0.10です。劣化については、リポジトリは0.31 ± 0.17を達成し、エージェントは0.68 ± 0.20です。エージェントのコードは、平均して人間のコードの約2倍の冗長性と劣化があります。次に、私自身の「フィーリング」でコーディングされたプロジェクトのいくつかを調査したところ、それらの多くは冗長性が0.4、劣化が0.75に達しており、これらの結果は単なる評価のアーティファクトではなかった可能性が高いです。[4]

エージェントがなぜそれ自体で「ずさんさ」に対処できないのかという点に戻るには、SlopCodeBenchの評価を見る必要があります。他のコーディングベンチマークでは、エージェントに最初に指示の完全なリストを与え、プログラムが通過する必要のある隠されたテストのセットを用意するのとは対照的に、それらは反対のことを行います。チェックポイントの間にモデルのコンテキストが消去される、複数の指示とテストの反復ラウンドを作成します。これにより、人間がコーディングエージェントを実際に使用する方法に似た、反復的なプロセスがより密接に模倣されます。その結果、悪いコーディングの決定が時間とともに蓄積し、すべてのチェックポイントで厳密な解決率（すべてのテストに合格する必要がある）では、最先端のモデルでさえ0％の合格率を達成します。[5] これは、1日に数万行、あるいは数十万行のLOCを喜んで追加するすべての人への警告サインとなるはずです。もちろん、テストが厳しすぎる、あるいは問題文が曖昧であるという通常の注意点もありますが、一般的な傾向は当てはまります。

これらの指標を探求することで、コードの「ずさんさ」を評価することがなぜ難しいのか、そしてなぜ人間の直感とセンスが依然として評価に暗黙的または明示的に組み込まれているのかについて、より明確な理解が得られたことを願っています。

関数の結合度、コードの変更頻度、凝集度など、探求したい有望な他の方向性があります。もしあなたが評価に取り組んでいて、話したいことがあれば、喜んでお話しします：sebastian@earendil.com

---

1. これは、「コード行数でプログラミングの進捗を測定することは、重量で航空機製造の進捗を測定するようなものだ」という格言を思い出させます。↩
2. 常に変化するモデルプロバイダーのランキングを得るために、何百万行ものLOCをレビューするように誰かを強制したくはありません。↩
3. これのルールは、AST-Grepを介して実装された手作りのヒューリスティックのセットであり、これもまた、すべての人間の側面を示しています。↩
4. ただし、悪名高い「フィーリング」なオープンプロジェクトは、どちらの指標でもあまり高く評価されませんでした。おそらく、関数の結合度が非常に高い、または無関係な関数の塊が多すぎて平均値が低下したことが原因でしょう。↩
5. Fable 5.1またはAstraではテストされていませんが、GPT 5.6 sol xhighなどではテストされています。↩