LLMはコード生成においてほぼ完璧になりましたが、それは物語の終わりではありません。コードが形式的に正しいからといって、不必要な抽象化を導入したり、重複を作成したり、全体的に悪い決定を下したりしていないわけではありません。これは画期的な観察ではありません。プロジェクトをバイブコーディングしたほとんどの人は、追加機能ごとにコード行数（LOC）が爆発的に増えることがあると気づいています。これは人間の主体性の喪失につながります。なぜなら、月に数百万行のLOCを追加するプロジェクトでは、人間が追いつくのが難しいからです。エージェントが処理してくれると信じているので、それは全く問題ではないと言う人もいるかもしれません。悪い知らせがあります。エージェントも実際にはずさんさに対処できません。

物理学のバックグラウンドから来ている私は、常に問題解決に実験的/定量的アプローチを取ってきました。Earendilでコードのずさんさを測定する方法を解明するタスクを始めたとき、私の自然な本能は、まず文献を深く掘り下げ、次に他の企業が何をしているかを確認することでした。率直に言って、いくつかの洞察に満ちた研究論文を除いて、現在の業界がどれほど「雰囲気ベース」に見えるかに失望しました。私の研究とXでは、「エンドツーエンドのコーディングエージェント」、「コードを提案するだけでなく、それを出荷するAI」、「人間レベルのコストなしで人間レベルの評価」などのメッセージを絶えず浴びせられていました。これらはすべての良い物語のように、真実の一粒を含んでいます。LLMはほぼ完全に正しいコードを書くことができます。これはコードのスケーラビリティと検証可能性によるものです。LLMにコードを生成させ、そのコードを隠されたテストでチェックさせるのは非常に簡単で、明確な報酬シグナルが得られます。それとは対照的に、このコードの「ずさんさ」をチェックするには、しばしば人間の直感とセンスが必要であり、一般的に非常に困難なタスクです。

なぜそうなのかを説明する最良の方法は、ずさんさを測定する可能な方法を検討することだと思います。AIを審査員とする：これはおそらく業界でコード品質を評価する最も一般的な方法であり、私の観察ではほとんど機能しません。最も素朴な方法、つまりモデルにコードが1〜10の尺度でどれだけ良いかを尋ねることは、基本的に乱数生成器と同等です。より洗練されたアプローチ、つまり審査員モデルに2つの解決策AとBを与え、どちらを好むかを決定させる方法には、解決策の名前を変更するとモデルが好みを変えるという欠点があります。ここでは少し冗談めかしていますが、より大きなモデルでは効果はそれほど顕著ではありませんが、主な点は依然として当てはまります。LLMに自分が書いたコードを判断させることは、適切な評価の代わりにはなりません。ルーブリックやLLMがテストを書くなどの興味深いアプローチもありますが、実際にずさんさをなくすにはほど遠いです。

人間がAIを判断する：ソフトウェアエンジニアの品質に大きな多様性があるという事実を無視すれば、これがコードを人間が読める状態に保つための最良の解決策でしょう。欠点は、AIのトレーニングや、複数のモデルプロバイダーとハーネスを備えた大規模なベンチマークにはスケーラブルでないことです。最も簡単な方法：私の研究とテストでは、単にLOC数の変化を取ることが、ずさんさの指標として驚くほど効果的でしたが、皮肉なことに、それに最適化し始めると、意味のある尺度ではなくなります。次の2つの指標は、論文Slop Code Benchで紹介されたもので、レガシーコードベースとLLMのずさんさをかなりうまく分離できるため、有望に見えました。冗長性：重複した不要な冗長行の量を測定しようとします。侵食：コードベースの質量がどれだけ少数の大きく複雑な関数に集中しているかを測定しようとします。

主要エンティティ：企業：Earendil

FAQ：コードのずさんさを測定する上での主な課題は何ですか？

主な課題は、ずさんさがしばしば人間の...

FAQ Q：コードのずさんさを測定する上での主な課題は何ですか？

FAQ A：主な課題は、ずさんさがしばしば人間の直感とセンスを必要とし、自動評価を困難にすることです。AI審査員は信頼できず、人間の評価はスケーラブルではありません。