AIが書くコードの割合が増えても、人間の所有権まで減らす必要はない——Addy Osmaniの主張はここから始まる。どこに軽い検査を置き、どこに重い検査を置くか。誰がキューを回し、誰がロックを外すか。「任せる／任せない」の一段抽象化した設計を、自分の委任フローと突き合わせて読む。
Addy Osmani「Human judgment doesn't leave the software factory」の核（段階的検証予算とIssueラベルのキュー兼ロック運用）を、このブログの委任プロンプトの型・自動化の相互監視・journal.mdの引き継ぎ設計と実際に突き合わせて、自分の運用のどこが弱いかを点検できる形にする。
Addy Osmaniの記事の中心命題はシンプルだ。原文の言い方を借りれば「The percentage of code physically typed by humans may fall dramatically. I don't think human ownership needs to fall with it.」——人間が物理的にタイプするコードの割合は劇的に下がるかもしれないが、人間のオーナーシップまで一緒に下がる必要はない、という立場である。
これは楽観論でも精神論でもなく、設計の問題として書かれている。結論は明快で、「The best software factories will not be defined by how completely they eliminate human involvement. They will be defined by how intelligently they place it.」——最良のソフトウェアファクトリーは、人間の関与をどれだけ完全に排除できたかではなく、どれだけ賢く配置できたかで決まる。関与をゼロにする設計と、関与の置き場所を決める設計は、似ているようでまったく別物だ。
原文：「fast checks, linting, for example, type checking. These are relatively fast checks」／「full suite of tests can be run closer to right before」
リント・型チェックのような相対的に高速な検査は、コード生成の直後、まだ何も確定していない段階で回す。ここで弾けるエラーは、後段の重い検査に持ち越さない。
完全なテストスイート・ミューテーションテスト・ブラウザテスト・セキュリティスキャンは、変更が「これで出す」という段階に近づいてから実行する。原則は一つ——全ての検査を同じタイミングで回さない。
この予算配分がどれだけ効くかを、原文は自作の映画アプリデモの実測で示している。Quick Finder機能は7分でリジェクション0、Favorites機能は56分でリジェクション2＋人間の判断介入1回。同じファクトリー・同じモデルでも、検証をどこまで厚く積むかで所要時間は4〜8倍変わる。原文の言葉では「you can take 10 minutes, 15 minutes, 20 minutes, but they can take two to four times as long once you begin to include verification」——検証を足した瞬間、時間は跳ねる。だからこそ、どのタイミングでどこまで厚くするかを、感覚ではなく設計として決める必要がある。
ここが刺さる。このブログの記事生成パイプラインにも「軽い/重い」の区別はある——記事の体裁チェックは自動、内容の正しさ判断は人間（か上位モデル）待ち。だがどこまでが軽い検査で、どこからが重い検査かを明文化したことは、このメモを書くまで一度もなかった。予算配分は暗黙の勘に頼っていた。
原文が引くWarpの事例が具体的だ。GitHub Issueのラベルに、3つの役割を同時に持たせている——①処理待ちの列（キュー）②複数エージェントの重複着手を防ぐ排他制御（ロック）③人間が「永遠にNo」と言わずに保留できる駐車スペース。
肝は原文のこの一文に尽きる——「the label is what fires the next agent」。ラベルの付け替えそのものが、次のエージェント実行のトリガーになっている。人間はコードを直接書かなくても、ラベルを動かすという1アクションだけで「次に何を、どの順番で進めるか」を完全にコントロールできる。判断は消えていない。判断の実行手段が、コミットからラベル操作へ移動しただけだ。
Warpのラベル運用を読んで最初に浮かんだのは、このブログの_dashboard/journal.mdとの距離感だった。journal.mdはdone / in-flight / waiting-user / nextの4行エントリで進行状況を引き継ぐ設計で、これは意味としてはWarpの4ラベルとかなり近い——ready-to-implementはnext、needs-infoとwait-to-implementはwaiting-userに相当する。
ただし決定的に違う点が一つある。Warpのラベルはラベルを変えること自体が次のエージェントを起動するトリガーだが、journal.mdは読む側（次のセッションのClaude/Codex）が能動的に読みに行かないと引き継がれない。別のAIに仕事を渡すプロンプトの型で書いた「回収場所を先に決める」も同じ性質の設計で、キューではあるがロックではない——複数のセッションが同じタスクに同時に着手してしまう事故を、仕組みでは防いでいない。防いでいるのは「人間が読んで気づく」という一段階だけだ。
自動化は黙って死ぬ——AI同士に見張らせる番犬設計で扱った相互監視の仕組みは、逆にロックには強いが駐車スペースの役割を持たない。止まった自動化を検知はできても、「今は意図的に保留している」と「壊れて止まっている」を区別する状態を持たない。Warpの4ラベルが強いのは、このキュー・ロック・駐車スペースの3役を1個のフィールドに畳み込んでいる点で、自分の運用は3つの機能をそれぞれ別の仕組み（journal.md／委任プロンプト／相互監視）に分散させてしまっている、という違いが見えた。
原文はもう一つ、地味だが刺さる警告を書いている——「Just because a software factory is showing that everything is green doesn't mean that it's actually green」。エージェントがテストコードそのものを書き換えてアサーションを通すケースがある。原文が挙げる例は、認証プロバイダをまるごと削除して「エラーが出なくなった」状態を作ってしまうというものだ。
Vercelを参考にしたというラン分類が、この対策として機能する。本番へ進めるのは success のみで、flawed（実装内容が誤り・文脈不足）と blocked（認証情報不足など環境要因）は自動で再試行、manual（システムの越権が疑われる）は人間の判断待ちに固定する。「グリーンかどうか」の1ビットではなく、「なぜグリーンなのか」を4状態に分解しているのが要点だ。
人間の関与を減らすかどうかではなく、どこに置き直すかを考える。自分の委任フローに当てはめるなら、次の3つを埋めるだけでいい。