10月17日、Tejas Kumarが「The 5 Levels of Agentic Coding: Why I Mostly Stay at Level 2」と題した記事を公開した。この記事では、AIエージェントを使ったコーディングを5段階に分類し、実際に4本のプロダクションアプリを開発した経験から、各レベルの実態とコストについて詳しく紹介されている。
エージェントコーディングとは何か
エージェントコーディングとは、AIエージェントに対してやりたいことを伝え、エージェントが自律的にコードを読み、ファイルを編集し、コマンドを実行する中で、人間がその結果をレビューしながらソフトウェアを開発するスタイルだ。著者が使用するのは主にClaude Codeで、エージェントは変更→確認→再実行のループで動く。
よく混同される「バイブコーディング（vibe coding）」との違いは、レビューを省くかどうかだ。Andrej Karpathyが2025年2月に命名したバイブコーディングは「コードの存在すら忘れてしまう」スタイルだが、著者の5レベルではどのレベルでも必ず誰かがコードを読む。変わるのはエージェントの数と、レビュアーが人間かどうかだ。
5段階の全体像
| レベル | 内容 | 弱点 |
|---|---|---|
| 1. 手動 | 全行を手で書く | 時代遅れ |
| 2. 1エージェント | 1会話で指示→実装→レビュー→リリース | 遅い |
| 3. 並列エージェント | 7〜8セッションを別々のgit worktreeで並走 | 後片付けが面倒 |
| 4. ソフトウェアファクトリー | pm・maintainer・sentryがLinearボードをこなす |
自分のプロジェクトで迷子になる |
| 5. ??? | 読者への問いかけ | — |
著者のスイートスポットはLevel 2またはLevel 3で、Level 4は「現在進行中の実験」という位置づけだ。
Level 1（全行を手で書く）は今や「時代遅れ」と端的に位置づけられているが、著者がわざわざ起点として置いている意味は小さくない。AIなしで自分のコードベースを完全に把握できるこのスタイルは、後述する「認知的負債」の問題を考えるとき、比較基準として機能する。Level 2以降のトレードオフを理解するには、Level 1が何を保証していたかを知っておく必要があるからだ。
Level 5については、元記事でも「???」として意図的に空白にされている。著者が現時点で答えを持っていないというより、読者とともに考えたいという問いかけとして提示されているものだ。
Level 2が「基本」である理由
Level 2は、1つの会話で1エージェントと作業する形式だ。著者はこれをペアプログラミングに例える。エージェントが「ドライバー」としてコードを書き、自分が「ナビゲーター」として方向を確認する。
遅い、という弱点はある。ただし、その遅さが品質を保つ。変更のたびに差分を確認できるのはLevel 2だけであり、後で自分がデバッグするコードを見落とすリスクが最も低い。
Level 2で特に有効な実践として著者が勧めるのは、「スペック駆動開発」だ。
- まず仕様を詰める。 「自分なしでも構築できるまで、一問ずつ質問してくれ」とエージェントに指示する。曖昧な部分がまだ安い段階で洗い出せる。
- 仕様をリポジトリに残す。 著者のプロジェクトDewfallとDaikuはどちらも
GENESIS.mdというファイルにスペックを保存している。新しい会話のたびにアプリを説明し直す必要がなくなる。 - 差分が小さいうちにレビューする。 Level 2では各変更をリアルタイムで確認できる。この機会を活かす。
Level 3：git worktreeで並列化する
Level 3では、7〜8セッションのClaude Codeを同時に走らせる。各セッションは別のgit worktree（同一リポジトリを別ブランチで別フォルダにチェックアウトする仕組み）上で動くため、エージェント同士がファイルを上書きしない。
Claude Codeの作者であるBoris Cherny自身、ターミナルで5セッション＋claude.aiで5〜10セッションを並走させている（InfoQ、2026年1月）。Simon Willisonも同様の運用を紹介しているが、「タスクは同時に始められても、レビューは一つずつ」という同じ壁に当たっている。
著者が「好きではない」と明言するのがworktreeの後片付けだ。現時点でDewfallのリポジトリには.claude/worktrees/以下に17個のworktreeが放置されており、うち13個はすでにmainにマージ済みだ。
worktreeを楽にする実践
claude --worktree feature-auth（-w）で.claude/worktrees/以下に自動作成。.gitignoreに/.claude/worktrees/を追加する.worktreeincludeファイルに.envなどを列挙すると、新しいworktreeに自動コピーされる- 2つのエージェントには別々のファイルを触るタスクを渡す。 同じファイルを編集させるとマージ時に苦労する（Claude Codeの公式ドキュメントも同様に警告している）
- マージ済みのworktreeをまとめて削除するワンライナー：
git worktree list --porcelain \
| awk '/^worktree /{w=$2} /^branch /{b=substr($2,12); if (b!="main") print w, b}' \
| while read -r w b; do git merge-base --is-ancestor "$b" main && git worktree remove "$w"; done
Level 4：ソフトウェアファクトリーの現実
Level 4は最も野心的な実験だ。著者はDaiku向けにLinearのロードマップを用意し、pm（プロダクトマネージャー役）・maintainer・sentryという複数のエージェントを起動した。pmはコードを書かず、チケットの割り当て・レビュー・デプロイ確認を担い、Claude Codeのクロスセッションメッセージング機能で他エージェントと連携する。
開始から3日後の10月16日時点で、475チケット中273が完了。夜中の0〜6時にも17〜27コミットが積み重なっていた。git logには「修正の修正」まで含む深夜のデバッグ記録が並ぶ。
「自分のプロジェクトを自分で把握できない」問題
著者が率直に認める問題がある。自分のプロジェクトで自分がFOMO（取り残される感覚）を感じている、というものだ。
sentryエージェントがSentryの例外を監視しているはずだったが、実際にはpmに一度も通知を送ったことがなかった。そして10月16日、デプロイでDBスキーマのバージョンが更新されず、約6時間誰もDaikuでタスクを開始できない障害が発生した。気づいたのは著者自身で、エージェントではなかった。
Margaret-Anne Storeyはこれを「認知的負債（cognitive debt）」と呼ぶ。高速に進むことで生まれた負債が「開発者の頭の中に蓄積される」というものだ。元記事では著者がこの概念を引用する形で紹介されている。Simon Willisonも2026年2月に「自分のプロジェクトがどう動くか、もう確かなメンタルモデルを持っていない」と同じ状況を報告している。
著者の場合、DECISIONS.mdは10月16日時点で66,725語に達していた。リポジトリの年齢はわずか12日だ。
ファクトリーで「把握」を保つには
- 決定事項を1ファイルに集約し、差分だけ読む。
git log -p --since=yesterday -- DECISIONS.mdで昨日分だけ確認できる - 全コミットにチケット番号を付ける。
DAI-468のように始めれば、git logがチケット別の変更履歴になる - 定時レポートを自動生成させる。 「今日出荷したもの・壊れたもの・自分で決めたこと・自分が必要なこと」を毎日平文で出力するよう
pmに指示する
Level 4が「動く」のは確かだ。ただし著者は「何が完成したかを知る必要がある」と結論づけ、Level 2の価値を改めて強調する。速度と把握可能性のトレードオフをどこで引くか——それがこの分類が問いかけることの本質だ。
詳細はThe 5 Levels of Agentic Coding: Why I Mostly Stay at Level 2を参照していただきたい。
