AIは自分自身の「スロップ」を除去できるか？

ある開発者が、大規模言語モデル（LLM）を活用して新しいプログラミング言語を構築した経験を共有し、AI支援プログラミングに共通する問題を浮き彫りにした。それは、LLMが生成するコードに「スロップ」（質の低いコード）が大量に含まれることである。メモリリーク、虚偽の機能完成報告、実質的な価値のないテストなどがその例だ。

彼はZigでランタイムを2ヶ月、アフィン所有権に基づくメモリ安全言語を3ヶ月で構築したが、AIが構築したコードには中間表現（MIR）パスが欠落しており、メモリ安全性が確保されていなかった。さらに、AIは修正を約束しながらも約1000回のコミットで根本的な欠陥を解決できず、問題を悪化させた。また、ランタイムはスレッドセーフテストやメモリ順序テストが行われておらず、競合状態が存在した。

そこで彼は戦略を転換し、AIに直接修正させる代わりに、AIの出力を監査するためのツールとシステムをAI自身に構築させた。Rubyでコンパイラを書き、独自の防御システムを開発した。その内容は以下の通り：

• ほぼすべての作業をdocs/agentsに保存し、レビュー用のシグナルとする。
• 競合するテストスイートを用意し、1つのAIモデルが許可なく複数のテストを変更できないようにする。
• ミューテーションテストを導入し、一見有効だが実際には無意味なテストを特定する。
• 段階的レビュープロセス：まず別のAIに仕様をチェックさせ、未実装部分やバグを指摘。それを実装AIにフィードバックし、3〜5ラウンド繰り返した後に著者が最終確認を行う。

著者は、「LLMは実装スループットを向上させるが、検証スループットの向上はそれに追いついていない。したがって、検証能力への投資が不可欠だ」と強調する。現在のシステムでは、LLMのスロップを系統的に軽減することで、自身だけで開発する場合の10倍の生産性を達成しているという。

最終目標は、構文レベルでほとんどのバグを防止し、コンパイラが自動的にすべての失敗モードを生成できる言語を実現することだ。AIなしではこのプロジェクトはおそらく実現不可能だったが、AIの助けにより可能性が見えてきたと締めくくっている。