Matt Pocock's Agentic Engineering Workflow

Matt Pocock's Agentic Engineering Workflow

David Ondrej · Matt Pocock · ~62 min · Deep Dive Document
Video thumbnail — Matt Pocock's Agentic Engineering Workflow
⏱ ~62 min 🎤 Matt Pocock · David Ondrej 🏷 Agentic Engineering · Claude Code · Skills · AFK Agents · Software Architecture

📋 Overview

In this wide-ranging podcast conversation, David Ondrej sits down with Matt Pocock — TypeScript educator, creator of one of the most popular agent skills repositories on GitHub, and builder of Sand Castle — to unpack his philosophy on agentic engineering. The core thesis: stop obsessing over models and start investing in the harness. Matt argues that good software fundamentals, well-designed codebases, and procedural skills are the real multipliers for AI-assisted development. The conversation covers the strategic vs. tactical programming divide, why skills are a ceiling on AI output, the teach skill demo, Sand Castle's sandbox architecture, the loops vs. queues debate, and practical advice for anyone wanting to level up their agentic workflow.

1 Strategic vs Tactical Programming

▶ 0:00

Matt opens with a framework borrowed from John Ousterhout's A Philosophy of Software Design: the distinction between tactical and strategic programming.

  • Tactical programming — the on-the-ground, day-to-day work: writing code, fixing bugs, creating commits. AI has essentially eaten this layer. It does tactical programming cheaper and faster than humans.
  • Strategic programming — the general sitting at the top: how the codebase should look, what strategies increase velocity, what interfaces exist between modules. This hasn't changed with AI.
💡 "AI has basically eaten tactical programming. It's gone. So you need to be great at strategic programming in order to get the most out of this infinite fleet of tactical programmers that you now have access to."

The skills needed for good delegation remain the same: design hard parts up front, scope tasks well, think about module interfaces, write good tests, and maintain just enough documentation to point AI to the right places.

2 Your Skills Are the Ceiling

▶ 2:40

Matt argues that developer skills act as a multiplier for AI. If you can oversee a codebase and tell AI how things should be built, AI has much richer context to work with. CTOs and conference attendees consistently tell him the same thing:

  • Senior developers get a 10x boost from AI — they know what to ask for and can evaluate the output
  • Junior developers get a smaller boost — they lack the context to guide AI effectively
  • The implication: it's becoming harder to justify hiring juniors when seniors with AI can cover so much more ground
💡 "Your skills are the ceiling on what AI can do. If your skills are low, then AI is not going to be able to go past that."

Getting good with AI is really about getting good at your domain. A better teacher can use AI to teach better than a random person can. Skills are more important now than they used to be because the multiplier effect is so large.

3 The Teach Skill — Live Demo

▶ 6:00

Matt demos his recently shipped teach skill — a Claude Code skill that encodes teaching principles (zone of proximal development, the knowledge/skills/wisdom framework) to create personalized courses on any topic. He's personally used it to teach himself to solve a Rubik's cube from memory.

How It Works

  1. Mission alignment — the skill starts by asking three questions to understand who you are, what you want to build, and why it matters. It creates a mission.md file.
  2. Resource gathering — it searches trusted resources and builds a curriculum based on your mission
  3. Stateful learning — it saves a learning record locally, tracking what you've learned, your zone of proximal development, and what comes next
  4. Rich HTML lessons — instead of terminal-based learning (which is "brutal"), it outputs lessons as HTML files you open in a browser
  5. Active recall quizzes — embedded quizzes use proven techniques for increasing storage strength
  6. Primary source references — after each lesson, it points you to trusted external resources (e.g., the Pro Git book)

In the demo, Matt pretends to be a vibe coder wanting to ship better software. The skill identifies Git as the highest-leverage gap (not more syntax), creates a personalized lesson, and quizzes David on basic Git commands.

💡 The teach skill is a stateful skill — it remembers previous sessions, your mission, and your progress. Matt distinguishes this from stateless skills that don't need any local memory.

Technical Setup

Matt is running Claude Code with Opus 4.8 at medium effort. Despite the launch of Claude's Fable model the day before, he deliberately hasn't switched — his philosophy is to wait about a month before adopting new models to see how things shake out.

4 Procedures vs Abilities — Two Types of Skills

▶ 17:24

Matt draws a critical distinction between two types of agent skills:

  • Procedures — skills you invoke yourself to get the model to behave a certain way. You are in control. Examples: grill-me (turns the agent into an adversarial interviewer), prd (product requirements document), teach.
  • Abilities — skills the model invokes on its own when it needs them. Examples: coding standards for React, style guides. These leak their descriptions into the context window.
💡 "I tend to prefer my skills as procedures. I like to be the one in control. I don't want to delegate my thinking to the model."

The Grill Me Skill

Matt's most popular skill is grill-me — incredibly short (about five sentences) but "unreasonably effective." It turns the agent into an adversarial interviewer that asks probing questions until you reach a shared understanding. Matt uses it as a replacement for plan mode — before implementing code, he has the agent interview him about his idea to flush out unexpected issues.

His preferred workflow: grill-meprd (product requirements) → break into individual issues → implement. Each step is a separate procedure skill that he controls.

He contrasts this with Superpowers by Opera (the most popular skills repo), which takes the opposite approach — the model is more in control. Matt prefers human control because "I know my abilities. I don't want to delegate my thinking to the model."

5 Knowledge, Skills & Wisdom

▶ 23:50

Matt presents a framework for mastery that applies to both humans and AI-assisted development. To be good at anything, you need three things:

  1. Knowledge — fundamental understanding, having the concept in your head
  2. Skills — having done it enough times that it's in muscle memory
  3. Wisdom — knowing when to do it, understanding how it fits in the real world

Wisdom is the hardest to obtain — it requires actually having done the thing in the exact context where you need it. You can gain knowledge and skills from courses and practice, but wisdom requires real-world experience.

💡 "Being able to bundle knowledge and skills into something that's reusable is such a fascinating outcome of this weird age we're living in."

The exciting possibility: senior developers can now proceduralize their expertise into reusable skills. Just like extracting a repeated function into a shared utility, you can extract your planning process into a skill, distribute it to your team, and raise the floor on what everyone can do.

6 Sand Castle & AFK Agent Setup

▶ 24:50

Matt reveals his actual day-to-day agentic engineering setup:

  • Claude Code locally — Opus 4.8, medium effort, for planning and some implementation
  • Sand Castle — a tool he built to run agents inside sandboxes (Docker/Podman)
  • GitHub Actions — for automated agent runs on PRs

Why Sand Castle?

Without a sandbox, an agent might randomly delete your home directory or exfiltrate environment variables. Sand Castle lets you plug in Docker or Podman to run Claude Code (or other agents) safely inside containers. Key benefits:

  • Parallelization — spin up multiple agents simultaneously on your machine or use remote sandboxes (e.g., Vercel sandboxes)
  • Safety — no file system access outside the sandbox, no credential leakage
  • Pull-back model — agents commit inside the sandbox, you pull commits back to your local workspace

GitHub Actions Integration

Matt combines Sand Castle with GitHub Actions to run agent review actions on PRs. The agent checks out the branch, runs type checks, lint, and code review, then comments on the PR. This enables fully AFK development — you create an issue, the agent picks it up via GitHub Actions, implements it, and opens a PR for review.

7 The Harness Over the Model

▶ 27:45

Matt's central thesis, expressed through a Formula 1 analogy: everyone is obsessed with the engine (the model), but the engine is only part of the system. The chassis (the harness — prompts, skills, codebase quality, environment) matters equally.

💡 "Everyone's obsessed with the model and I think they should be more interested in the harness — what you can do to get the most out of the harness, giving it the right prompts, giving it the right skills to work with, and improving the environment in which the model runs."

His concrete example on token optimization: "People ask me all the time, how do you optimize for token spend? Have a codebase that's easier to make changes in." A better-architected codebase means you can use a cheaper model to get the same results because the guardrails are better, it's easier to explore, and the agent spends fewer tokens banging its head against the wall.

David pushes back — can't you do both? Matt agrees but insists the split should be 50/50, not 90% model / 10% harness as most people treat it. People chase shiny new model releases while ignoring harness optimization that would compound over time.

8 The Bitter Lesson Debate

▶ 29:08

Matt raises the Bitter Lesson from ML research — the idea that raw compute always eventually beats hand-crafted optimizations. He acknowledges this could apply to his harness-first philosophy: maybe instead of optimizing the harness, you should just wait for the models to get better.

His response: "I'm not a pundit. I'm trying to do the best with what I have right now." His strategy is to keep the workspace and harness agent-agnostic and apply good software fundamentals — things that have always worked and will probably continue to work regardless of which model is ahead.

The key distinction from vibe coding: Matt isn't anti-AI — he's heavily invested in AI tooling. The difference is approach. He advocates learning fundamentals and building a proper foundation, rather than jumping to each new tool/model every week. The quintessential vibe coder "switches tools every week" and "never learns any programming principles."

💡 "If your codebase architecture is better, then you can get a cheaper model to do the same work. You're hamstringing your model from day one if you don't invest in good architecture."

9 Queues, Not Loops

▶ 43:00

David brings up the viral Twitter discussion about agentic loops — the idea (originating from Jeffrey Huntley's "Ralph" pattern) of running Claude Code in a while loop until it's done. Matt has strong opinions here:

  • The real discovery was AFK agents — the moment Matt could remove himself from the loop and parallelize, his output exploded. "Suddenly there are two of me, three of me, four of me."
  • Loops are the wrong metaphor — he prefers to think in queues. Development is fundamentally a queue of tasks: project managers add items, developers pick them off. Multiple nodes (humans and agents) process the queue.
  • Ralph loops are overkill — you don't need an infinite loop. You need an AFK agent to take a specific task and complete it. The task comes off the queue when the PR gets merged.
💡 "The idea of a single loop that just goes and completes all the tasks doesn't really match with how developer teams generally work. I think an idea of a queue where you're picking tasks off is better."

David offers a metaphor: a medieval king managing a kingdom. You don't deploy a minister to a region and never hear from them (that's a loop). You have people bringing problems to you (that's a queue), and you prioritize: "We have 50 bug reports — only three are critical. Let's fix those first."

10 Human-in-the-Loop Checkpoints

▶ 49:00

Matt describes an ideal automated pipeline: telemetry catches a bug → an issue is auto-created → an agent explores it → returns structured data (fixable immediately or needs human?) → implements the fix → opens a PR → the human sees the bug report, the exploration, the fix, and a review request. "It's one button click away instead of a whole debugging session."

On removing human review checkpoints, Matt argues you gain two things from review:

  1. Safety gate — preventing dangerous changes from reaching production
  2. System insight — watching the agent work tells you about the health of your system and harness

You shouldn't lose the second one. Even if 20 small fixes get auto-merged per day, you need observability into patterns — maybe through a summary report of common bug patterns rather than reviewing each individual PR.

Video Walkthroughs for PRs

Matt highlights an emerging practice: on any front-end change, the AI records a video of itself walking through the code change, overlays text-to-speech narration, and attaches the video to the PR. "That sort of richness is something that we should be building into everything we do."

11 Building a Business in the AI Age

▶ 54:00

David asks about building businesses in the AI era — is SaaS dead? Matt's characteristically pragmatic answer: "I don't think much has changed about it, to be honest."

  • You still need to talk to customers, figure out what they need, and build prototypes that solve their actual problems
  • AI gives you a massive leg up in implementation speed, but it doesn't help with the core challenge of finding the right problem to solve
  • All classic product design books still apply
  • You should own the product vision — AI is notoriously bad at original, out-of-the-box ideas
💡 "You should be asking AI what thing you can remove from your app. How do I make this simpler? How do I improve the UX? How do I focus in on what people want?"

12 DX vs AX — Developer Experience vs Agent Experience

▶ 56:15

Matt introduces a new concept: AX (Agent Experience) — the experience an agent has working in a codebase. He argues there's huge overlap between good DX (Developer Experience) and good AX, but they come at the problem from different angles:

  • Seniors excel at DX — they know how to build codebases that work well with humans. This translates to good AX because many of the same principles apply.
  • AI-native juniors approach from AX-first — they know the tools, the best models, the best skills for each situation, but may lack the software fundamentals.

Both profiles are valuable. Enthusiasm beats pure experience in output, and juniors who are excited about AI develop much faster. The ideal is pairing AI fluency with software fundamentals.

Matt is blunt about tactical-only developers: "If you're just a tactical programmer plumbing away doing your work, you're gone. You can't be a code monkey anymore. You need to think strategically."

13 Start from a Blank Slate — Actionable Advice

▶ 1:00:49

David's closing question: one or two action steps for the average AI enthusiast to improve today. Matt's answer is surprising — delete everything and start over:

  1. Delete every skill, plugin, and MCP server. Delete your CLAUDE.md, delete your AGENTS.md. Go back to absolutely nothing.
  2. Observe the agent in its blank state. See what it actually does without all the noise. In Matt's experience, "everyone bloats up their context window with too much stuff."
  3. Layer things back deliberately — add only procedure skills (not abilities) that you yourself invoke. Start with Matt's skills repo.
  4. Only bring back what you genuinely miss. If you really miss brainstorming from Superpowers, bring it back. If you miss a specific capability, add it. But make sure each addition earns its place.
  5. Delegate implementation to AFK agents — this is the biggest workflow unlock. It takes setup, but once running, "it just goes crazy."
💡 "Go back to a blank slate and see what the agent does. Layer things on top of it and make sure those things are procedures — procedure skills, not ability skills."

🎯 Key Takeaways

🔑 Key Takeaways

  1. Strategic over tactical — AI has eaten tactical programming. Your value is now in strategic thinking: codebase architecture, module interfaces, task scoping, and team velocity.
  2. Your skills are AI's ceiling — seniors get 10x from AI while juniors get a small boost. The difference is domain expertise that guides and evaluates AI output.
  3. Harness over model (50/50) — stop obsessing over model releases. Invest equally in prompts, skills, codebase quality, and development environment. A well-architected codebase lets cheaper models do the same work.
  4. Procedures over abilities — keep the human in the driver's seat. Use skills you invoke yourself (grill-me, prd, teach) rather than skills the model invokes autonomously.
  5. Stateful skills unlock personalized AI — the teach skill demonstrates how saving state locally (mission, learning record, progress) enables AI to build genuinely personalized experiences over time.
  6. Sand Castle for safe parallelization — running agents in sandboxes (Docker/Podman) enables worry-free AFK development. Combine with GitHub Actions for fully automated issue → PR pipelines.
  7. Think in queues, not loops — development is a queue of tasks with multiple nodes processing it. Infinite loops are wasteful; event-driven task processing is how real teams work.
  8. Push human checkpoints to the right — build pipelines that bring you the bug report + exploration + fix + review request, so review is one click instead of a debugging session.
  9. Build loops for systemic improvement — when AI finds a security bug, don't just fix it. Ask why it existed and build systems (cron jobs, automated reviews) to prevent the class of issue.
  10. DX ≈ AX — developer experience and agent experience heavily overlap. A codebase that's easy for humans to work in is usually easy for agents too.
  11. Fundamentals are model-agnostic — good testing, clean architecture, proper documentation, and modular design will compound across every future model release.
  12. Start from a blank slate — delete all your skills, plugins, and MCP servers. Observe the bare agent, then layer back only what you genuinely need as procedure skills.

🔗 Resources & Links

  • Matt Pocock's Skills Repo — the teach skill, grill-me, PRD, and other agent skills. Install via npx skills@latest add matt-skills
  • aihero.dev — Matt's newsletter and hub for agentic engineering content
  • aihero.dev/skills — dedicated skills documentation and updates

Timestamp Index

▶ 0:00 Opening — harness vs model thesis
▶ 0:42 Strategic vs tactical programming
▶ 2:40 Skills as the ceiling for AI
▶ 4:47 Sponsor segment (SerpApi)
▶ 6:00 The teach skill — background
▶ 7:06 Live demo: teach skill in action
▶ 9:10 Stateful vs stateless skills
▶ 13:00 Opus 4.8 vs Fable — model choice
▶ 17:00 Skills repo on GitHub
▶ 17:24 Procedures vs abilities distinction
▶ 18:18 The grill-me skill
▶ 19:16 Superpowers vs Matt's approach
▶ 21:00 Context window bloat from abilities
▶ 23:50 Knowledge, skills, wisdom framework
▶ 24:50 Matt's agentic setup revealed
▶ 26:26 Sand Castle + GitHub Actions demo
▶ 27:45 Formula 1 analogy — harness vs engine
▶ 29:08 The Bitter Lesson and AI coding
▶ 32:00 Token optimization via better code
▶ 33:00 Vibe coders vs fundamentals approach
▶ 35:00 David's Fable + browser use story
▶ 39:00 Building cron jobs for security review
▶ 42:00 Fix the system, not just the bug
▶ 43:00 Agentic loops — viral Twitter debate
▶ 45:00 Ralph loop origins (Jeffrey Huntley)
▶ 47:00 Medieval king / queue metaphor
▶ 49:00 Ideal automated bug pipeline
▶ 53:20 AI video walkthroughs for PRs
▶ 54:00 Building businesses in the AI age
▶ 56:15 DX vs AX concept
▶ 59:30 Juniors vs seniors in AI age
▶ 1:00:49 Action steps: start from blank slate
▶ 1:02:05 Where to find Matt (aihero.dev)