人間の介入は失敗のシグナル
ヒューマン・イン・ザ・ループ = ボトルネック
ヒューマン・イン・ザ・ループ = ボトルネック
自動運転について考えてみてください。人間がハンドルを握らなければならない時、それは機能ではなく、システムの失敗です。車がその状況を自力で処理できなかったのです。
なぜコーディングは違うと言えるのでしょうか？
次のような状況に陥った時：
- AIの中途半端なコードを修正している
- 明らかな間違いを手動で直している
- タスクを通してエージェントを一歩一歩導いている
- 同じ要件を繰り返し説明している
...それは「人間とAIの協調」ではありません。AIが仕事を果たせていないだけです。
Oh My OpenCode はこの前提の上に構築されています：エージェンティックな作業への人間の介入は、根本的に誤ったシグナルです。システムが正しく設計されていれば、エージェントはあなたの子守りを必要とせず、仕事を完遂するはずです。
見分けのつかないコード
目標：エージェントが書いたコードは、シニアエンジニアが書いたコードと見分けがつかないものであるべきです。
「手直しが必要なAI生成コード」ではありません。「良い出発点」でもありません。実際の、最終的な、本番環境で使えるコードです。
これは以下を意味します：
- 既存のコードベースのパターンに正確に従う
- 指示されなくても適切なエラーハンドリングを行う
- 実際に正しいことをテストするテストコード
- AIによる粗雑なコード（オーバーエンジニアリング、不必要な抽象化、スコープクリープ）がない
- 価値がある場合にのみコメントを追加する
コミットが人間によるものかエージェントによるものか見分けがつくなら、そのエージェントは失敗しています。
トークンコスト vs 生産性
生産性を著しく向上させるのであれば、より高いトークン使用量は許容されます。
より多くのトークンを使って：
- 複数の専門エージェントに並行して調査させる
- 人間の介入なしに仕事を完全に終わらせる
- 完了前に作業を徹底的に検証する
- タスクを超えて知識を蓄積する
...これらは、10倍、20倍、あるいは100倍の生産性向上を意味するのであれば、価値ある投資です。
しかし：
不必要なトークンの浪費は追求しません。システムは以下に向けて最適化されます：
- 単純なタスクには安価なモデル（Haiku, Flash）を使用する
- 重複する探索を避ける
- セッション間で学習内容をキャッシュする
- 十分なコンテキストが集まったら調査を停止する
トークン効率は重要です。しかし、仕事の質や人間の認知的負荷を犠牲にしてまで優先されるべきではありません。
人間の認知的負荷を最小化する
人間は「何が欲しいか」を言うだけでいいはずです。それ以外はすべてエージェントの仕事です。
これを達成するための2つのアプローチ：
アプローチ 1: Ultrawork
ただ "ulw" と言って立ち去るだけ。
あなたの発言: ulw add authentication
エージェントは自律的に：
- コードベースのパターンとアーキテクチャを分析する
- 公式ドキュメントからベストプラクティスを調査する
- 実装戦略を内部的に計画する
- 既存の規約に従って実装する
- テストとLSP診断で検証する
- 何か問題があれば自己修正する
- 100%完了するまで岩を押し続ける
介入ゼロ。完全な自律性。結果だけを。
アプローチ 2: Prometheus + Atlas
戦略的なコントロールが必要な時。
Tabを押してエージェントを切り替えた後: add authentication
Prometheus (戦略プランナー):
- 並列エージェントを通じて深いコードベース調査を行う
- 知的で文脈に沿った質問であなたにインタビューする
- エッジケースとアーキテクチャへの影響を特定する
- 依存関係を含む詳細なYAML作業計画を生成する
Atlas (マスターオーケストレーター):
/start-workを通じて計画を実行する- 専門エージェント（Oracle, Frontend Engineerなど）にタスクを委譲する
- 効率のために並列実行の波を管理する
- 進捗を追跡し、失敗を処理し、完了を保証する
あなたが設計し、エージェントが実行する。完全な透明性。
どちらの場合も、人間の仕事は何が欲しいかを表現することであり、どうやってそれを実現するかを管理することではありません。
予測可能、継続的、委譲可能
理想的なエージェントはコンパイラのように動作すべきです：Markdownドキュメントを入力すれば、動作するコードが出力されるのです。
予測可能
同じ入力があれば：
- 同じコードベースのパターン
- 同じ要件
- 同じ制約
...出力は一貫しているべきです。ランダムでも、驚くようなものでもなく、頼んでもいない「創造的」なものであってはなりません。
継続的
作業は中断に耐えうるべきです：
- セッションがクラッシュした？
/start-workで再開 - 席を外す必要がある？ 進捗は追跡されています
- 数日にわたるプロジェクト？ コンテキストは保持されます
エージェントが状態を維持します。あなたがする必要はありません。
委譲可能
優秀なチームメンバーにタスクを割り当てて任せることができるように、エージェントにも委譲できるべきです。
これは以下を意味します：
- 明確な受け入れ基準、独立して検証される
- 何か問題が起きた時の自己修正動作
- 本当に必要な時だけの（Oracleやユーザーへの）エスカレーション
- 「ほぼ完了」ではなく、完全な仕事
コアループ
[Oh My OpenCode](https://github.com/code-yeongyu/oh-my-opencode) のすべては、このループを機能させるために設計されています：
| 機能 | 目的 |
|---|---|
| Prometheus | 知的なインタビューを通じて意図を抽出する |
| Metis | バグになる前に曖昧さを捉える |
| Momus | 実行前に計画が完全であることを検証する |
| Orchestrator | 人間のマイクロマネジメントなしに作業を調整する |
| Todo Continuation | 完了を強制し、「終わりました」という嘘を防ぐ |
| Category System | 人間の判断なしに最適なモデルへルーティングする |
| Background Agents | ユーザーをブロックせずに並列調査を行う |
| Wisdom Accumulation | 作業から学び、過ちを繰り返さない |
私たちが築く未来
次のような世界：
- 人間の開発者は、AIにどう作らせるかではなく、何を作るかに集中する
- コードの品質は、誰が（あるいは何が）書いたかとは無関係である
- 複雑なプロジェクトも単純なプロジェクトと同じくらい簡単になる（ただ時間がかかるだけ）
- 「プロンプトエンジニアリング」が「コンパイラデバッグ」と同じくらい時代遅れになる
エージェントは不可視であるべきです。 隠されているという意味ではなく、電気や水道、インターネットのように、ただ当たり前に機能するという意味で。
スイッチを入れる。明かりがつく。送電網のことなど考えもしない。
それが目標です。