この記事は、かつてプロダクトを担っていたチームがエンジニア 6 人から 2 人に縮小し、しかも期待される仕事量はそれに見合って減らなかったことを受けて、2 人のエンジニアからなるチームが AI を中心に開発プロセスを作り直した経緯を述べている。著者はその対応を役割の入れ替えとして位置づける。AI を補助ツールとして使うのをやめ、AI をリーダーに、人間を監督者にする。人間に残る仕事は「決定」と「確認」の 2 つだけになる。
この記事で最も特徴的な主張は、よくある生産性向上の主張を退けている点である。記事によれば、現在の AI では単一の実装タスクはむしろ遅くなることが多い。エージェントは何かを書く前に、過去の実装やドキュメントを調査し、計画を立て、業務要件との整合性を確認しなければならないため、単純な作業では合計時間が増えるのである。この説明によれば、利得は別のところから生まれる。人間は主導するのではなく監督するので複数のタスクを同時に走らせることができ、その前提として、それらが走っている間に人間は別のこと（会議や昼食など）をしている必要がある。著者は同様に、これで仕事が楽になるわけではないとも明言しており、むしろより高い集中力と、より頻繁なコンテキストスイッチが求められると論じている。
具体的な主張としては、この体制がゼロから約 1 か月半で構築されたというものがある。著者によれば、12 月初旬時点のチームの土台は「AI 駆動？なにそれ？」という状態だった。それが 1 月下旬にはリポジトリに 37 の Skill と 24 の SubAgent が揃い、2 人のエンジニアで以前の 6 人チームと同等のアウトプットを維持できるようになったという。
要点
- 記事が示す分業では、人間の行為は 3 つである。業務要件の概要を書くこと、生成中に AI からの質問に答えること、そしてその出力を軽く確認・修正することである。その間のすべては AI が担う。
- 構造を支える仕組みは 2 つある。1 つは Skill で、専門知識や求められる振る舞い（どの順序で作業するか、品質基準は何か、失敗時に何をするか）を定義する。もう 1 つは SubAgent で、ある領域に特化した専門エージェントであり、それ自体が Skill を使うこともある。メインエージェントは Skill を使って、SubAgent 群を統括するオーケストレーターとして振る舞う。
- 要件定義のフローは、概要だけを記した Linear の issue から始まる。記事によれば、これは完全に埋める必要はない。続いてオーケストレーター Skill が 3 つの SubAgent を順に実行する。issue を取得して曖昧な点を問いただすアナライザー、業務要件ドキュメントを書くジェネレーター、そしてそれを 10 の基準で採点し、80 点を下回った場合は最大 3 回まで自動修正するバリデーターである。
- 1 つのエージェントを 3 つに分けた理由として挙げられているのはコンテキストの分離である。1 つのエージェントにすべてを与えるとコンテキストが膨れ上がって性能が落ちるのに対し、専門エージェントに分ければ出力品質が安定し、失敗したフェーズだけをやり直せる。
- 質問のループは Claude Code の AskUserQuestion ツールの上に構築されている。これは AI が実行中に人間へ選択式の質問を投げかけ、不明点がなくなるまでループし続けられるようにするものである。著者がこれについて主張するのは、AI が言われたことをやるだけでなく足りないものを尋ね、人間が先送りしがちなまさにその点を突いてくるということである。
- タスクファイルは自己完結するように書かれる。タスク概要、As-Is/To-Be、スキーマ、API 仕様、Given-When-Then 形式の完全なテスト項目、依存関係を含み、実装時に設計ドキュメントを参照せずに済むことを明確に意図している。その理由は、これらのタスクを別々の AI セッションが並列に実装するため、タスク間のコンテキスト依存をゼロにしなければならないからだとされる。
- 実装は TDD で進み、CI が通った後に
code-simplifierエージェントが無条件で実行され、続いて技術レビューと仕様レビューが並列に走る。両方が 80 点以上で、かつ Critical または High の指摘がないことが求められ、満たさなければ自動修正ループが回る。記事は制御パラメータとして、実装の反復は最大 4 回、レビューの反復は最大 3 回と示している。 - 並列化は
git worktreeで実現されている。共有のエピックブランチからタスクごとに 1 つのワークツリーとブランチを切り、それぞれに独自の Claude Code セッションを割り当てる。 - GitHub 上では、ローカルで使うものと同様の Skill と SubAgent を Claude Code ではなく Codex で実行している。理由として挙げられているのは、別のエージェントを使うことでより多角的なレビューが得られるということである。このワークフローは変更された言語を検出し、対応するレビューを並列に実行し、すべてのスコアが 80 点を超えればプルリクエストを自動承認する。
- ブランチ戦略により、AI の承認は人間のレビューの代替ではなく前提条件になっている。フィーチャーブランチは AI の承認だけでエピックブランチにマージされ、すべてのフィーチャーブランチがマージされて AI がエピックを承認して初めて、人間がそれをレビューする。
- さらに先へ進むうえでの限界として 2 つの障害が挙げられている。1 つは暗黙知である。AI は書かれたことだけを忠実に実装するため、仕様の穴をそのまま再現してしまう。もう 1 つは人間のキャパシティである。多数のタスクが同時に走ると、2 人ではすべてのプルリクエストを読み切れない。
- 1 つ目への対応は、コードベースに埋め込んだ 5 層の暗黙知の階層である。プロダクトコンテキスト、コーディング規約、品質基準（ゴールデンファイル）、リファレンス、ワークフローから成り、著者によれば、これによって AI は新しく加わった人間のチームメンバーと同じように層を順にたどって作業できる。
- 全体を通じた主張は著者が自分のチームについて語ったものであり、ほぼすべてが定量化されていない。「6 人分のアウトプット」という比較は測定された結果ではなく成果として述べられているにすぎず、記事自身もこの体制の構築にかなりの労力がかかったことを認めている。唯一示されている導入前後の数値は要件定義フェーズのもので、人間の作業時間は導入前の数時間から導入後は約 10〜20 分になったとされる。
背景
この記事は、著者が一般的な実践の現状と見なすもの、すなわち Skill や SubAgent を導入してはいるが人間が依然としてリーダーであるチームとの対比の中に自らを位置づけている。また、AI によって個々のタスクが速く終わり仕事が楽になるという、広く共有されているが著者は同意しないという期待とも対比している。
今後の取り組みとして挙げられているのは、同じフローをプルリクエストのレビューより先へ拡張することである。E2E テスト環境、リリース対象の自動判定、リリースの自動化、そして自ら修正プルリクエストを作成するエラー監視である。著者は目指す姿を「Linear に issue を書けば、AI が本番リリースまで主導する」と表現している。
並列実装については、記事はその考え方が他所ですでに公開されている実践と多くの共通点を持つと述べ、それを改めて説明する代わりに読者をその資料へ案内している。