この記事は、開発者が不在の間も作業を続ける自律的なコーディングエージェントのループを構築するための実践ガイドであり、エージェントに「寝ている間に学習させ、リリースさせる」ために Ryan Carson が説明した手法を発展させたものである。ループ自体のオーケストレーション、反復をまたいで持続するメモリの構成、自動テストによる出力の検証、複数の並行エージェントへのスケーリング、そしてコミット権限とシェル実行権限を持つエージェントを無人で動かすことのリスク管理を扱っている。
中心となるパターンは Ralph Loop（Geoffrey Huntley と Ryan Carson によって広められた「Ralph Wiggum テクニック」という愛称を持つ）である。開発を小さくアトミックなタスクに分割し、エージェントに「選択・実装・検証・コミット・リセット」のサイクルを繰り返させる。混乱が蓄積するのを避けるため、毎回エージェントのコンテキストをリセットする。
要点
- ループの 6 ステップのサイクルを示している。To-Do リストから次のタスクを選ぶ、それを実装する、テストや型チェックで検証する、チェックに合格すればコミットする、タスクの状態を更新して学んだことを記録する、そしてエージェントのコンテキストをリセットして繰り返す。
- 本来ステートレスなループをまたいで持続する 4 つのメモリの経路を説明している。git のコミット履歴、プレーンテキストの進捗ログ、タスク状態ファイル（例えば、合否フラグ付きのタスクを並べた JSON）、そして長期的な意味記憶として機能し、すべての反復が読み込み追記もできる AGENTS.md ファイルである。
- AGENTS.md を「パターンと規約」「落とし穴」「スタイル／好み」「最近の学び」といったセクションに分け、簡潔かつ事実に即した内容に保つことを勧めている。また、ファイルが大きくなるにつれて、そのすべてを毎回のプロンプトに注入するとコンテキストが肥大化し、性能が低下するおそれがあると警告している。
- Simon Willison を引用し、エージェントに良いテストを書かせる最も効果的な方法は、エージェントが模倣できる質の高いテストをあらかじめコードベースに保っておくことだと報告している。
- Cursor のエンジニアリング実験を引用し、専門化した Planner エージェントが作業を分解し、Worker エージェントがそれを実装する「Planner-Worker モデル」を説明している。共有ファイルのロックを用いた以前のアプローチではエージェントが行き詰まったり過度にリスク回避的になったりしたが、この方式では数百のエージェントでウェブブラウザを構築するまでスケールし、1 週間で 1,000 以上のファイルにわたって 100 万行を超えるコードを生み出したと報告している。
- エージェントはフィーチャーブランチでのみ動かし（main では決して動かさない）、読み取り専用のコマンドだけを自動承認して書き込みには承認を必須とし、実行をサンドボックス化する（例えばコンテナ内で）ことを勧めている。それとは別に、暴走によるコストを抑えるため、反復回数の厳格な上限（および時間やアイドルの上限）を設けることを勧めている。
- 正しさに関する主なリスクとしてハルシネーションと「タスクの逸脱」（要件の誤解）を挙げ、曖昧さのない受け入れ基準、テストや型チェックによる検証、長時間の実行に伴うずれに対抗するための定期的なゼロからの再計画、そして可能な場合は 2 つ目のモデルによるクロスチェックで緩和することを勧めている。
- Compound Product（Ryan Carson のチームによるオープンソースのシステム）は、分析ループ、計画ループ、実行ループを連結し、あるエージェントの出力が次のループの入力になるようにしていると報告している。その思想は「一つひとつの改善が、将来の改善をより容易にするべきだ」というものである。
背景
この記事は、同じ手法についての Ryan Carson 自身の解説を補完するものであると明言しており、ループパターンを広めた功績を彼と Geoffrey Huntley に帰している。さらに、エージェントのメモリとテストについて Eric J. Ma と Simon Willison がそれぞれ公開した文章から追加の実践を取り入れている。特定の実装（Carson の ralph ツール、Compound Product、Cursor の Planner-Worker 実験）に関する主張は、著者自身の成果として示されるのではなく、名前の挙がったそれぞれの情報源に帰されている。