Full Walkthrough: Workflow for AI Coding — Matt Pocock

Main ideas / lessons

• AI has constraints that change how you should plan work

  • LLMs operate with a “smart zone” (best quality early in a session) and a “dumb zone” (degradation as context grows).
  • LLMs also behave like “Memento”-style forgetters: each session effectively resets to a system prompt and earlier context is discarded unless you manage it.

• Software engineering fundamentals still apply (and actually help more with AI)

  • Use classic practices like:
    • keeping tasks small (“don’t bite off more than you can chew”),
    • designing for testability,
    • using feedback loops (tests/type checks),
    • modular architecture (prefer “deep modules” with clear interfaces).

• Planning must be human-in-the-loop; implementation can become more AFK

  • The alignment/planning (“grilling”) phase requires active human participation.
  • After planning yields well-defined tasks, implementation can be delegated to agents that run more automatically (“AFK”/asynchronous).

• Avoid “specs-to-code” / “vibe coding”

  • Don’t rely on writing only specs and repeatedly regenerating code without understanding/moderating the codebase.
  • The code is the battleground; you need to keep ownership through structure, tests, and human review.

• Use an “alignment asset” approach

  • Instead of jumping straight to plans, use a structured interview (“grill me”) to reach a shared understanding, and then convert that shared understanding into a destination document.

---

Methodology / workflow presented (detailed)

Core LLM constraints to manage

Smart zone vs dumb zone

• Keep the working context small enough that model reasoning stays reliable.
• Use a rough marker: around ~100K tokens (context size beyond that often degrades quality).
• Result: split work so each reasoning/implementation chunk stays in the smarter region.

Session phases (typical LLM session lifecycle)

• System prompt: should be as small as possible.
• Exploratory phase: agent explores codebase/relevant context.
• Implementation phase
• Testing/feedback loop phase
• Clearing context resets back to system prompt.

Compacting

• Optional technique to squash conversation history into a smaller record.
• Preference: avoid compacting when possible; prefer consistent “reset” behavior.

---

Overall end-to-end workflow (“Workflow for AI Coding”)

1. Start from an idea / client brief

   • Example: student retention drop; add gamification.

2. Grilling / alignment session (human-in-the-loop)

   • Use a “Grill Me” skill to:
     • relentlessly ask questions until shared understanding is reached,
     • walk decision-tree branches and resolve dependencies,
     • ask questions one at a time with recommended answers.
   • Output becomes an asset: a conversation history that encodes the design concept.

3. Turn the grilled shared understanding into a PRD (destination document)

   • Create a PRD as the “destination”:
     • Problem statement
     • Solution overview
     • User stories
     • Implementation decisions
     • Testing decisions
     • (Also includes out-of-scope / negatives to preserve “no-go” decisions)

4. Convert PRD into a Kanban board of issues (implementation planning)

   • Break PRD into independently grabbable tasks with blocking relationships.
   • Some tasks should be labeled/typed AFK (can be delegated to agents).
   • Tasks become a backlog for implementation agents.

5. Use “vertical slices / traceable bullets” instead of horizontal layering

   • Problem with horizontal phases:
     • AI codes layer-by-layer (schema first, then API, then UI), but you don’t get integrated feedback until late.
   • Vertical slice approach:
     • Each slice crosses multiple layers (DB/service/API/route/UI) and yields early end-to-end feedback.

6. Run agent implementation in an AFK loop

   • Feed local issue files to an implementer agent.
   • The agent:
     • explores repo,
     • uses TDD,
     • applies changes,
     • runs feedback loops.

7. Automated review + manual QA (“impose taste/opinion back”)

   • Let the agent run:
     • tests,
     • type checks,
     • AI-based code review (before human QA).
   • Then humans QA manually for correctness and quality.
   • QA is described as crucial for avoiding “slop.”

8. Iterate by expanding the Kanban board during QA

   • QA can produce new issues/tasks, which block/extend the backlog.
   • Keep looping until code quality is “done” enough for team review.

9. Parallelization support (optional in workshop; concept emphasized)

   • Implementers can run in parallel after tasks are properly decomposed.
   • A “planner” selects issues to run concurrently.
   • A “merger” merges branches and resolves conflicts, re-running checks.

---

Instructions captured from tools/skills described

“Grill Me” skill (planning/alignment)

• Prompt behavior
  • “Interview me relentlessly” about every aspect until shared understanding.
  • “Walk down each branch of the decision tree,” resolving dependencies.
  • “For each question provide recommended answer.”
  • Ask questions one at a time (structured interview).
• How it’s used
  • Pass the client brief as input.
  • Optionally ask follow-up questions to deepen understanding.

“Write a PRD” skill (destination doc creation)

• Typical PRD contents (as shown)
  • Problem statements
  • Solution
  • User stories
  • Implementation decisions
  • Testing decisions

“Ralph loop” / AFK implementation agent (delegation)

• Workflow
  • Use a backlog/curated list of AFK tasks.
  • Output “no more tasks” when complete.
  • Pick next task (priority-based selection).
  • Explore repo.
  • Complete task using TDD.
  • Run automated feedback loops (tests, type checking).
• Infrastructure
  • Demonstrated using a Docker sandbox approach to avoid local installs and to keep setup reproducible.

TDD technique (used inside implementation)

• Red-Green-Refactor
  • Write a failing test first (red),
  • make it pass (green),
  • refactor if needed.
• Why it helps
  • Adds real tests to the codebase.
  • Makes it harder for the AI to “cheat” by producing code that only satisfies tests written afterward.
  • Improves reliability of agent output.

---

Key conceptual analogies / rationale

• Smart vs dumb zone uses a token-attention scaling analogy: attention relationships scale badly as context grows.
• Memento-like forgetting motivates minimizing system prompt size and managing session context.
• Traceable bullets / vertical slices
  • Horizontal “layer-by-layer” coding delays integrated feedback.
  • Vertical slices produce frequent “I can see where this is going” signals.
• Shallow vs deep modules (Ousterhout-inspired)
  • Bad: many shallow files with complicated dependencies → hard for AI to reason/test.
  • Good: deep modules with small interfaces → easier testing and better agent behavior.

---

Speakers / sources featured

Speaker(s)

• Matt Pocock (main presenter; also referenced as workshop organizer)

Other named people / authors

• Dex Hardy (Human Layer; “smart zone/dumb zone” concept)
• Martin Fowler (refactoring; “don’t bite off more than you can chew” style advice)
• The Pragmatic Programmer (referenced as supporting guidance)
• Frederick P. Brooks (quote from The Design of Design, “design concept” / shared understanding)
• Ralph Wiggum (coined framework-like term for PRD-driven loop)
• John Ousterhout (deep vs shallow modules; referenced via The Philosophy of Software Design)

Tools / systems mentioned (as sources of capability, not speakers)

• Claude Code (used in demonstrations; workshop notes mention liking/disliking parts of Claude Code UI)
• Claude / Opus / Sonnet (model/tool names used for roles like planning vs reviewing)
• Gemini (mentioned as an example for feeding meeting transcripts)
• Slido (for Q&A voting)
• GitHub (for repository and issues-based PRD/issue storage)
• Docker (for AFK agent sandboxing)
• TDD / npm test / type checks (practices/tools used in the described implementation loop)
• Sandcastle (speaker’s described TypeScript library for AFK loops and parallelization)