Full Walkthrough: Workflow for AI Coding — Matt Pocock

2026-08-01 · AI Engineer and Matt Pocock

概要

Matt PocockによるAIコーディングのワークフロー実演ワークショップ。LLMには「スマートゾーン/ダムゾーン」と「メメント的な記憶喪失」という2つの制約があり、それを前提に「grill me（徹底的に質問させる）→ PRD作成 → カンバン式のタスク分割 → 実装」というプロセスを組む方法を、実際のリポジトリ上でClaude Codeを動かしながら解説している。核となる主張は「AIは新しいパラダイムだが、ソフトウェア工学の基礎（タスクを小さく、垂直スライス、コードを手放さない）はAI相手にもそのまま効く」というもの。

主なポイント

スマートゾーン/ダムゾーン（HumanLayerのDex氏の概念）: トークンを足すごとにattentionの関係数が二次関数的に増え、およそ100kトークン付近からLLMは目に見えて劣化する。200kでも1Mでもこの境界はほぼ変わらない。
1Mコンテキストは「ダムゾーンが増えただけ」。長文からの検索・retrievalには有効だが、コーディングには向かない。現時点の実用的なスマートゾーンは約100k。
compactよりclearを推奨。compactは会話を要約履歴に潰して「堆積物」を残すが、clearならシステムプロンプト直後の状態に必ず戻る。この「常に同じ初期状態」を再現できることが最適化の前提になる。
システムプロンプト（常駐コンテキスト）は極小に。ここに250kトークン詰め込んでいる人もいるが、それだけで即ダムゾーン行き。
現在のトークン数をステータスラインに常時表示する。ダムゾーンまでの距離を把握するための必須情報（AI Heroに設定記事あり）。
grill meスキル: 「合意に達するまで容赦なくインタビューし、決定木の枝を1つずつ潰し、各質問に推奨回答を添えて、1問ずつ聞け」という数行のスキル。40〜100問に及ぶこともあり、結果として得られるのはドキュメントではなく人間とAIの共有された設計コンセプト（F.P.ブルックス『デザインのためのデザイン』）。
spec-to-code（仕様だけ直して中身を見ない）は否定。実際に試したがうまくいかない。「コードこそが戦場」で、プロセス全体を通してコードを意識し続ける必要がある。
サブエージェントによる探索の分離: exploreサブエージェントは93.7kトークン消費したが、親コンテキストの消費は25k程度に留まる。重い調査は必ず委譲する。
タスクは「human-in-the-loop」と「AFK（離席可能）」の2種に分類。計画・アラインメント段階は必ず人間が張り付く必要があり、Ralphループ化できない。実装はAFK化できる。
PRDは「目的地」、カンバンは「道のり」。PRDには問題/解決策/ユーザーストーリー/実装判断/テスト判断/変更予定モジュールを含め、タスクはブロッキング関係を持つチケット群に分割し、各チケットにAFK/human-in-the-loopのラベルを付ける。
分割の指針はトレーサー弾（垂直スライス）（『達人プログラマー』）。レイヤー単位ではなく縦に薄く貫く単位で切る。
PRDそのものは読まない: grillingで既にAIと波長が合っている以上、読んでも「要約能力」を検査しているだけになる。LLMは要約は得意。
Spec Kit / OpenSpec / Taskmaster等のフレームワークには依存しすぎない。勝者が決まっていない今は、プランニングスタックを自分で所有して可観測性を保つ（Inversion of Control）。
「悪いコードベースは悪いエージェントを作る」。コードやTypeScriptを深く理解しているほどAIから引き出せる量が増える。

実践に使えること

Claude Codeのステータスラインに現在のトークン数を表示させ、100kを目安に作業を区切る。超えそうならcompactではなく、成果物（issue/PRD）を書き出してから/clearする。
grill me 相当のスキルを自作する。中身は「合意に達するまで1問ずつ、推奨回答付きで、決定木を順に潰しながら容赦なく質問しろ」だけでよい。曖昧な依頼（Slackの一文など）を渡す最初の一手にする。
会議の文字起こしやクライアントの依頼文をそのままgrillingセッションに食わせ、自分が気づいていない前提（例: 既存データを遡って反映するか）を炙り出す。
「grilling → PRD生成 → issue/カンバン化」をスキルとして固定し、各タスクに「何にブロックされるか」と「AFKか人間同席か」を明記させる。
タスク分割はレイヤー横断の垂直スライスで切り、1タスクが100kトークン以内に収まるサイズにする。
探索や調査は必ずサブエージェントに投げ、親コンテキストには要約だけ戻す。
仕様の重要判断は、人間の専門家＋開発者＋AIを同席させたモブ的セッションで詰める（AIが第三者として容赦なく質問する役を担う）。
PRDやissueはローカルの issues/ ディレクトリかGitHub Issuesに蓄積し、作業リポジトリの資産として運用する。