Video learning playbook
[03:17] Source statement: the smart/dumb zone idea comes from the founder of HumanLayer (captions render the name as "Dex Hardy"; the actual person is Dexter Horthy, unverified spelling). Attention relationships scale roughly quadratically as tokens are added, like matches when teams join a league. His marker: around 100k tokens the model gets dumber no matter whether the window is 200k or 1M.
[06:27] Multi-phase plans are just a loop written out by hand, "phase N". The Ralph Wiggum practice: specify the destination (a PRD) and repeatedly tell the agent "make a small change that gets closer." He likes more structure than pure Ralph, but that is the skeleton.
[07:57] Every session has the same anatomy: system prompt (keep it tiny; he has seen 250k-token system prompts that start the session already in the dumb zone), explore, implement, test. [09:28] Clearing beats compacting because clearing resets to a known, repeatable state; compacting produces sediment. He runs a status line showing the exact token count at all times and calls it essential; the recipe is an article on his site AI Hero.
[37:41] On 1M contexts: the vendors "shipped you more dumb zone." Good for retrieval over big inputs, not for coding. Smart zone is still about 100k.
[13:02] Source statement: the specs-to-code movement (write spec, generate code, never read the code, edit the spec when it breaks) is "vibe coding by another name," and he tried it seriously before rejecting it: the code is your battleground and you must keep shaping it.
[16:04] Instead, every piece of work starts with the grill-me skill: "Interview me relentlessly about every aspect of this plan until we reach a shared understanding... For each question provide your recommended answer. Ask the questions one at a time." What he actually wants is not a plan artifact but a shared design concept (Fred Brooks, The Design of Design): being on the same wavelength as the agent. Sessions run 40 to 100 questions, up to an hour.
[21:57] Grilling surfaces the questions nobody wrote down (should points be retroactive for existing records?). It also composes: feed a meeting transcript with a domain expert into a grilling session and grill through the assumptions.
[26:24] Task taxonomy that drives the whole system: human-in-the-loop tasks vs AFK (away-from-keyboard) tasks. Planning and alignment must be HITL. Implementation can be made AFK.
[23:13] On frameworks (Spec Kit, OpenSpec, Taskmaster): own your planning stack. When students adopt an opaque stack and it fails, they cannot fix it; inversion of control matters more than any specific tooling.
[29:39] Two documents: one for the destination (PRD), one for the journey (issues). The PRD is user stories, implementation decisions, testing decisions, and an out-of-scope section (which is where rejected options and their rationale live).
[35:19] He does not review the PRD. Reasoning: the only thing reading would test is the LLM's ability to summarize, which is a solved problem; alignment was already achieved in the grilling. [1:26:49] Same logic against endlessly optimizing the PRD with a second model: the value is in alignment and later in QA, not in polishing the destination document.
[32:40] The PRD names the proposed modules to modify. This is the anti-specs-to-code move: the code's shape stays in view from the first planning step.
[39:57] Instead of a sequential multi-phase plan, the PRD becomes a Kanban board of issues with blocking relationships, each independently grabbable, each typed AFK or HITL.
[42:30] Source statement: AI loves to code horizontally, layer by layer (all schema, then all API, then all frontend), which means no integrated feedback until the last layer. The fix is the Pragmatic Programmer's tracer bullets (captions consistently mishear this as "traceable bullets"): thin vertical slices crossing every layer, so each slice ends with something visible and testable.
[45:30] Reviewing the proposed slices is cheap and worth it; he catches the AI proposing a horizontal first slice and corrects it in one line ("the first slice is too horizontal"). Inference: this is the one artifact he does review, because slicing errors are structural and cheap to catch here.
[52:15] Day shift and night shift: humans spend the day planning and queueing work; agents burn through the backlog AFK. [1:01:38] In teams, everything up to the PRD is the team surface (grill with domain experts in the room, prototype for feedback, RFC loops); the board and implementation come after alignment. [1:03:10] Frontend: agents cannot yet judge visual quality in a mature codebase; instead generate three throwaway prototypes behind a route, pick by eye, feed the winner back into grilling.
[53:47] The minimal version is a bash script (once.sh): cat every issue file into a variable, grab the last five commits, run Claude Code with accept-edits permission and the prompt. The loop version runs the same thing repeatedly in a Docker sandbox.
[56:49] Run the once version repeatedly while tuning the prompt before trusting the loop. [1:04:40] Reviews should run in a fresh context: a reviewer sharing the implementer's spent context reviews from the dumb zone; clear first and the review happens in the smart zone.
[1:12:41] QA is where the human imposes taste on the codebase, and it feeds new issues back into the board. Source statement: teams that automate idea, research, QA, everything, ship apps that lack taste. "We are not producing slop here." [58:37] Cost he accepts: this workflow means more code review than before, and he has no fix for that.
[1:14:36] From Ousterhout's A Philosophy of Software Design: shallow modules (many small files, tangled dependencies, unclear test boundaries) are hard for AI to navigate and worse to test; the AI unaided will produce exactly that shape.
[1:17:00] Deep modules expose a small interface over a lot of functionality: wrap the test boundary around the module and the feedback loop gets strong. [1:18:07] Feedback loop quality is the ceiling on agent output quality. [1:19:26] The mental trick: design the interfaces yourself, delegate the implementations; modules become gray boxes, which is how you move fast without losing your sense of the codebase.
[1:21:30] The improve-codebase-architecture skill scans a repo for module-deepening candidates (clusters that should be tested as a unit, services with zero tests). His one-takeaway of the whole talk: run that skill on your repo. His video editor became tractable for AI only after wrapping the whole frontend-to-backend flow in one big externally-testable module.
[1:24:11] Doc rot: implemented PRDs left in the repo poison future agent sessions once the code drifts. He closes them (GitHub issues give a visual done marker); local markdown PRDs he deletes.
[1:29:03] Push vs pull for standards: the implementer should pull coding standards on demand (skills); the reviewer should have standards pushed into its prompt alongside the code.
[1:30:33] The loop: planner picks non-blocking issues, each gets a git worktree in a Docker sandbox with an implementer, commits are reviewed, then a merger agent merges branches and fixes type/test fallout. [1:32:04] Model split: Sonnet implements, Opus reviews ("I need the smarts then"). This has been his default flow "for quite a while."
| Name | What it is | Where |
|---|---|---|
| grill-me, write-a-prd, prd-to-issues, tdd, improve-codebase-architecture, better-sqlite3-rebuild | The skill set, visible as repo files under .agents/skills and .claude/skills | 31:40 on screen |
| Ralph Wiggum loop | Destination doc + repeated "make a small change" agent runs | 06:27 |
| Sandcastle | His TypeScript library for parallel sandboxed agent loops (worktree + Docker + planner/implementer/reviewer/merger) | 1:29:03 |
| github.com/mattpocock/course-video-manager | His real work repo, 744 closed issues as PRD/issue history; Sandcastle lives in .sandcastle/ there | 33:48, 91:20 on screen |
| AI Hero (aihero.dev) | His site; article with the token status line recipe | 09:28 |
| HumanLayer | Company whose founder coined smart/dumb zone | 03:17 |
| Books cited | The Pragmatic Programmer (tracer bullets), Refactoring (Fowler), The Design of Design (Brooks), A Philosophy of Software Design (Ousterhout, deep modules) | throughout |
Routing 2026-08-02 (orchestrated same day, plan: active/alexana-workspace/working-files/plans/pocock-candidates-build-v1.md): 1 implemented (absolute token count added to the existing statusline), 2 and 3 implemented (orchestrate-flow.md vertical-slice and criteria-push rules), 6 implemented (Repo Plan Docs closure rule in build-and-design-docs.md), 4 and 5 routed to personal todo.md Backlog (4 blocked on a grill session, 5 {agentic} for the next session).
[09:28] He calls the exact-token-count status line essential for staying out of the dumb zone; this machine has no status line configured.
[39:57-45:30] Orchestrate currently writes sequential phased plan docs; his argument is phases are a hand-written loop that cannot parallelize and defers feedback. Adding a "slices must be vertical, issues carry Blocked by and AFK/HITL type" rule to the plan step would let gates catch horizontal slicing the way he does.
[1:04:40, 1:29:03] Never let a reviewer share the implementer's spent context; push coding standards into reviewer prompts, let implementers pull skills. Orchestrate's gates already use fresh subagents; the push-standards-to-reviewer half is not written down anywhere.
[53:47, 1:30:33] The agentic-tasks.md Ready to Run list is already a typed backlog; a once.sh-style runner (cat ready tasks + guardrails into a headless claude run in a worktree, review before merge) would make it a real night shift, and Sandcastle is the reference design for the parallel version.
[1:21:30] His single takeaway: run improve-codebase-architecture on a real repo. The mattpocock-skills plugin is already installed; candidate first target is fleet-control or the IV site repo.
[1:24:11] Implemented plan docs that outlive their accuracy poison future sessions; his fix is closing issues for the visual done marker. The vault already has archived/ conventions and the spider, but repo-side plan docs in ~/Projects have no close-on-completion rule.
Save the playbook to read later, or hand the raw notes to your favorite AI.
The Markdown file (a .md file) is a plain-text copy of this whole playbook, written in the simple format AI chat tools read best. It keeps the headings, links, timestamps, and captions and drops all the page styling. Think of it as the raw notes behind this page, ready to hand to an assistant.
To use it, download the file and drag it into ChatGPT, Claude, or any AI chat (or just paste the text in), then ask for what you want: “Summarize this into a one-page cheat sheet,” “Turn these steps into a checklist I can follow,” or “Quiz me on the key ideas.” Because the file is already structured, the assistant works from the real content instead of guessing.