人々は、どうやってコーディングエージェントを管理しているのかよく尋ねます。実際のシステムです。 核心的な洞察:1回の長いAIコーディングセッションは脆弱です。文脈を蓄積し、幻覚を作り、時間が止まる。だから一つのマラソンの代わりに、たくさんのスプリントを走ります。各エージェントセッションは新たに始まり、git履歴とファイル状態を通じて前回のセッションの続きから引き継ぎます。 これを「ラルフループ」と呼びます。ラッパースクリプトは作業が完了するまで、同じプロンプトでコーディングエージェントを繰り返し起動します。もしエンストやクラッシュが起きても、問題ありません。次のイテレーションはゼロの荷物でクリーンに始まります。 私は計画にはOpus 4.6を使っています。PRDの作成、アーキテクチャの分解、タスク仕様の定義などです。その後、Codex 5.3が実際のコーディング実行を担当します。この分割が最も信頼性が高く高品質なコードを作成し、バグ修正やフォローアップの問題が最も少ないことがわかりました。 私はPRDをマークダウンチェックリストとして作成しています。ループはすべてのチェックボックスが満たされているかを確認することで完了を検証します。エージェントは完了したと言っているのに、47件中12件のタスクが残っているのですか?再起動。混乱したモデルと交渉する必要はない。 エージェントは再起動を乗り越えるためにtmuxセッションで動作します。私は一瞬で監視し、もし1台が死んだら自動的に再起動します。もし1台が停止した場合(連続チェックで同じ出力が出る)、キルして再起動します。 すべてのTMUXセッションには終了時にウェイクフックがあります。エージェントが終了すると、すぐに私にピンを送るイベントが発生します。静かな完成もありません。作業が終わった瞬間、監視しているかどうかに関わらずわかります。 調子の良い日は、3〜4つのエージェントを別々のプロジェクトで並行して動かし、それぞれが独立したgit worktreeで管理しています。先週、3つのプロジェクトで同時に108タスクを約4時間でこなしました。 もう一つの鍵はテスト駆動型プロンプトです。まず失敗したテストを書いてから実装するようエージェントに指示しています。テストは非決定論的労働者に対する決定論的な受け入れ基準です。マージ後の故障を大幅に削減します。 魔法じゃない。これはAI労働に応用されたプロセスエンジニアリングです。仕様をクリアし、自動検証を行い、詰まったら再起動し、出力を確認します。 これは私がよく受ける質問の一つなので、きちんとまとめて『AIの雇用方法』の新しい章として追加しようと思います。すでに購入したすべての人には更新版が提供されます。