エージェントに「もっと速く」と頼み続けたら、Rustコードが最先端ライブラリを超えた

こういうので素晴らしい結果を出している。最適化が行われるためのまともなフレームワークが本当に必要だとわかった。本質的には、測定ハーネスと、自分がやっていることへのある種の動機づけを提供するだけだ。

LLMの素晴らしいところは、あらゆることのチェックリストを持っているように見えることだ。「ホットパスでアロケートするな」とか「コアをピン留めするのを忘れるな」とか、いくつか挙げると、自分では忘れていたかもしれない項目をいくつか思いついてくれる。

最終的には、私と一緒にリスト全体を消化し、その過程で全ての測定を文書化してくれる。

でも、それはまだ経験によって導かれる。異常な数値を見たら、「ねえ、リリースモードでコンパイルするのを忘れてない？」と言うかもしれない。すると謝って修正してくれる。もし私が言わなければ、全てが間違っていることに気づかずに探求を続けるかもしれない。

測定できるものであれば、LLMは最適化できる。

かつて、`sample`の結果とCPUプロファイラ/トレースをダンプするリポジトリコマンドと、現在変更されたgitワークスペースをHEADや任意のコミットとA/A + ABBA/BAABテストできるベンチマークツールを用意したら、LLMはただやるべきことをやるだけだった。

そして、それが私の自家製ターミナルがghostty/kitty/itermよりもはるかに少ないメモリで、しかもより高いスループットを持つ理由だ。

AIは、正しくパフォーマンスの高いソフトウェアを保証することがあまりにも簡単になった今、それを気にしない人々や企業をますます暴き出すだろう。以前は、そういうことをするのは少なくとも高コストで時間がかかり、専門知識を要した。

「より良いコードを書いて」と頼み続ければ、LLMはより良いコードを書けるのか？

私にとっての鍵の一つは型の使用だった。関数がそれからしか生まれない証人を生成し、続行するためにそれを要求するTypestateや、エージェントが忘れないように文字列の代わりにカスタム型を使うnewtypeなどだ。また、線形型をシミュレートすることで、エージェントに車輪の再発明ではなく実装を使うように強制することもできる。型は最適化する対象がはるかに小さく、コンパイル時に大声で失敗する制約を提供する。

ベンチマークを行い結果をループする最適化エージェントに報告する別のエージェント（セッション/インスタンス）を用意することが、カンニングを防ぐクリーンな方法だとわかった。ベンチマークエージェントにはカンニングする理由がなく、その目標はただ刺激されたときにベンチマークを実行することだけだ。

これは品質評価にも本当に良いとわかった。何かがどう作られたかのコンテキストを持たないエージェントに品質レビューをさせ、詳細なフィードバックをたくさんもらう。そしてそのレビューノートを実装者に返してフィードバックとする。これはエージェントに自己評価させるよりずっとうまく機能する。