AIコーディングを2000時間続けた彼が、効率の問題をスケジューリングの問題として捉え直した

ツールリストから抽出した四層スケジューリングシステム

bbは統一されたエントリーポイントです。Codex、Claude Code、Pi、Cursor CLI、OpenCodeなどのプログラミングエージェントを同じインターフェースに統合し、ユーザーが既に持っているprovider CLIのログインを再利用します。cmuxは、複数のターミナルとブラウザを同時に配置できるワークスペースで、Ghosttyはこれらのセッションをホストするターミナルアプリケーションです。これら三つは、「どこから作業を開始し、観察するか」という問題を解決します。

Herdrは、さらに下の層に位置します。それは、エージェントが存在するターミナルセッションをバックグラウンドに保持し、working、blocked、idleなどの状態をマークします。David自身が作成したCorralは、完了したエージェントをP1からP4の順にキューに入れます。前者は何が起こったかを示し、後者は次の一分間を誰に割り当てるかを決定します。

ローカルマシン、商用クラウドエージェント、自前のVPSは実行環境となります。Skills、Worktree、ADR、コードレビュー、読み取り専用の本番データ権限、リリースロックがガバナンス層を構成します。モデルはこれら全体に組み込まれていますが、いずれかの層を独占しているわけではありません。

Harnessは、エントリーポイントと実行環境の両方にまたがって機能します。Davidは、ミニマルでモデルを自由に交換できるPiをベースの実行器として使用し、Cursor CLIを使用してマルチモデルと事前送信機能を実現しています。より探索的で、方法がまだ明確でないタスクに遭遇した場合、彼は実行中にSkillを蓄積できるHermesやPrimeの使用を検討します。具体的な製品判断には個人的な好みが含まれていますが、残る選択方法は次の通りです。つまり、経路が明確なタスクには軽量で制御可能な実行器が必要であり、不確実性が高いタスクには、探索と自己蓄積が可能なHarnessを使用する価値があるということです。

この図は、「より賢いモデルに交換する」ことが、期待通りに生産性を向上させないことが多い理由も説明しています。モデルはタスクを20分から10分に短縮できるかもしれません。しかし、人が15の完了、ブロック、競合するセッションの間を行ったり来たりしているなら、節約された時間はスケジューリングによって再び消費されてしまいます。

エージェントが増えると、ボトルネックは生成速度から人の注意に移る

単一エージェントの時代には、人は一つの対話に注目していました。タスクを渡し、出力を確認し、情報を追加し、結果を確認するという流れです。エージェントが並列化されると、作業は動的なキューになります。テストを実行しているもの、権限が必要なもの、完了しているがリスクが非常に低いもの、リリースをブロックする問題を発見したばかりのものなどがあります。

Herdrのステータスパネルは、これらのセッションを可視化しますが、「見える」だけでは十分ではありません。仮に、P1エージェントが支払い障害の修正を完了し、P4エージェントが同時にテキスト修正を提出したとします。完了時間順に処理すると、価値の低いタスクが応答ウィンドウを奪うことになります。Corralの優先順位付けは、人の注意も希少なリソースとしてスケジューリングするという点にあります。

ここで、見落とされがちな変化が生じます。人は、段階的にコードを書く存在から、例外処理者かつ意思決定者へと変わります。作業量は自動的に消えるわけではありません。それは、コードを書くことから、タスクの定義、環境の準備、リスクの判断、ブロックの処理、結果の検収へと移行します。ステータス、優先順位、明確な完了条件がなければ、エージェントを多数実行しても、未完了の作業が増えるだけです。

Davidはまた、「事前送信」を強調しています。次のステップで何が起こるかが既に分かっている場合、「実装計画」「モデルを変えてレビュー」「有効な問題を修正」といったメッセージを事前にキューに入れておく方法です。この方法は待ち時間を減らせますが、経路が明確なタスクにのみ適しています。アーキテクチャの選択がまだ決まっていない場合、六つのメッセージを事前に送信すると、初期の誤判定を自動的に六回増幅してしまうことになります。

原文では、見落とされがちな入力ボトルネックも補足されています。Davidは、長いプロンプトを送信するために音声認識を使用しています。彼が挙げる「毎分250語、入力速度が三〜四倍向上」という数字は個人の見解であり、具体的な効果は話す習慣や修正コストによって異なります。しかし、一般化できる部分としては、複数のエージェントに頻繁にコンテキストを割り当てる必要がある場合、入力の摩擦を減らすことでスケジューリング時間を確かに短縮できるという点です。音声は、すでに明確に考え抜かれた指示を速めるだけで、タスクの定義や受け入れ判断の代わりにはなりません。

クラウドは継続実行を解決し、自前サーバーは所有権を解決する

ローカルマシン上のエージェントの上限は物理的なものです。複数のセッションが同時に依存関係のインストール、コンパイル、完全なテストスイートの実行を行うと、CPU、メモリ、ディスク、ネットワークが互いに競合します。また、ノートパソコンを閉じたり、ネットワークから切断したりすると、長時間のタスクが中断される可能性があります。クラウドエージェントは各タスクを分離された環境に配置し、並列かつ無人で実行でき、スマートフォンやSlackから開始するのも簡単です。

Cursorは2026年6月に、社内のPRの40%以上がすでにクラウドエージェントからのものであり、その割合はまだ増加していると公表しました。Davidは8月31日の記事でこの数字を「60%に近い」と書きましたが、キャプチャされたX Articleには [image here] しか残っておらず、その図はありませんでした。この傾向には公式資料による裏付けがあります。しかし、60%という正確な数値は現時点では著者の見解であり、その後の70%、80%、90%は予測です。

商用クラウドエージェントは同時に、新たな依存関係をもたらします。環境設定、キー、セッション履歴、価格設定、データがすべてベンダーのシステムに結びついています。Davidの妥協案は、VPSをレンタルし、その上でHerdrを実行し、SSH経由でコンピューターやスマートフォンから接続するというものです。ターミナルセッションはサーバー上に残るため、ローカルマシンがネットワークから切断されてもリモートプロセスは停止せず、異なるエージェントCLIを引き続き使用できます。

原文では、非常に具体的な構築プロセスが示されています。Davidはcmuxの左側でプログラミングエージェントを開き、右側に空のターミナルを残します。そして、エージェントに、他のペインを操作できるSkillを通じて新しいVPSにアクセスさせ、Herdr、Node.js、Python、Git、Piをインストールさせます。数回のプロンプトの後、二組のリモートエージェントがサーバー上で継続的に実行できるようになり、彼のMacBookがシャットダウンしても中断されません。この事例は、「自前のクラウド環境」がどのように実現されるかを補完すると同時に、同じ自動化のリスクを露呈しています。つまり、プロセス中にエージェントがローカルマシンからOpenRouterキーを見つけ出し、リモートで完全なルート権限を取得してしまったのです。スピードと制御は両方とも本物ですが、そのため、キーの分離、最小権限、再構築可能な環境は欠かせません。

「わずか十分ほどで構築完了」や「数ドルで80/20を実現」という記述は、順調なデモを説明したものであり、長期的な所有コストではありません。自前サーバーはユーザーに制御権を返しますが、同時に、システムパッチ、キーのローテーション、バックアップ、ログ、侵入対応、障害復旧もユーザーに返します。個人の実験環境では、このような交換は許容できるかもしれません。しかし、本番リポジトリと実際のキーに接続すると、運用能力そのものが製品の一部になります。

モデルとサブスクリプションは交換可能な計算リソースであり、ワークフローの中心ではない

Davidは複数のサブスクリプションを同時に購入しており、「より少ないコストでより多くの利用可能なトークンを得る」ことを目指しています。彼は、プランニング、新規プロジェクト、難解なバグ、日常的なチャット、フロントエンドのタスクを異なるモデルに割り当てます。また、新しいモデルがリリースされたら、ソーシャルメディアの評判に従わず、一日かけて自分でテストすることを推奨しています。

方法は維持できますが、買い物リストをそのまま真似ることはできません。原文にリストアップされたプランの価格、使用量の倍率、モデル名、相対的なランキングは、すべて2026年第三四半期に紐づいています。著者自身も、二ヶ月後には完全に変わっているかもしれないと述べています。サブスクリプションの隠れた制約には、ピーク時のレート制限、同時実行制限、モデルの切り替え、プラットフォームのポリシーも含まれており、月額料金だけを比較すると、これらの容量の境界を見落とすことになります。

彼の「絶対にAPI料金を払ってはいけない」という発言も、一つの使用方法のみを対象としています。つまり、既製のクライアントを個人が高頻度で対話的に使用する場合です。プログラムによるバッチ処理、安定した割り当て、リクエストごとのコスト帰属、サービスアカウント、無人での本番タスクが必要な場合、APIは別の種類の制御能力を提供します。サブスクリプションとAPIは同じ商品ではなく、百万トークンあたりの表面価格だけで判断することはできません。

より持続可能な方法は、タスクルーティングを確立することです。つまり、タスクに必要な推論の強度、許容できる遅延、一度の失敗による損失の大きさ、分離環境の必要性、別のモデルによるレビューが必要かどうか、といった基準です。モデルとプランは、このルーティングテーブルの中で、常に交換されるベンダーに過ぎません。

高スループットはプリセットとガードレールによって達成され、全面委任によって達成されるものではない

原文で最も実用的なルールは非常にシンプルです。繰り返される単一ステップのアクションはテキストスニペットにし、繰り返されるマルチステップのプロセスはSkillにします。これにより節約されるのは、一度に数十文字の入力ではなく、毎回、順序を思い出し、漏れをチェックし、受け入れ条件を説明するという認知コストです。

Davidの /total-review は、二つの異なるモデルに同じ変更をレビューさせ、重複を除いて一つの問題リストにまとめます。/ask-then-build は、実装前に重要な選択肢を項目ごとに尋ねます。彼はまた、再帰的なレビューに反対しています。「あと五つ問題を見つけて」とモデルに要求すると、モデルはしばしば五つを埋めようと努力し、たとえ残りが想像上のバグであってもです。レビューは、変更の規模と失敗のコストによってトリガーされ、明確な停止条件を持つべきです。

権限も同じ階層に従うべきです。Davidは短いエイリアスを使用して権限バイパスモードを直接起動します。これは、分離され、再構築可能で、機密性の高い認証情報がない環境では、確かに手順を省きます。Piの公式セキュリティドキュメントは、それがサンドボックスではないことを明確に注意喚起しています。この設定を日常のホストや本番環境にコピーすると、速度の利点は変わりませんが、誤ったコマンドの影響範囲はまったく異なります。

Worktreeは並行変更が互いに上書きする問題を解決し、ADRはコードから逆算できないアーキテクチャ上の理由を保存し、本番データベースの読み取り専用ロールはエージェントが実データを確認できるようにしながら、直接書き換えることはできません。また、単一ライターのリリースロックは、マージ、検証、プッシュ、CI、デプロイ、ヘルスチェックを、制御された出口として直列化します。これらの実践は共通して、エージェントがタスクの完了に必要な権限を取得できる一方で、タスクに関係のない破壊的な能力を取得できないようにすることを実現しています。

テストにも階層化が適用されます。小さな変更のたびに単体、統合、エンドツーエンドのテストを要求すると、リポジトリが肥大化します。一方、テストを完全に禁止すると、回帰の証拠が失われます。リスクと既存のテスト戦略から出発し、同じ種類の失敗が再発するのを防ぐための最小限の証拠を追加すべきであり、テストファイルの数で真剣さを測るべきではありません。

一般ユーザーは、一つのメインと一つのサブからなるワークステーションから始められる

Davidが二十〜三十のエージェントを同時に実行する構成は、彼の作業量とサブスクリプション容量に応じたものです。大多数の人が最初からこの規模をコピーすると、クォータをより早く消費し、注意を細切れにしてしまうだけです。まず、より小さなループを構築することから始めると良いでしょう。

1. メインとサブを一つずつ。 メインエージェントが実装を担当します。独立したレビューは、中規模から大規模の変更の場合のみ、別のモデルに実行させます。まず、レビューが、成果物を変えるような問題を一貫して発見するかどうかを観察します。
2. 一つの分離された作業ツリー。 並行タスクが同じファイルに触れる可能性がある場合にのみワークツリーを開きます。小規模なプロジェクトや単一の変更は現在のブランチに留め、移動コストを削減します。
3. 一セットの結果トレンド。 エージェントセッション、ユーザープロンプト、Gitコミットを記録すると、習慣の変化を観察できますが、三つとも代理指標です。さらに、手戻り回数、マージ後の障害、リードタイム、実際のユーザー結果などを加えて初めて、効率が向上したかどうかを判断できます。

この小規模なシステムの待ち時間、競合率、ローカルリソースが実際にボトルネックになった場合にのみ、ステータスパネル、VPS、商用クラウドエージェントを追加します。拡張の順序は、発生した問題によって決定され、ツールのカタログによって決定されるわけではありません。

この2000時間の構成から残った耐久性のあるものは、エンジニアリングの役割分担図です。エントリーポイントは切り替えコストを削減し、スケジューリングは注意を管理し、環境は継続的な実行を担当し、ガバナンスはスピードを受け入れ可能な結果に変換します。次世代のモデルは変わり、プランも変わり、今日最も人気のあるクライアントも変わるでしょう。しかし、この四つの役割が消えることはありません。