LLM がコードを書くのはもう珍しくありません。むしろ次に問題になるのは、動くかどうかではなく、そのコードがどれだけ雑か、という話です。Earendil の記事は、まさにそこを正面から扱っています。正しいけれど無駄が多いコード、重複だらけのコード、あとから人間が追いにくいコードを、どうやって数値に落とすのか。この記事はその難しさと、今の評価手法の頼りなさをかなり率直に書いていました。
Earendil の Sebastian は、LLM がほぼ完璧にコードを生成できるようになった今でも、それで話は終わらないと述べます。というのも、コードが形式的に正しいことと、良いコードであることは別だからです。必要以上の抽象化を増やしたり、似た処理を何度も書いたり、全体として悪い判断を積み重ねたりする。いわゆる “slop” は、テストを通るコードの中にも入り込みます。
記事では、こうした雑さが人間の手を離れやすい点を強く問題視しています。特に、月あたり何百万行もの LOC が増えるような開発では、人間が全部を追い切れません。エージェントなら何とかしてくれる、という期待もあるが、著者はそこに否定的です。エージェント自身も slop をさばけるほど賢くはない、というのが彼の見立てでした。
Sebastian は物理学のバックグラウンドから、まず文献と他社の手法を広く調べたと言います。ただ、研究論文の一部を除けば、業界全体はかなり “vibes based” に見えたそうです。X でも「end-to-end coding agents」「AI that doesn't just suggest code—it ships it」「Human-level evaluation without human-level cost」といった宣伝文句があふれているが、それらには一面の真実はあっても、評価の厳しさまでは担保していない、と彼は見ています。
では、どう測るのか。まず挙がるのは AI に AI を裁かせる方法です。コードを 1〜10 で採点させる、あるいは A と B を見せてどちらが良いか選ばせる。だが、著者によれば前者はほぼ乱数に近く、後者も選択肢の名前を変えるだけで好みが揺れることがある。大きなモデルでは多少ましでも、LLM が書いたコードを LLM が評価するだけでは、まともな評価にはならないという立場です。ルーブリックを入れたり、LLM にテストを書かせたりする流れもあるが、slop を消し切るにはほど遠いとしています。
一方で、人間が AI を見るやり方は、少なくとも人間の可読性を守るという意味では筋が通っています。ただし、これはスケールしません。AI の学習や大規模ベンチマーク、複数のモデル提供者をまたぐ比較には向かないからです。そこで最も単純な指標として、著者は LOC の増減を見ます。驚くほど効くことがある一方で、これを最適化し始めた瞬間に意味を失うという皮肉もあります。
さらに記事は、SlopCodeBench という論文で提案された 2 つの指標を紹介します。1つは Verbosity で、AST-Grep に引っかかる冗長行と clone lines の割合を LOC で割って測ります。もう1つは Erosion で、関数ごとの cyclomatic complexity と SLOC から mass(f)=CC(f)√SLOC(f) を定義し、複雑度が 10 を超える関数に mass がどれだけ集中しているかを比率で表します。著者が引用する平均値では、既存リポジトリの verbosity は 0.15 ± 0.06、agents のコードは 0.33 ± 0.10。erosion は既存リポジトリが 0.31 ± 0.17、agents が 0.68 ± 0.20 でした。つまり、生成コードは人間のコードよりおおむね 2 倍ほど冗長で、より eroded だというわけです。著者自身の vibe coded プロジェクトでも verbosity が 0.4、erosion が 0.75 に達したものがあり、実感とも合っていたといいます。
最後に、SlopCodeBench の評価設計が重要だと説明されます。このベンチマークは、最初に全指示を与えて隠しテストで採点する普通の形式ではなく、途中でコンテキストを消しながら指示とテストを何度も繰り返します。人間が実際にエージェントを使う反復的な開発に近づけた設計です。その結果、悪い設計判断が積み上がり、厳格な solve rate では最先端モデルでも 0% の pass rate になったそうです。著者は、これは大量の LOC を気軽に積み上げる人たちへの警告だと受け止めています。
この話でまず印象に残ったのは、著者の関心が「正解率」ではなく「コードベースの摩耗」に向いていることです。AI 評価の議論は、ついベンチマークのスコアや pass rate に寄りがちです。でも実際の開発では、通ったコードが必ずしも歓迎されるわけではありません。あとから人間が読めない、直しにくい、似た処理が増殖する。そういう損失は、テストを通った瞬間には見えにくい。著者はそこをちゃんと問題にしていて、私はかなり妥当だと思いました。
特に面白いのは、Verbosity と Erosion という指標です。どちらも万能ではないはずですが、少なくとも「雑さ」を雑に済ませない姿勢がある。Verbosity は冗長さ、Erosion は複雑さの偏りを見る。これなら、単に LOC が増えたかどうかよりは一歩深い。ただし、ここには危うさもあります。指標ができると、人はそこを最適化したくなるからです。短いコードを書けば良い、複雑な関数を分割すれば良い、という単純なゲームに落ちる可能性がある。著者も LOC 最適化の例でその罠を認めていますが、この種のメトリクスはたいてい、測れた瞬間にゲーム化される運命にあります。私はそこにかなり注意が必要だと思います。
AI を judge にする方法への冷ややかな見方も、かなり核心を突いています。生成と評価を同じ系列のモデルに任せると、評価の独立性が失われる。これは昔からある話ですが、LLM 時代には一段と深刻です。なぜなら、モデルはもっともらしい説明を返すのが得意だからです。数字を付けさせればそれらしく見えるし、A/B 比較もそれなりに筋が通って見える。けれど、見えているのは判定の形式であって、判定の質ではない。
ここで重要なのは、著者が AI judge を全面否定していない点です。ルーブリックやテスト生成のような工夫はあるし、研究としては面白い。ただ、彼はそれでも「slop を取り除く決定打」にはなっていないと言う。その控えめさはむしろ信用できます。今の業界には、AI に AI を採点させれば人間のコストが消える、といった期待が広がっていますが、実際には評価の最後のところで人間の感覚が残る。可読性、納得感、保守しやすさ。ここはまだ機械だけでは埋まらない、ということです。
SlopCodeBench の設計は、今回の記事でいちばん示唆的でした。最初に全部の条件を渡してテストだけで切るのではなく、途中で文脈を消しながら何度もやり取りする。これはかなり実務に近いです。開発は一発勝負ではなく、途中で仕様が増え、前提が壊れ、過去の判断に引きずられます。だから、後から見れば当然のように見える悪さが、実際には段階的に積み上がる。
著者が「最先端モデルでも strict solve rate が 0%」と書いているのは、かなり強い警告です。もちろん、テストが厳しすぎる可能性や、問題文に曖昧さがある可能性はあるでしょう。それでも、評価の場を現実に寄せると、モデルの弱さが一気に露出する。私はこの点に、ベンチマークの本質があると思います。評価は能力の証明であると同時に、何を現実として扱うかの宣言でもあるからです。
この文章を読んで感じたのは、sloppiness の測定は、結局のところ「人間がどんなコードを良いと感じるか」を避けられないということです。著者も、最後には human intuition and taste が暗黙に、あるいは明示的に評価へ入り込むと言っています。これは弱点というより、現状の正直な姿だと思います。コードは機械可読でも、保守は人間の仕事だからです。
だからこそ、今の段階で大事なのは、AI に完璧な採点者を期待することではなく、どの雑さを見逃さないかをはっきりさせることだと思います。冗長さなのか、関数の局所的な複雑さなのか、変更のたびに増える重複なのか。そこを定義しないまま「動くから良い」と言い切ると、後で確実に返ってきます。著者の論点は、華やかな AI コーディングの話の裏側で、その後始末を誰が引き受けるのか、という地味だが重い問いでした。
参考: If coding is solved, what now?: Measuring the sloppiness of code
