来たるべきループ

Armin Ronacherの思考と執筆ブログアーカイブ プロジェクト 旅行 トーク 来たるべきループについて 2026年6月23日執筆 私はもうClaudeにプロンプトを与えていません。Claudeにプロンプトを与え、何をすべきかを判断するループが動いています。私の仕事はループを書くことです。 — Boris Cherny ここ数ヶ月、私はますます多くの人々が、単にコーディングエージェントを使用するのとは意味のある違いを感じさせるものを、その上に構築しているのを見てきました。これの一部はPiの上で行われており、確かに見るのはクールです！しかし、パターンはどこでも同じです。作業がある種のキューに入れられ、機械がそれを取り上げ、試行し、停止し、そして何らかのハーネスがそれが本当に終わりだったのかどうかを決定します。そうでない場合、ハーネスは同じセッションを続行し、別のメッセージを注入し、修正されたコンテキストで新しいセッションを開始するか、タスクを別のマシンに送信します。タスクは、モデル自体が通常「完了しました」と言うであろう時点を超えて生き続けます。 私はその種のループについて、認めたくないほど考えています。すべてのコーディングエージェントの内部にはすでにエージェントループがあります。モデルはツールを呼び出し、結果を取り込み、別のツールを呼び出し、ファイルを読み込み、ファイルを編集し、テストを実行し、最終的に何らかの答えを生成します。そのループは私たちが長い間非常によく知っていたものです。もう一つのループはハーネスレベルのループです。エージェントループの外側のループです。そのループも新しいものではありません。私たちは初期のClaude Codeの時代からこれのバージョンを行ってきましたが、そのループはエージェントエンジニアリングにおいてますます普及しており、ここ数週間でTwitterの議論を支配し始めています。 私はまだこれが得意ではありません 現在の私の状況は、私が深く気にかけているコード（それがかなりの量のコードであることが判明しました）に対して、この作業方法で大きな成功を収めていないということです。その一部は趣味であり、一部はコントロールです。私はコードがどうあるべきかについて高い基準を設定しようと努めており、出荷するコードを理解したいと思っています。プレッシャーの下で、あるいは他の人間との議論の中で、システムが何をしているのかを、まずクラッカーに説明を求めることなく説明できることを望んでいます。 さて、このコードを理解したいという欲求が、数年後も私に残っているかという疑問は明らかにあります。今のところ、私は理解が私にとって重要であるという点を超えていません。この欲求を考えると、特にループによって注意を払わずに書かれたコードの経験には、私に何か足りないものがあります。現在のモデルは、あまりにも防御的で、複雑で、推論が局所的すぎるコードを生成する傾向があります。彼らは強力な不変条件を避けます。彼らは悪い状態を不可能にする代わりにフォールバックを追加します。彼らはコードを複製し、悪い抽象化を発明し、不明確な設計をより多くのメカニズムでごまかします。 しかし、さらに悪いことに、私はこれの改善がほとんど見られないと感じています。むしろ、その点では、私たちは間違った方向に進んでいるとさえ感じられます。少なくとも私の好みでは、現在のハンズオフなハーネス（ultracodeを備えたClaude Codeなど）は、昨年の秋に私たちが生成していたものよりも悪いコードを生成します。それは、例えばFableを備えたClaude Codeが、以前はもっと人間が関与していたプロセスであったのに、中断することなく30分以上問題に取り組み続けるからです。さらに、モデルは局所的な失敗を観察し、局所的な防御を追加する傾向があることはよく理解されています。Karpathyは、彼らが「例外を死ぬほど恐れている」と述べました。重要な不変条件を持つシステム、特に永続化されたデータ形式やコアインフラストラクチャでは、正しい修正は「すべての不正なケースを処理する」ことではありません。正しい修正は、不正なケースが表現不可能であるか、そもそも書くことができないようにすることです。しかし、多くの手動介入があっても、そのようなコードはLLMから自然に生成されず、たとえ自然に生成されたとしても、彼らは今や不可能になったエラーを処理しようとします。 その振る舞いをループの背後に置くと、それは増幅される傾向があります。各イテレーションが別の小さな防御を追加すると、システムは徐々に理解しにくくなりながらも、より堅牢に見えるようになります。ハンズオフであればあるほど、それが起こります。また、このようなツールが明確なガイダンスなしにジュニアに与えられると、非常に悪い習慣を教えることにもなります。なぜなら、なぜそんなことをしているのかと尋ねると、彼らは説得力のある議論を展開するからです。 ループが機能する場所 同時に、ループパターンが機能しないと見せかけるのは不誠実でしょう。なぜなら、それはすでにいくつかのドメインで驚くほどよく機能しているからです。コードのポーティングはその一つです。Bunの一部をZigからRustに移行する作業を含む、大規模な自動ポーティングの印象的な例がすでにあります。私自身もMiniJinjaをGoにポーティングするために成功裏に使用しました。パフォーマンス探索も、これが美しく機能するもう一つのケースです。機械は実験を試し、ベンチマークを行い、失敗を破棄し、検索を続けることができます。セキュリティスキャンも自然に当てはまりますし、ほとんどあらゆる種類の研究も同様です。複雑な問題空間を探索し、必ずしも永続的なコードをコミットすることなく報告するようシステムに依頼するのです。これらの多くに共通しているのは、新しいコードを生成するのではなく、既存のコードを変換するか、意図的に寿命の短いコードを生成するかのどちらかであるということです。彼らは概念実証やアイデアを生成するか、発見を表面化するか、あるいは機械的な変換に近いものです。私は、寿命の必要性がない成果物を生成するループ、または何らかの明確に検証可能な機械的変換を作成するループは、ハーネスが機械的に目標を測定する一般的な能力よりも重要だと信じています。 ループの多くの成功したアプリケーションは、別のLLMを判断者またはオーケストレーターとして使用します。機械的変換のケースはバイナリテストケースで検証できますが、代わりにLLMによって判断することもできます！例えばClaude Codeは、実行する実験的なワークフロー全体を作成する能力がますます向上しています。確かに、それが生成するコードはいい加減ですが、それはモデルの欠点であって、ワークフローのステップが全体的な改善または完了につながったかどうかを判断するのにハーネスが優れていないというわけではありません。ハーネスには、別のイテレーションを駆動するのに十分なシグナルがあればよいのです。それは客観的である必要もバイナリである必要もなく、単に十分に役立つものであればよいのです。私はすでに、日々の退屈な部分を取り除き、実験と測定を行い、アイデアを与えてくれるループを心から愛しています。 有機体としてのソフトウェア 一方で、同じループ手法を使って永続的なコードを書くことは、まだ私にはしっくりきません。私が好んで使う比喩は、ソフトウェアを決定論的な機械から有機体へと移行させるというものです。私は機械を理解することを奨励する環境でソフトウェアエンジニアになりました。理解を深めるために、常に剥がすことができる層がありました。決定論的な観察可能な動作を示さない機械は、おそらく受け入れられましたが、一般的には最適ではないと見なされていました。ソフトウェアアーキテクチャの観点からは、より決定論的な方向へとさらに押し進めることが望ましいと考えていました。同様に、コードを理解する能力は否定できない目標でした。実際には常に可能であるとは限りませんでしたが、私たちは新しいエンジニアでさえ巧妙なアーキテクチャを通じて複雑なコードベースをナビゲートできるようにコードを書くことに誇りを持っていました。うまく設計されたシステムでは、不変条件がどこにあり、どの部分が耐荷重であり、どの変更が安全であるかを知っているエンジニアが常にいました。理想的には、これらすべても適切に文書化されていました。その理解が欠けている場合、それは一般的に改善すべきものと見なされていました。 もちろん、その理想は常に困難を伴いました。多くのソフトウェアシステム、特に非常に成功したシステムには、チームのエンジニアがそれらをクリーンに保つことができた期間がありました。大規模なソフトウェアシステムは、しばしば大きすぎたり、動的すぎたり、外部サービスに依存しすぎたりして、誰かの頭の中に入ることはできません。LLMがなくても、私たちはすでに分散システムを医師のように診断しています。症状を観察し、仮説を立て、「より多くのテストをオーダーします。」