LLMが書くコードは人間の2倍「雑」だった

コード品質についてエージェントにフィードバックを与える定量的アプローチを人々が検討しているのを見て、本当に嬉しいです。この投稿は良いスタートのように見えます！

著者への主なフィードバックは、雑さにとって最も重要な問題は局所的なものではなく、グローバルな特性だということです。私の経験では、エージェントは人間と同様、注意力に有限の容量がありますが、邪魔になる局所的な雑さに遭遇した場合、必要に応じて修正できます。重要な技術的負債の問題は通常、簡単には修正できないグローバルな問題です。それらにはグローバルな分析とグローバルなリファクタリングが必要です。

答えはわかりませんが、関心の分離、明確なアーキテクチャ階層、明確に定義されたインターフェースなど、アーキテクチャ特性を測定する方法が必要になると思います。

コーディングは、フロンティアモデルに無制限のトークンを使えば、おそらく解決されるでしょう。それが永遠に法外な費用であり続けるかどうかはまだわかりません。私の会社では、まだ余裕があるうちにトークンを使いまくりました。しかし、Anthropicのエンタープライズプランに切り替えて、トークンごとに支払うようになったとき、本当に大変なことになりました。今はまともなコストレベルに戻りつつあり、そしてわかったのは、なんと、人間の力の方が費用対効果が高いかもしれないということです。AIはもちろん活用すべき巨大なツールですが、ループを作って走らせるにはまだ高すぎます。これはもちろん時間とともに変わるでしょうが、解決済みの問題だと仮定するのはナンセンスです。常温核融合を解決すれば、そうかもしれません。それまでは、進化がエントロピーとの戦いに勝っています。

著者と同じ結論に達したことで、アーキテクチャレビューを行う最初のエージェントを作るに至り、その過程で何年も従ってきた良いプラクティスの背後にある指標について学びました。LCOM、循環的複雑度、そういったものです...

大量のコードを出荷するのはとても簡単なので、コードが正しいことを保証するためにより多くの努力を払うべきです。開発者を巻き込んだ自己改善フィードバックループや専用のツールなど...

しかし、またしても、少し前まではすべてがプロンプトエンジニアリングでしたが、今では漠然とアイデアを表現すればそれなりに動く結果が得られるので、これもまた急速に進化するでしょう...

LLMがコードベースで扱える複雑さに限界があるかどうか、実際に知っている人はいるのでしょうか？LLMが人間にとって理解しやすいコードを書かないことは明らかです（そして、これらのモデルのトレーニングにRLが使われるほど、どんどん悪化するでしょう）。しかし、LLMが導入する複雑さのためにLLM自身も苦労するという点がなければ、安全クリティカルでないソフトウェアの大部分にとってはもう関係ないのかもしれません。私は限界があってほしいと心から願っています。なぜなら、彼らを操縦することは、私がまだ価値を提供できる最後の能力の一つだと感じているからです。しかし、これらのモデルが保守の悪いコードでより苦労するという証拠は実際にあるのでしょうか？

ここではグッドハートの法則が議論なしに持ち出されています。必要なテストをすべてパスする最小のLOCを最適化することが、雑なコードを生むと確信しているのでしょうか？そして、そもそも雑なコードとは何でしょうか？定義できれば、その定義をコンテキストに入れてLLMに避けるように指示できるのでしょうか？

コーディングは単にメモリ上で動くプログラムではなく、チーム間で理解のメンタルモデルを共有するプロセスでもあります。

人間がますますコーディングから排除されるなら、誰がメンタルモデルを保持するのでしょうか？

AIがメンタルモデルを保持するなら、定義上、人間のプロンプトは損失のあるチャネルを通ることになります。これはAIなしでも同じです。ソフトウェアの品質は、ビジネス/PMの言葉を技術的な決定に翻訳する優れた開発者に直接依存します。

では、コーディングは今解決されたのでしょうか？それは何十年も前にすでに解決されていました。

良い尺度はコミュニケーションです。共通の理解があれば、起源は必ずしも重要ではありません。