Kentはコードを読まずにどうやって機能をリリースするのか
自分で書いた SaaS を実験場にする。Kent C. Dodds は 90 分のライブ配信で、意図、文脈、プリミティブ、出荷、検証、経済性という 6 群 15 項目の原則からなるデリバリチェーンを実演し、読んでいない agent のコードを実ユーザーに安全に届ける方法を説く。
日本語
コピー
Kent はコードを読まずにどうやって機能を出荷しているか
Kent C. Dodds が自分の SaaS で回している実際のデリバリー・ループ。エージェントが書いた、自分では読んでいないコードをどうリリースするか——15 の原則と、ライブ配信の全記録。AI エージェントは数分で機能を実装する。難しいのはそのあとだ。自分が読んでいない——しかも、誰も読んでいないことがますます増えている——コードを、実際のユーザーに届けること。
9 月 30 日、Kent C. Dodds は MEGA のライブ配信で 90 分を使い、自分の SaaS Kody で実際にやっていることを一通り見せた。デモ用のリポジトリではなく、彼のプロダクト、彼のデリバリー・ループ、彼のゲートだ。今回の Drop は、その配信を自分の技術スタックに持ち帰れる形にした。映像と、それを支える 15 の原則——特定のツールに依存しない原則だ。
このループを一枚で
Kent が回しているのは一本のチェーンで、どの環も、次の環が diff を誰も読まないまま信頼できるために存在している。
- 意図 —— ゴールを決め、コンテキストが揃うまでエージェントと議論を重ねる
- プリミティブ —— ドキュメント化された構成要素。変更はすべてこれに照らして分類する
- 実装 —— エージェントが、エージェント自身のコンテキストで行う
- レビュー —— 別のエージェントと CI が、それぞれのコンテキストで行う
- ゲート —— テスト、プレビュー環境、リスク分類
- スイッチ —— feature flag と実験用オーディエンス。リリースを巻き戻せるようにする
- 本番からのフィードバック —— 可観測性、コストを添えたリリース通知
- クリーンアップ —— 実装者が去ったあとに削除・移行・原則の徹底を担う定期エージェント
このチェーンに「読む」という環はない。8 つのうち 6 つは検証だ。
おまけ：verification-stack-checklist.md —— 1 枚の Markdown チェックリスト。コードがユーザーに届く前に Kent が通すすべてのゲート、レビュアー、スイッチ、クリーンアップをまとめたもの。自分のリポジトリ向けに作り変えてほしい。（3 KB）
verification-stack-checklist.md // gates, reviewers, flags, cleanup
15 の原則
信頼
1. コードを信頼できるのは、検証できるからであって、自分が書いたからではない。 コードを信頼してきたのは、自分で打ち込んだからではなく、確認できるからだ。エージェントは人間より速く書く。この原則は変わらない——変わるのは、検証・ゲート・ロールバックの重要度が上がり、「誰が書いたか」の価値がほぼゼロになることだ。
2. ソフトウェアが何をするものか理解していなければ、良いソフトウェアは作れない。 プロダクトの文脈から切り離されたプロセスは空殻だ。以前はこの部分を外に出せた。PM がユーザーを理解し、自分がチケットを引き受ける。いまチケットを引き受けるのはエージェントだ。人間の仕事は、ユーザーと痛みと意図を理解することになった。
3. ユーザーのフィードバックでは、提案された解決策ではなく核心の課題を探す。 ユーザーが出す解決策が役に立つこともあるが、たいていはノイズだ。その下にある痛みを見つける。初期段階では、どのフィードバックも真剣に吟味する。ただし実装を約束はしない——同時に、自分が解こうとしている問題の領域で本物の問題を報告してくれるユーザーは手放さない。
コンテキスト
4. 実装を求める前に、共有コンテキストを揃える。 自分が知っていることはすべてエージェントに渡す。すでに答えを持っている問いも含めて。噛み合っていなければ、コードが一行も書かれる前にズレを捕まえられる。まず意図を固め、それから「実装して」と言う。
5. 抽象の階段をひたすら上へ登る。 Tab 補完 → コードを見ながら対話 → 対話から直接編集 → エージェントがエージェントを管理。役に立つ動きは常に上へ。いま自分がやっているこの作業、エージェントにできるか？ と繰り返し問う。できるなら渡す。安定してできないなら、安定してできるようにする。
6. 永続する知識はリポジトリに住む。エージェントの記憶ではない。 会話履歴を一切持たない真新しいエージェントでも、良い結果を出せるべきだ。ビジョン、不変条件、決定の記録、コントリビューションのルール、システム構造——すべてリポジトリに置く。目指すのはエージェント非依存。モデルを替えても harness を替えても、プロダクトの頭脳は失われない。
7. 摩擦ログでプロジェクトを自己修復させる。 エージェントはさまざまな苦痛——起動の遅さ、壊れたスクリプト、欠けたドキュメント——を黙って迂回し、決して文句を言わない。摩擦を記録するよう指示する。定期クリーンアップ・エージェントが根本原因を直し、以降の実行はそのたびに安くなる。
プリミティブ
8. プリミティブは、エージェントがゴミを作るのを止める仕組みだ。 構成要素——auth、UI の画面、ストレージ、課金——を明文化し、すべての変更に自己分類を強制する。再利用、組み合わせ、拡張、あるいは（ごくまれに）新しいプリミティブの追加。ドキュメントを一度に全部出すのではなく、漸進的に見つけさせる。新しいエージェントは新入社員と同じで、情報過多は混乱させるだけだ。変更がどのプリミティブに触れるかで低・中・高リスクに格付けすれば、エージェントは自然と最小の安全な変更を選ぶ。
デリバリー
9. 両方向ドアを優先する。それが無理なら feature flag を使う。 まず、その決定がどれだけ簡単に撤回できるかを問う。ユーザーが依存する公共のプリミティブをリリースするのは片方向ドアだ。feature flag と「実験的、壊れるかもしれない」オーディエンスは、多くの片方向ドアを両方向ドアに変える——リリースし、学び、撤回する。謝罪メールは要らない。
10. エージェントはコードを消さない。クリーンアップは意図的にやるしかない。 エージェントはフォールバックを足すだけで、レガシーな経路を永遠に残す。削除する金は誰も払わない。移行はクリーンアップ issue で追跡し、なぜ削除が安全だと言えるのかを書き出す。使われていない経路には計装を入れる。定期的に「レガシー掃除人」を走らせ、安全なものはそのまま削除、安全でないものは計装を足す——テストとドキュメントも同じだ。
11. まず手作業で無理やりやり、次に自動化し、最後に決定的なものにする。 つらい作業を手でやる。本当の問題を理解できるまで、十分に長くやる。その後で：手動 → Agent → 繰り返せる部分を決定的なソフトウェアにする。Agent はあなたの苦しみを感じないので、明示的に要求しない限り、作業を耐久性のあるソフトウェアとして定着させてくれない。どの Agent からも呼び出せるソフトウェアは、特定ベンダーの囲い込まれた庭に閉じ込められた自動化より強い。
検証
12. 実装者とレビュアーを分ける——コンテキストウィンドウを別にする。 その変更を構築した Agent を唯一のレビュアーにしてはいけない。独立した AI レビュアーと CI が、それぞれ自分のコンテキストで動くことで、著者のコンテキストでは正当化されてしまうものを捕まえられる。実装者にはこう伝える：レビューの指摘は検証すべき提案であって、命令ではない。まずレビュアーを手で使い、それからこのループを自動化して信頼を築く。
13. Agent が書いたテストはゲートとして不十分。 同じ Agent が機能もテストも書いた？ CI が緑になるのは弱いシグナルでしかない。diff を読まずにリリースする勇気は、積み重ねの上に成り立つ：強力な AI レビュー、CI、Agent が実際に操作できるプレビュー環境、フィーチャーフラグ、そして本当にテスト済みの災害復旧。テストは重要だ。テストだけでは足りない。
経済性
14. 支出は価格ではなく、生み出した価値で測る。 並列 Agent には実際の金がかかる。まずコストを削る：摩擦のログ、より良いドキュメント、決定的なソフトウェアパッケージ。それでも金がかかるなら、届けるものの価値がコストを上回ることを確かめる——そしてコストと難易度をリリースノートに書き、自分に対して正直であり続ける。
15. あなたの独自の価値は、もうコードの実装ではない。 てこの効果こそがこのすべての理由であって、「常にもっと多くを届ける」ことではない。実装を外に出し、注意力は判断、プロダクトの方向性、難しいトレードオフ、そしてチケットに収まらない長い会話に残す。コードを書くことは、もはや人間だけの価値提案ではない。想像すること、判断すること、気にかけることは、依然としてそうだ。
MEGA における位置づけ
この共有は第 3 週——プロダクト——の縮図だ。Kent のこの週は、上のループを持ってきて自分のリポジトリ上で組み立てさせる：プリミティブの記録、レビュアーの分離、空の diff で失敗するゲート、自分の変更で通ること、フラグ、そしてすべてを正直に保つクリーンアップ agent。第 2 週は Angie とともにループが依存する agent を構築する。第 4 週は John とともにそれを工場にする。
参考資料
- I was wrong about MCPs - Kody のケイパビリティ層。原則 8 をアーキテクチャとして表したもの
- Don't make the agent remember how to do its job - 原則 11 の実践：プロセスがパッケージになる
- Towards Autonomous Product Development - 同じループを、クラウド上でオーケストレーターとワーカーで動かす
- Kody、オープンソース：github.com/kentcdodds/kody
おまけファイル：verification-stack-checklist.md — 1 ページの Markdown チェックリスト：Kent があらゆるものがユーザーに届く前に走らせるゲート、レビュアー、フラグ、クリーンアップタスク——自分のリポジトリに合わせて作り変えよう。（3 KB）
verification-stack-checklist.md // gates, reviewers, flags, cleanup