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

コーディングは解決されたのか？ コードの「ずさんさ」を測定する 日付: 2026年9月10日 木曜日 差出人: Sebastian <sebastian@earendil.com> 宛先: あなた 件名: コーディングは解決されたのか？ コードの「ずさんさ」を測定する LLMはコード生成においてほぼ完璧になりましたが、それで話は終わりではありません。コードが形式的に正しいからといって、それが不要な抽象化を導入したり、重複を作成したり、全体的に悪い決定を下していないとは限りません。これは画期的な観察ではありません。プロジェクトを「バイブ」でコーディングしたことのあるほとんどの人は、各追加機能がコード行数（LOC）の爆発を引き起こす可能性があることに気づいています。これは、月に数百万行のLOCを追加するプロジェクトでは、人間が追いつくのが難しいため、人間の主体性を失わせます。 一部の人は、エージェントがそれを処理してくれると信じているので、それは問題ではないと言うかもしれません。残念なお知らせですが、エージェントもずさんさに対処することはできません。 物理学のバックグラウンドから来た私は、問題解決において常に実験的・定量的アプローチをとってきました。Earendilでコードのずさんさを測定する方法を解明するという課題に取り組んだとき、私の自然な衝動は、まず文献を深く掘り下げ、次に他の企業が何をしているかを確認することでした。率直に言って、いくつかの洞察に満ちた研究論文を除けば、業界が現在「バイブスベース」であることに失望しました。私の調査やX（旧Twitter）では、「エンドツーエンドのコーディングエージェント」、「コードを提案するだけでなく、それをデプロイするAI」、「人間レベルのコストなしでの人間レベルの評価」といったメッセージに絶えず bombard されました。これらはすべて良い物語と同様に、真実の断片を含んでいます。 LLMはほぼ完璧に正しいコードを書くことができます。これは、コードのスケーラビリティと検証可能性によるものです。LLMにコードを生成させ、そのコードを隠しテストでチェックさせることは非常に簡単であり、明確な報酬信号が得られます。それとは対照的に、このコードの「ずさんさ」をチェックするには、しばしば人間の直感とセンスが必要であり、一般的に非常に難しいタスクです。 なぜそうなのかを最もよく説明する方法は、測定可能なずさんさの可能性のある方法を検討することだと思います。 AIを審査員として: これはおそらく業界でコード品質を評価する最も一般的な方法であり、私の観察ではほとんど機能しません。モデルに1から10のスケールでコードの良さを尋ねるという最もナイーブな方法は、基本的に乱数ジェネレーターと同等です。2つのソリューションAとBを与え、どちらを好むかを決定させるという、より洗練されたアプローチには、ソリューションの名前を変更するとモデルの好みが変わるという欠点があります。ここでは少し皮肉を言っていますが、効果は大規模なモデルではそれほど顕著ではありませんが、要点は依然として有効です。LLMに自身が書いたコードを評価させることは、適切な評価の代わりにはなりません。ルーブリックを使用したり、LLMにテストを書かせたりする興味深いアプローチがいくつかありますが、ずさんさを完全に排除するにはまだ程遠いです。 人間がAIを審査員として: ソフトウェアエンジニアの品質に大きな多様性があるという事実を無視すれば、コードを人間が読める状態に保つための最良の解決策となるでしょう。欠点は、AIのトレーニングや、複数のモデルプロバイダーとハーネスを備えた大規模なベンチマークにはスケーラブルではないことです。 最も簡単な方法: 私の調査とテストでは、LOC数の変化を単純に取ることは、ずさんさの驚くほど効果的な指標であることが判明しました。皮肉なことに、それを最適化し始めると、意味のある測定ではなくなるという注意点があります。 次の2つの測定基準は、SlopCodeBenchという論文で紹介され、レガシーコードベースとLLMによるずさんさをうまく分離できたため、有望に見えました。 冗長性 (Verbosity): 重複した、または不要に冗長な行の量を測定しようとします。 Verbosity = |AST-Grepフラグ付き行 ∪ クローン行| / LOC エロージョン (Erosion): コードベースの質量が、少数の大きくて複雑な関数にどれだけ集中しているかを測定しようとします。 mass(f) = CC(f) * sqrt(SLOC(f)) ここで、fは関数、SLOCはソースコード行数、CC(f)は関数のサイクロマティック複雑度です。 Erosion = Σ[f: CC(f)>10] mass(f) / Σ[f] 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まで達しており、これらの結果はおそらく評価の単なるアーティファクトではなかったと思われます。 エージェントがそれ自体でずさんさに対処できないという点に戻るには、SlopCodeBenchの評価を見る必要があります。他のコーディングベンチマークでは、エージェントに最初に指示の完全なリストを与え、プログラムがパスする必要のある隠しテストのセットがありますが、それらは逆のことを行います。チェックポイントの間にモデルのコンテキストが消去される、複数のラウンドの指示とテストの繰り返しを作成します。これにより、人間がコーディングエージェントを実際に使用する方法に似た、反復的なプロセスがより密接に模倣されます。 その結果、悪いコーディングの決定が時間とともに蓄積され、すべてのチェックポイントでパスする必要があるすべてのテストで、厳密な解決率では、最先端のモデルでさえ0％のパス率を達成します。 これは、1日に数万、あるいは数十万行のLOCを喜んで追加するすべての人への警告サインとなるはずです。明らかに、テストが厳しすぎたり、問題文が曖昧すぎたりする通常の注意点がありますが、一般的な傾向は変わりません。 これらの指標を探求することで、コードのずさんさを評価することがなぜ難しいのか、そしてなぜ人間の直感とセンスが依然として評価に暗黙的または明示的に組み込まれているのかについて、より明確な理解が得られたことを願っています。関数の結合度、コードの変更頻度、凝集度など、探求したい有望な他の方向性があります。評価に取り組んでおり、話し合いたい場合は、喜んでお話しします: sebastian@earendil.com これは、「コード行数でプログラミングの進捗を測定することは、重量で航空機製造の進捗を測定することのようなものだ」という格言を思い出させます。 ¹ 変化し続けるモデルプロバイダーのランキングを得るためだけに、数百万行のLOCをレビューするように強制されたくはありません。 ² これのルールは、AST-Grepを介して実装された手作りのヒューリスティックのセットであり、これもまた、すべて人間の側面を示しています。 ³ ただし、悪名高いバイブのあるオープンプロジェクトは、おそらく関数の結合度が非常に高い、または単に関連性のない関数の質量が大きいために平均値を低下させたため、これらの指標でそれほど高く評価されませんでした。 ⁴ Fable 5.1またはAstraではテストされていませんが、GPT 5.6 sol xhighなどでテストされています。