explainx / blog
Matt Pocock's full AI coding workshop covers practical engineering workflows: smart zone vs dumb zone, grill-me alignment, PRD-to-vertical-slices, TDD with AI, AFK agents, Sand Castle parallelization, and production code review.
Jun 7, 2026
Y Combinator's Paxel scans Claude Code, Codex CLI, and Cursor transcripts to create builder reports with archetypes, prompt stats, and work patterns.
Jun 7, 2026
Discover 185+ AI coding plugins from OpenAI and Anthropic on explainx.ai.
Jun 7, 2026
OpenAI's official plugins repository features curated Codex plugin examples for Figma design workflows, Notion integration, iOS/macOS app development, web deployment, and MCP server connections.
separate branches using tools like Sand Castle while developers focus on high-value planning and architecture.
On April 24, 2026, TypeScript educator and AI coding pioneer Matt Pocock released a comprehensive 2-hour workshop titled "AI Coding for Real Engineers" that fundamentally challenges the notion that AI makes software engineering fundamentals obsolete.
While many treat AI coding as a paradigm shift that renders 20 years of software engineering wisdom irrelevant, Pocock makes the opposite argument: engineering fundamentals matter more than ever when working with AI agents. The workshop demonstrates that code quality, architecture decisions, TDD discipline, and design patterns become critical leverage points that determine whether AI agents amplify your capabilities or multiply technical debt.
This article provides a comprehensive breakdown of the workshop's core concepts, practical workflows, and production-ready patterns for integrating AI agents into professional software development.
| Topic | Key insight |
|---|---|
| Workshop focus | Complete AI-assisted development lifecycle from ambiguous requirements to autonomous agent deployment |
| Core thesis | Software engineering fundamentals are not obsolete—they're the leverage layer that makes AI agents useful |
| Smart vs dumb zone | LLMs degrade beyond ~100k tokens (40% context); keep work in the smart zone through task decomposition |
| Grill-me skill | Force agents to ask 40-80 alignment questions before coding to reach shared understanding |
| PRD workflow | Synthesize conversations into structured PRDs, then decompose into vertical-slice GitHub issues |
| Tracer bullets | Build thin vertical slices through all layers (schema/API/UI/tests), not horizontal layers |
| TDD with AI | Write failing tests first, let agents implement to green, review and refactor |
| AFK agents | Classify issues as HITL (human decision) or AFK (autonomous implementation) |
| Sand Castle | TypeScript framework for parallelizing sandboxed agents with worktrees and Docker isolation |
| Code review | Use Sonnet for speed, Opus for review quality, always in fresh context |
| Deep modules | Favor high-leverage interfaces that hide complexity over shallow modules that leak it |
The dominant narrative in 2026 is that AI coding assistants represent a paradigm shift so profound that traditional software engineering practices—design patterns, TDD, architecture reviews, code review processes—are suddenly obsolete boomer baggage.
Matt Pocock's workshop opens by rejecting this framing entirely.
His counter-thesis: AI agents are powerful, but they're only as good as the engineering constraints, workflows, and quality standards you give them. If you feed an agent vague requirements, skip tests, ignore architecture, and treat code as disposable, the agent will amplify those bad habits at machine speed.
The workshop demonstrates the opposite approach: treating AI as a force multiplier for disciplined engineering. When you combine strong fundamentals with agent capabilities, you get compound leverage. When you abandon fundamentals, you get compound dysfunction.
This is why Pocock built Claude Code for Real Engineers, a 2-week cohort teaching AI coding from first principles, and open-sourced his skills repository (135,000+ GitHub stars as of June 2026) containing agent skills that encode professional engineering workflows—now at v1.0.1 with progressive disclosure. See our full skills guide and v1.0 breakdown.
One of the workshop's most actionable insights is the concept of the smart zone and dumb zone in LLM context windows.
At approximately 100,000 tokens—or roughly 40% of the total context window—LLMs begin entering what Pocock calls the "dumb zone" where reasoning quality degrades sharply. The exact boundary varies by model and task complexity, but everyone working with long-context models has observed this cliff.
The cause is quadratic attention scaling: as context grows, the computational cost of attending to all tokens increases exponentially, leading to quality degradation even when the model technically has capacity for more tokens.
Most developers instinctively believe: more context = better results. Just paste the entire codebase, all previous conversations, every GitHub issue, and let the model figure it out.
Pocock's data shows the opposite: bloated context actively harms output quality. Once you cross into the dumb zone, the agent starts missing critical details, hallucinating solutions that contradict earlier context, and producing generic code that ignores project-specific constraints.
The workshop emphasizes a multi-phase decomposition approach:
| Phase | Goal | Context size |
|---|---|---|
| Alignment | Understand requirements deeply through grill-me questioning | Minimal: just the initial request |
| Planning | Produce PRD and break into vertical slices | Medium: PRD + architecture docs |
| Implementation | Each agent works on one isolated issue | Small: issue description + relevant code only |
| Review | Fresh context evaluation of changes | Clean: just the diff + quality standards |
By keeping each phase within the smart zone, you maintain reasoning quality throughout the development lifecycle.
This is not theoretical optimization. Pocock demonstrates real examples where the same task produces dramatically different results depending on whether context is kept lean or allowed to bloat.
The second major pattern from the workshop is what Pocock calls the "grill-me" skill—an alignment phase that happens before any code is written.
The default workflow with AI agents is:
This is expensive, demoralizing, and creates an adversarial relationship with the tool.
The grill-me skill flips this dynamic. Instead of letting the agent immediately implement, you force it to interrogate you first:
Before writing any code, ask me at least 40 questions to ensure you
fully understand the requirements, edge cases, architecture constraints,
performance requirements, testing strategy, and integration points.
Do not stop asking questions until you can articulate the complete
solution back to me and I confirm we have shared understanding.
Pocock's examples show agents asking 40 to 80 targeted questions covering:
This process produces what Pocock calls a shared design concept: you and the agent are genuinely on the same wavelength about what's being built.
Investing 10-15 minutes in alignment questions prevents hours of wasted autonomous work. More importantly, it surfaces misunderstandings, missing requirements, and architectural conflicts before they become code problems.
Pocock documents this pattern in his grill-me skill along with common mistakes teams make when using it.
Once alignment is complete, the workshop demonstrates converting that shared understanding into a Product Requirements Document (PRD) that becomes the source of truth.
Pocock's to-prd skill synthesizes conversations and grill-me sessions into structured PRDs that typically include:
| PRD section | Purpose |
|---|---|
| Problem statement | What user/business need are we solving? |
| Proposed solution | High-level approach and architecture |
| Success criteria | Measurable outcomes that indicate done |
| User stories | Specific scenarios and use cases |
| Technical constraints | Performance, security, compatibility requirements |
| Out of scope | Explicitly document what we're NOT building |
| Dependencies | Other systems, teams, or features this requires |
| Testing strategy | How will we validate this works? |
| Rollout plan | Feature flags, gradual rollout, rollback strategy |
A PRD serves as the destination document that agents can reference throughout implementation. When an agent gets confused or needs to make a design decision, it can return to the PRD for authoritative guidance.
This prevents scope creep, ensures consistency across multiple agents working in parallel, and provides a clear definition of "done" that isn't subject to interpretation.
Pocock's workflow has the PRD automatically filed as a GitHub issue. This creates:
This is not bureaucracy—it's infrastructure that makes parallel autonomous work possible.
With a PRD in place, the next phase is decomposition. This is where Pocock's approach diverges sharply from typical project planning.
The default instinct is to break work into horizontal layers:
This creates long-running branches, late integration, and makes it impossible to validate whether the feature works until everything is done.
Instead, Pocock advocates tracer bullets—thin vertical slices that cut through every layer to deliver a complete, working feature:
Issue 1: User can create a basic todo
- Schema: Add `todos` table with id, text, completed, user_id
- API: POST /todos endpoint with validation
- UI: Simple form to create todo
- Tests: End-to-end test covering create flow
Issue 2: User can mark todo as complete
- Schema: Use existing completed field
- API: PATCH /todos/:id endpoint
- UI: Checkbox component
- Tests: End-to-end test covering complete flow
Issue 3: User can delete todo
- Schema: No changes needed
- API: DELETE /todos/:id endpoint
- UI: Delete button with confirmation
- Tests: End-to-end test covering delete flow
Each issue is independently shippable. Each can be picked up by a different agent. Each can be tested and validated immediately.
Pocock's to-issues skill takes a PRD and automatically decomposes it into vertical-slice GitHub issues with:
This decomposition is not busywork—it's the infrastructure that enables parallelization.
One of the workshop's most controversial claims is that Test-Driven Development (TDD) becomes more important with AI, not less.
The common argument: "AI can write both code and tests together, why slow down with TDD?"
Pocock's response: because AI agents are optimizers. Give them a vague problem and they'll produce code that superficially works but doesn't actually solve your requirements. Give them a failing test and they'll produce code that provably solves the problem you specified.
1. Red: Human writes a failing test describing desired behavior
2. Green: Agent writes minimum code to make test pass
3. Refactor: Agent or human cleans up implementation
4. Repeat: Move to next test
The key insight: tests are specifications that agents can verify against. When you write the test first, you're forcing yourself to think clearly about:
Instead of:
"Build a function that validates email addresses"
Write a failing test:
describe('validateEmail', () => {
it('accepts valid emails', () => {
expect(validateEmail('[email protected]')).toBe(true);
});
it('rejects emails without @', () => {
expect(validateEmail('userexample.com')).toBe(false);
});
it('rejects emails without domain', () => {
expect(validateEmail('user@')).toBe(false);
});
it('accepts emails with subdomains', () => {
expect(validateEmail('[email protected]')).toBe(true);
});
});
Then tell the agent: "Make these tests pass."
The agent now has an unambiguous success criterion. No guessing about requirements. No debating whether the implementation is "correct." The tests define correct.
When you send an agent off to work AFK (away from keyboard), you can't supervise every decision. But you can give it a test suite that defines acceptable behavior.
Pocock shows examples where:
This is specification-driven autonomous work. The tests are your quality enforcement layer when you're not watching.
The workshop spends significant time on software architecture principles, particularly the concept of deep modules from John Ousterhout's A Philosophy of Software Design.
| Deep modules | Shallow modules |
|---|---|
| Small, simple interface | Complex, intricate interface |
| Hide significant complexity | Expose implementation details |
| High leverage: lots of functionality behind minimal API | Low leverage: interface nearly as complex as implementation |
Example: fs.readFile(path) hides buffering, streaming, error handling | Example: new XMLHttpRequest() with 12 setup methods before use |
Pocock argues that AI agents write better code when working with deep modules, because:
Conversely, shallow modules force agents to hold more implementation details in context, increasing the chance of crossing into the dumb zone.
When reviewing agent-generated code, Pocock recommends asking:
The workshop includes his improve-codebase-architecture skill that agents can use to identify shallow modules and propose deeper alternatives.
One of the workshop's most production-ready patterns is the AFK (away from keyboard) classification for autonomous agent work.
When decomposing PRDs into issues, each issue gets classified:
| Classification | Meaning | Example |
|---|---|---|
| HITL | Human in the loop: requires judgment, architecture decisions, or business tradeoffs | "Should we cache this data or recompute on every request?" |
| AFK | Away from keyboard: well-defined implementation with clear acceptance criteria | "Add validation to email field per PRD specification" |
Issues are AFK-ready when they have:
Pocock demonstrates a real example where 3 agents work in parallel on separate vertical slices, implementing and testing autonomously while he's in meetings.
Critically, AFK does not mean "let the agent do whatever it wants." It means:
The autonomous part is the mechanical implementation of well-specified work. The judgment, design, and quality standards remain human responsibilities.
To operationalize AFK workflows at production scale, Pocock built Sand Castle, a TypeScript framework for orchestrating sandboxed coding agents.
Running multiple agents in parallel on the same codebase creates:
import { run } from 'sandcastle';
await run({
issue: 'Add user profile endpoint',
branch: 'feature/user-profile',
worktree: true, // Isolate in git worktree
docker: true, // Sandboxed execution
timeout: 30 * 60 * 1000, // 30 minute max
});
For each agent, Sand Castle:
Sand Castle coordinates:
| Agent type | Responsibility |
|---|---|
| Planner | Examines full backlog, identifies non-blocked AFK issues, determines parallelization opportunities |
| Implementation | Works on single issue in isolated environment, writes code, runs tests, commits when green |
| Reviewer | Reviews implementation agent output against quality standards, fresh context |
| Merger | Integrates approved changes, resolves conflicts if needed, validates integration tests |
The workshop emphasizes Sand Castle is not a "set it and forget it" solution. Production use requires:
Pocock shows real examples where Sand Castle enables 3-5x faster feature delivery for well-specified work, while acknowledging it's inappropriate for exploratory or high-judgment tasks.
The workshop dedicates substantial time to code review as a quality gate for agent-generated code.
The default approach many teams adopt:
This treats code review as a formality rather than a quality enforcement mechanism.
| Review aspect | Approach | Tool |
|---|---|---|
| Implementation | Use Sonnet for speed and cost | Claude Sonnet 4.5 |
| Review | Use Opus for quality and judgment | Claude Opus 4.5 |
| Context | Reviewer always works in fresh context, not implementation thread | New conversation |
| Standards | Explicit quality checklist provided to reviewer | Documented criteria |
| Focus | List issues first, not praise | Critical evaluation |
By using Sonnet for the mechanical implementation work and Opus for critical review, you optimize for both velocity and quality.
This is critical: the reviewer should not have access to the implementation conversation history.
Why? Because seeing the implementation context creates anchoring bias. The reviewer starts evaluating whether the agent solved the problem it thought it was solving, rather than whether the solution is objectively correct.
Fresh context forces the reviewer to evaluate:
Pocock shows examples where reviewer agents:
Poor review: "This looks good, I don't see any issues."
Good review: "This implementation has three problems: 1) Missing null check on line 47 could throw in production. 2) No rate limiting on the endpoint. 3) Error messages leak internal implementation details. Recommend fixing before merge."
A brief but powerful pattern from the workshop is what the community calls the "ralph loop"—popularized by Pocock's demonstrations of bash-driven agent automation.
while true; do
claude-code --file prompt.md
if [ $? -eq 0 ]; then
git add .
git commit -m "Agent work completed"
else
echo "Agent failed, stopping loop"
break
fi
sleep 5
done
The prompt.md file tells the agent:
The loop enables continuous autonomous work without human intervention. The agent:
This is the operational pattern behind Pocock's demonstrations of "I started 3 agents before lunch and they shipped 8 features by end of day."
Good use cases:
Bad use cases:
The ralph loop is a production pattern for mechanical work, not a replacement for thoughtful engineering.
The workshop culminates in a complete walkthrough demonstrating all concepts together:
/grill-me skill/to-prd to generate structured PRD/prd-to-issues to decompose into vertical slicesFor each AFK issue:
Developer focuses on HITL issues requiring architectural decisions.
This retrospective feedback becomes the input for improving skills, specifications, and workflows for the next feature.
| Skill | Purpose |
|---|---|
| /grill-me | Force alignment through deep questioning |
| /to-prd | Convert conversations into structured PRD |
| /prd-to-issues | Decompose PRD into vertical-slice issues |
| /tdd | Guide test-driven development workflow |
| /improve-codebase-architecture | Identify shallow modules and suggest deep alternatives |
The workshop ultimately argues these traditional engineering skills become more important, not less, when working with AI:
AI agents are terrible at operating with ambiguous requirements. The better you can articulate constraints, edge cases, and success criteria, the more useful the agent becomes.
Skill to develop: Practice writing precise acceptance criteria and failing tests that capture requirements unambiguously.
Agents implement solutions within the architecture you provide. They won't spontaneously refactor to a better design pattern or question a flawed system boundary.
Skill to develop: Study design patterns, system design, and module boundaries. Make architectural decisions deliberately before delegating implementation.
Tests define "correct" for autonomous agents. Poor tests mean agents optimize for passing bad tests rather than solving real problems.
Skill to develop: Master TDD, property-based testing, integration testing, and test design. Learn to write tests that actually validate desired behavior.
Agent-generated code requires scrutiny for security, performance, edge cases, and alignment with project standards. Rubber-stamping merges creates technical debt at machine speed.
Skill to develop: Systematic code review, security awareness, performance analysis, and architectural consistency checking.
Keeping work in the smart zone requires breaking complex problems into smaller, well-scoped phases. This is the core skill that enables effective agent work.
Skill to develop: Practice vertical slicing, tracer bullet development, and incremental delivery. Learn to see the smallest complete slice that delivers value.
The workshop identifies several anti-patterns:
Mistake: "The AI will figure out the architecture."
Reality: Agents implement within constraints you provide. Architecture is your job.
Mistake: Immediately start coding from vague requirements.
Reality: 15 minutes of grill-me saves hours of rework.
Mistake: Pasting entire codebase, all conversation history, every GitHub issue into context.
Reality: Bloated context degrades reasoning quality. Stay lean.
Mistake: "The agent can write tests later."
Reality: Tests are the specification that makes autonomous work possible. Write them first.
Mistake: Merging agent PRs without review.
Reality: Agents produce plausible-looking code that may be wrong, insecure, or inefficient.
Mistake: Treating all work as AFK-able.
Reality: Judgment-heavy decisions require human involvement. Only mechanical implementation should be delegated to autonomous agents.
The workshop explicitly targets professional software engineers who:
This is not a workshop for:
The target audience is experienced engineers who want to 10x their leverage while maintaining production quality standards.
The deepest insight from the workshop is this: AI agents amplify whatever system you give them.
If your system has:
But if your system has:
AI does not fix broken engineering processes. It accelerates whatever process you have—for better or worse.
Pocock's workshop is fundamentally about building systems worthy of amplification.
For engineers who want to go deeper, Matt Pocock offers Claude Code for Real Engineers, a 2-week cohort covering:
The cohort is designed for working engineers who want production-ready skills, not toy demos.
The concepts in this workshop connect to broader patterns in the AI agent ecosystem:
Matt Pocock's "AI Coding for Real Engineers" workshop makes a definitive argument: software engineering fundamentals are not obsolete in the age of AI—they're the leverage layer that determines whether AI agents amplify your capabilities or multiply your problems.
The workshop provides practical, production-ready patterns for:
These are not theoretical concepts. They're workflows that professional engineering teams are using in production to ship features 3-5x faster while maintaining quality standards.
The key insight: your job as an engineer is not to write every line of code yourself. It's to design systems, define specifications, encode quality standards, and maintain architectural integrity—then delegate mechanical implementation to agents that work within those constraints.
Master those skills, and AI becomes genuine leverage. Skip them, and AI becomes a chaos multiplier.
Workshop note: This comprehensive breakdown is based on Matt Pocock's "AI Coding for Real Engineers" full workshop video released April 24, 2026, plus analysis of his open-source skills repository, Sand Castle framework, community discussions, and related educational content from AI Hero. For latest updates, skill releases, and cohort information, visit aihero.dev and the mattpocock/skills GitHub repository.