A comprehensive dissection of the Model vs Harness architecture, the death of tactical programming, and why your skills, not the model, are the real ceiling on what AI can achieve. Featuring the full frameworks from the interview that's reshaping how developers think about AI-assisted development.
Matt Pocock, creator of Total TypeScript and the skills repo that has garnered over 130,000 GitHub stars, sat down with David for a 62-minute interview that systematically dismantles the conventional wisdom around AI coding tools. Rather than chasing the latest model release, Pocock argues, developers should be investing in their own skills and their harness infrastructure, because your skills are the ceiling on what AI can do.
The harness is the entire Formula 1 car: chassis, aerodynamics, pit crew, strategy. The model is just the engine. You can't control the engine: Intel, NVIDIA, and OpenAI do. You can control everything else.
AI has eaten tactical programming, it's gone. What remains is strategic programming: winning the war, not the battle. You are now a general managing an infinite fleet of tactical programmers.
Seniors get a 10× boost from AI. Juniors get a small boost. Skills are more important now than ever before because the multiplier is available, but only if you have the skills to multiply.
Knowledge is cognitive. Skills are practiced. Wisdom is contextual, knowing when to apply what you know. Wisdom is almost impossible to obtain without real-world experience in the exact context.
Abilities are invoked by the model and leak descriptions into the context window. Procedures are invoked by you, and their descriptions can be hidden from the AI entirely. Prefer procedures.
Development is a queue, not a loop. AFK (Away From Keyboard) agents parallelize you, suddenly there are two of you, or three, or four, or five. Human-in-the-loop checkpoints push further right over time.
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. Matt Pocock
Pocock opens the interview with a diagnosis of the AI developer ecosystem: a collective obsession with the model, the latest Claude release, the newest GPT variant, the Fable demo that just dropped. But this fixation is misplaced. The model is the engine, and you have no control over the engine. What you can control, and what determines most of your outcomes, is the harness.
The harness is a deliberately broad category. It encompasses every controllable element in the AI development pipeline: the system prompts and custom instructions you give the agent, the skills and tools you equip it with, the codebase architecture it operates within, the sandbox infrastructure that keeps it safe, the token budget you allocate, and the observability systems that tell you how well it's performing.
| Dimension | Model (Engine) | Harness (Formula 1 Car) |
|---|---|---|
| Control | No — Intel, NVIDIA, OpenAI control it | Yes — fully in developer's hands |
| Releases | Unpredictable (Claude → Fable overnight) | Iterative, predictable, CI/CD-friendly |
| Optimization surface | Can't optimize; just consume | Massive: architecture, skills, prompts, sandboxes |
| Leakage risk | Prompt injection, data exfiltration | Controlled via sandboxes and permissions |
| Cost scaling | Per-token cost, provider-dependent | Better harness = cheaper model = lower spend |
| Portability | Vendor lock-in risk | Agent-agnostic design → swap models freely |
| Time horizon | Next release in weeks/months | 30-40 years of proven software fundamentals |
| Where to invest | Keep watching, don't over-index | Invest here. This is your leverage. |
The framing is elegant: 50/50. Half the outcome is the model. Half is the harness. The model half is dictated by forces outside your control, the compute scaling of NVIDIA, the research breakthroughs at Anthropic and OpenAI, the market dynamics between providers. But the harness half? That's yours. And crucially, the harness half multiplies the model half. A better harness makes any model better. A worse harness drags every model down.
People are focused on the wrong thing. They're looking at the big shiny new thing when in fact just focus on the stuff that's been working for 30, 40 years. Matt Pocock
This is Pocock's grounding philosophy: the fundamentals haven't changed. Good software design, clean interfaces, clear module boundaries, thoughtful architecture, these have worked for decades and will continue to work. The only difference now is that good fundamentals don't just benefit human developers. They benefit the AI agents working alongside them. This gives rise to the concept of AX (Agent Experience), how good the codebase is for AI agents, which overlaps significantly with DX (Developer Experience) but has its own distinct considerations.
AI has basically eaten tactical programming. It's gone. AI is just better at doing tactical programming than you are because it can do it for cheaper. Matt Pocock
Drawing from John Ousterhout's landmark book A Philosophy of Software Design, Pocock distinguishes between two modes of programming that have defined the profession for decades. Tactical programming is the day-to-day work: writing syntax, fixing bugs, committing code, running tests, resolving merge conflicts. It's the battle. Strategic programming is the long game: designing architecture, defining interfaces, scoping modules, thinking about system velocity, ensuring the codebase remains easy to change. It's winning the war.
Pocock's claim is stark and absolute: AI has eaten tactical programming. Not "is eating." Not "will eat." Has eaten. It's gone. AI is faster, cheaper, and more reliable at the tactical level than any human developer. And this changes everything about what it means to be a programmer.
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. Matt Pocock
The metaphor is powerful: you are no longer a programmer. You are a general. You command an infinite fleet of tactical programmers. AI agents that can write code, fix bugs, run tests, and ship changes faster than any human. But an infinite fleet of tactical programmers is useless without a general who knows how to deploy it. The general's skills, scoping tasks, defining interfaces, designing architecture, setting quality standards, are the same delegation skills that have always mattered in software engineering. They haven't changed. They're just deployed against a different kind of team.
| Delegation Skill | To Human Juniors | To AI Agents | Key Difference |
|---|---|---|---|
| Task scoping | Write clear tickets with acceptance criteria | Write clear prompts with context and constraints | AI needs more explicit context (context window) |
| Interface design | Define contracts between team members' code | Define contracts between agent-produced modules | AI is faster — interfaces need to be tighter |
| Code review | Line-by-line review for correctness and style | Strategic review: does this fit the architecture? | AI handles tactical review; human focuses on strategy |
| Testing strategy | Require tests, review coverage | AI writes tests; you design WHAT to test | Test design becomes the human's domain |
| Velocity management | Sprint planning, retrospectives | Queue management, checkpoint placement | Continuous, not time-boxed; queue-based, not loop-based |
| Mentorship | Teach juniors patterns and practices | Teach agents through skills, prompts, and procedures | Skills are reusable, deterministic, version-controlled |
| Architecture decisions | Make decisions, explain rationale | Make decisions, encode in harness and architecture | Decisions become system constraints, not just documentation |
The implication for career development is profound. If you've spent your career optimizing for tactical speed, being the fastest code-writer, the best debugger, the most efficient committer, your competitive advantage has been automated away. But if you've invested in strategic thinking, understanding architecture, designing systems, scoping work, managing complexity, your value has multiplied. The tactical programmer becomes a commodity. The strategic programmer becomes a force multiplier.
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. Matt Pocock
This is perhaps the most counterintuitive claim in the entire interview. The narrative around AI tools has been one of democratization, that AI levels the playing field, that it empowers the junior developer to do what only seniors could do before. Pocock's data and experience point in the opposite direction. AI is a multiplier, not an equalizer. And multiplication amplifies differences, not erases them.
| Dimension | Junior Developer + AI | Senior Developer + AI | Delta |
|---|---|---|---|
| Productivity boost | Small boost — "a little boost" | Massive boost — "ridiculous huge boost" | ~10× differential |
| Code review ability | Can't tell if AI output is good or bad | Knows what good looks like; catches issues | Safety gap — risk of merging bad AI code |
| Task scoping | Vague prompts → vague output → frustration | Precise scoping → precise output → velocity | Input quality determines output quality |
| Architecture decisions | AI makes decisions; junior can't evaluate | Human makes decisions; AI implements | Control over direction |
| Context richness | Limited domain knowledge → thin context | Deep domain knowledge → rich context | "So much richer context to work with" |
| Hiring calculus | "It doesn't make sense to hire that many juniors anymore" | Senior + AI replaces multiple senior-equivalent outputs | Market restructuring |
| Learning trajectory | AI as crutch — may slow skill development | AI as lever — accelerates existing capabilities | Enthusiasm can compensate (see §12) |
The mechanism is straightforward: AI agents need context to produce good work. A senior developer provides rich, nuanced context, they know the codebase, the architecture, the tradeoffs, the edge cases, the team dynamics, the production history. The AI "has so much richer context to work with" when guided by a senior. A junior developer, by definition, cannot provide this context. The AI is working in the dark. It produces plausible-looking output that the junior can't effectively evaluate. The result is a small boost at best, and dangerous overconfidence at worst.
But the framework offers hope, too. Skills are learnable. The ceiling can be raised. The fastest way to get more value from AI is not to wait for the next model release, it's to improve your own skills. Learn the domain deeper. Understand the architecture better. Practice strategic programming. The multiplier is available to everyone. The variable is what you have to multiply.
The AI knows general programming patterns. You know your specific domain. The more domain depth you bring, the richer the context you provide to the agent, and the better the agent performs.
AI can write code. It can't (yet) design systems. Your ability to define interfaces, scope modules, and make tradeoff decisions is what turns AI output into coherent software.
AI produces code that looks correct. You need to know when it's actually correct. This judgment, knowing what good looks like, is the irreplaceable human skill in the loop.
Pocock introduces a three-layer model of human competence that maps directly onto the AI-assisted development landscape. The layers are sequential, you cannot skip from Knowledge to Wisdom without passing through Skills, and each layer has a fundamentally different relationship with AI tools.
| Layer | Definition | How You Get It | Can AI Help? | Example (Git) |
|---|---|---|---|---|
| 1. Knowledge | Understanding the thing in your head. "What is that thing like?" | Reading, watching, listening, studying | ✅ Yes — AI can teach knowledge effectively | Knowing what Git is, what version control does, understanding commits and branches conceptually |
| 2. Skills | Having done it many times. Muscle memory. Pattern recognition. | Practice, repetition, deliberate exercise | ⚠️ Partially — AI can guide practice, but you must do the reps | Being able to resolve a merge conflict, rebase cleanly, bisect to find a bug — fluently, without thinking |
| 3. Wisdom | Knowing WHEN to do it. Understanding context, tradeoffs, real-world fit. | Real-world experience in the exact context | ❌ Almost impossible — requires lived experience | Knowing when NOT to use Git (e.g., game assets), when to squash vs preserve history, when the tool is wrong for the job |
Wisdom is almost impossible to obtain without actually having done the thing in the exact context where you need to do it. Matt Pocock
This is the key insight for the AI age. Knowledge and skills can increasingly be bundled into reusable chunks, "skills" in the Pocock sense, which are packaged prompts, teaching modules, and procedural workflows. This is the fascinating outcome of the current era: Knowledge + Skills can be productized. The Teach Skill (see §6) is a working example, an AI teacher that encodes pedagogical principles and trusted resources into a reusable package that anyone can install.
But Wisdom? Wisdom resists productization. If you want to be like someone at Anthropic, if you want the wisdom of a top-tier AI researcher, you can gain their knowledge (read their papers) and their skills (practice their techniques). But to gain their wisdom? "You need to probably go to Anthropic to gain the wisdom." Context is not transferable through a prompt.
The skills repo that Pocock maintains at github.com/mattpocock/skills has accumulated over 130,000 GitHub stars, making it one of the most popular AI-assisted development resources in existence. At its core is a carefully designed architecture that distinguishes between two fundamentally different types of skills: Abilities and Procedures.
| Characteristic | Ability | Procedure |
|---|---|---|
| Invoked by | The model itself — automatically when it deems relevant | The human — explicitly when the developer chooses |
| Description visibility | Leaked into context window (always visible to AI) | Hidden from context window (disable_model_invocation: true) |
| Context cost | Every ability consumes context tokens — 100 abilities = 100 descriptions leaked | Zero context cost when not in use — description is never loaded unless invoked |
| Control model | AI decides when to use it — "delegate my thinking to the model" | Human decides when to use it — "I take the steering wheel" |
| Risk profile | AI may invoke inappropriately; may conflict with other abilities | Only invoked in the right context because human controls invocation |
| Example skills | "Always use React functional components," "Format with Prettier," coding standards | Grill Me (adversarial interviewer), Teach Skill (AI teacher), PRD writer |
| Best for | Persistent, always-on guard rails and conventions | Contextual workflows that need human judgment about when to apply |
| Pocock's preference | Use sparingly — every one costs context | Prefer these — keep knowledge inside the human |
The most popular procedure skill in the repo is Grill Me, a skill that is, remarkably, only 4-5 sentences long. It transforms the AI agent from an assistant into an adversarial interviewer. Before implementing anything, the agent interviews you about your idea. It asks probing questions, surfaces edge cases you haven't considered, challenges your assumptions.
The workflow is deliberate and sequential: Grill Me → Write PRD → Break into issues → Implement. At each step, the human is in control. The human decides when to grill, when to document, when to break down work, when to hand off to implementation. The AI is a tool in the human's hand, not an autonomous actor making decisions on its own.
Instead of the model being in control, you take the steering wheel. You know your skills, you know your abilities. You decide: grill me → write PRD → break into issues → implement. Matt Pocock (paraphrased synthesis)
Matt's newest and arguably most ambitious skill is Teach Skill, an AI-powered teacher that creates personalized, stateful courses on the fly. Unlike a static tutorial or a generic AI explanation, Teach Skill encodes genuine pedagogical principles into its behavior, creating a learning experience that adapts to the learner's current knowledge, goals, and context.
| Phase | What Happens | Pedagogical Principle |
|---|---|---|
| 1. Mission Alignment | "Learning is not getting information into your head but orienting you in the world." Three questions: who are you, what do you want to build, why it matters. | Purpose-driven learning (adult learning theory) |
| 2. Context Capture | Writes mission.md — captures user context, project goals, success criteria, starting knowledge level. | Stateful teaching — "a great teacher remembers" |
| 3. Resource Search | Searches trusted resources — documentation, books, primary sources. Not random web results. | Information quality over quantity |
| 4. Learning Record | Creates a persistent record of what's been learned, what's next, ZPD (Zone of Proximal Development) estimates. | Progressive disclosure + retrieval practice |
| 5. Reference Sheet | Creates a cheat sheet with key commands, concepts, and patterns. | Cognitive offloading — reduce working memory load |
| 6. First Lesson | Creates an HTML lesson rendered in browser (not terminal — "learning stuff in the terminal is just brutal"). Explanation + terminal exercises + quizzes. | Multimedia learning — visual + interactive |
| 7. Active Practice | Terminal exercises with commands to run. Quizzes with short-answer validation (not multiple choice). | Retrieval practice — the testing effect |
| 8. Primary Sources | Sends student to original sources — e.g., ProGit book for Git fundamentals. | Authority and depth — not just AI summaries |
| 9. Iteration | Invites follow-up questions. Adapts based on learner responses and quiz results. | Feedback loops + ZPD adjustment |
The demo in the interview is revealing. A self-described "vibe coder", someone who knows basic CLI commands and can read some code but has no formal training, asks Teach Skill what they should learn next. The skill doesn't just dump information. It aligns on mission first, asks clarifying questions, then generates a personalized Git fundamentals course. The course knows the learner's system has Git installed. It creates exercises specific to their environment. It renders lessons as HTML, not terminal text, because "learning stuff in the terminal is just brutal."
Vygotsky's ZPD is encoded into the skill, it teaches at the edge of what you know, not what you already know (boring) and not what's too far ahead (frustrating). It estimates and continuously adjusts your ZPD.
Not passive reading. Not multiple choice. Short-answer quizzes that force you to retrieve information from memory. The testing effect is one of the most robust findings in cognitive science, and Teach Skill bakes it in.
Teach Skill doesn't just explain Git, it sends you to the ProGit book. It routes learners to primary, authoritative sources rather than generating plausible but potentially incorrect explanations.
The course adapts to the learner's system, goals, and current knowledge. It knows what's installed, what's relevant, and what the learner actually wants to build. Not a generic course, a course for you.
Matt's own use cases demonstrate the breadth: he used Teach Skill to learn how to solve a Rubik's cube from memory. He also asked it "how to become a senior developer", and it produced a "gorgeous curriculum" drawn from trusted resources, structured around the Knowledge → Skills → Wisdom framework, with exercises and checkpoints at each level.
Installation is trivial: npx skills latest add map skills → choose teach skill. Works with Claude Code, Codex, or any agent framework.
The moment I discovered AFK was the moment I really got into AI coding and the moment I was really able to massively increase my output because then instead of me having to sit in the loop, handle all the permissions requests... I've paralyzed myself. Suddenly there are two of me, or three of me, four of me, five of me. Matt Pocock
The Ralph Loop, originally described by Jeffrey Huntley on July 14, 2023, was a simple idea: a while loop that passes a prompt to Claude Code repeatedly. The agent works, checks its work, iterates, loops. It was one of the earliest patterns for autonomous AI coding. But Pocock realized something crucial: development is not a loop. Development is a queue.
| Dimension | Loop Architecture | Queue Architecture |
|---|---|---|
| Mental model | Single agent iterating continuously | Multiple agents picking tasks from a shared queue |
| Real-world analog | One developer working nonstop on everything | A dev team with PMs adding to backlog, devs picking tasks |
| Parallelism | One thing at a time (serial) | Multiple things simultaneously (parallel) |
| Human role | Human-in-the-loop — sitting with the agent, approving each step | AFK (Away From Keyboard) — human queues tasks, checks results later |
| Risk profile | Agent can go rogue on a single task — "infinite loop in a far province" | Each task is bounded; results come back for inspection |
| Feedback mechanism | Continuous — human sees every step in real time | Checkpoint-based — human reviews at defined gates |
| Output scaling | 1× human output (human is bottleneck) | N× human output (2, 3, 4, 5... parallel agents) |
| Example system | Sitting in IDE with Cursor, copiloting every change | Sand Castle — agents in sandboxes, GitHub Actions triggers |
David provides a memorable metaphor: the medieval kingdom. The king delegates ministers to provinces. A minister on an infinite loop in a far province, that's terrifying. That minister could go rogue, start a rebellion, drain the treasury. The king doesn't want loops. The king wants a queue, ministers come back with reports: "upcoming invasion," "famine in this region." The king prioritizes. This is not a loop. This is a queue of reports from delegated agents.
Matt's Sand Castle infrastructure operationalizes the queue architecture:
| Component | What It Does | Why It Matters |
|---|---|---|
| Sandboxes | Runs agents inside Docker/Podman containers | Prevents "randomly delete your home directory" or "exfiltrate environment variables" |
| Remote Sandboxes | Can use Vercel sandboxes for remote agents | Scales beyond local machine; cloud-native execution |
| GitHub Actions Integration | On PR → checkout branch → run review agent → reply on PR | Automated code review without human in the loop |
| Label Triggers | Anyone on the team can add labels to trigger specific agents | Democratized agent invocation — no CLI needed |
| Issues Pipeline | Triage → Explore (AFK) → Implement (AFK) → Review (AFK) → Human Checkpoint → Merge | Full development pipeline with progressive AFK stages |
| Human Checkpoints | Defined gates where human review is required | Push checkpoints further right over time as trust builds |
The Bitter Lesson. Rich Sutton's famous 2019 essay, argues that the biggest lesson from 70 years of AI research is that general methods that leverage computation beat specialized approaches that leverage human knowledge. Every time humans tried to encode domain expertise into AI systems, raw compute eventually washed it away. The lesson is "bitter" because it means human cleverness is a short-term advantage at best.
Pocock acknowledges the Bitter Lesson but offers a crucial refinement that makes it actionable for developers:
I still think there's a lot to be gained by just optimizing the harness and focusing on creating good codebases that the agent can do well in instead of hamstringing the agent before it even gets started. Matt Pocock
The key distinction: harness optimization is not the kind of optimization the Bitter Lesson warns against. Sutton's lesson is about encoding human domain knowledge into model architectures, feature engineering, expert systems, hand-crafted heuristics. Harness optimization is different. It's about creating an environment where general compute can operate efficiently. It's the difference between trying to make the engine smarter (Bitter Lesson territory) and making the road smoother (harness territory).
| Approach | What It Does | Bitter Lesson Status | Pocock's View |
|---|---|---|---|
| Feature engineering | Hand-craft inputs for specific domains | ⚠️ Washed away by compute | Don't do this — let the model learn |
| Expert systems | Encode human rules into AI | ⚠️ Washed away by compute | Don't do this — too brittle |
| Model-specific optimizations | Fine-tune prompts for one model | ⚠️ Fragile across model releases | Stay agent-agnostic — use fundamentals that work everywhere |
| Harness optimization | Better architecture, cleaner interfaces, smarter scoping | ✅ Scales WITH compute, not against it | Invest here. Good harness = cheaper model = same output |
| Codebase quality | Codebase that's easy to make changes in | ✅ Reduces token spend regardless of model | Primary leverage point. "Have a codebase that's easier to make changes in." |
| Guard rails & sandboxes | Docker, permissions, safety boundaries | ✅ Security that scales with any model | Non-negotiable — prevents catastrophic failures |
Pocock's token economics framework is refreshingly simple:
The agent spends fewer tokens navigating the codebase. Clear module boundaries, consistent patterns, well-named files, these aren't just for humans anymore. They reduce token waste for AI agents, which translates directly to cost savings.
Good architecture provides natural guard rails, the agent can't accidentally break module A while working on module B because the interface is well-defined. This reduces token spend on error recovery and debugging.
A well-structured codebase is easier for an agent to explore. It can find what it needs faster, fewer tokens spent searching, reading irrelevant files, following false leads. The codebase becomes a map, not a maze.
"I'm trying to keep my workspace and my harness agent-agnostic as much as possible. If I try to apply good software fundamentals to what I'm doing, if I do stuff that's always worked, then it will probably continue to work in the future."
I'm trying to keep my workspace and my harness agent-agnostic as much as possible. If I try to apply good software fundamentals to what I'm doing, if I do stuff that's always worked, then it will probably continue to work in the future. Matt Pocock
This is Pocock's answer to the model churn problem. New models ship every few months. Capabilities change. Pricing changes. But good software fundamentals, clean interfaces, clear architecture, well-scoped modules, these are invariant. A codebase optimized for human maintainability is also a codebase optimized for AI operability. The investment compounds across model generations.
David shares a remarkable story from the day after Fable's release. The Twitter API console was bugged, couldn't create API keys. He tried different browsers, disabled extensions, cleared caches. Nothing worked. He gave the problem to Cursor powered by Fable. The agent:
But here's where Pocock's strategic mind kicks in. Most developers would think: "Fable fixed it. Great. Ship it." Pocock thinks differently:
What you've actually learned? Sure, you've learned Fable is good. But you've also learned there are security issues in your code. And you should probably have something that runs and checks for more security issues in the future. Matt Pocock
| Developer Mindset | Reaction to Fable Finding a Bug | Outcome |
|---|---|---|
| Average developer | "Fable fixed the bug. Great." | Ships the fix. Same class of bug happens again next week. Fable fixes it again. No systemic improvement. |
| 10× AI builder | "How did this bug get to production? Why wasn't it caught?" | Adds a cron job that runs security review every day on different parts of the repo. Patches the underlying process. Prevents the entire class of bugs. Builds a self-improving system. |
We need to build loops into our... systems that just check... You need to figure out WHY it happened. If someone keeps stealing your bike, maybe buy a lock. Matt Pocock
The "bike lock" metaphor is perfect. When Fable finds a bug, that bug is not just a bug, it's a signal that your harness is missing a safety check. The 10× AI builder doesn't just fix the bug. They ask: "What system should I add so this class of bug never gets through again?" They treat every AI discovery as an opportunity to improve the harness, not just the code. The harness gets smarter. The next bug in this class is caught automatically. The human spends less time firefighting. This is the compound interest of harness optimization.
The ultimate vision Pocock sketches is a self-improving harness, a system where each AI interaction makes the system better at handling future interactions. This is not about the model getting smarter (that's the model provider's job). It's about the harness accumulating improvements over time.
| Maturity Stage | Human Involvement | Example | Checkpoint Position |
|---|---|---|---|
| 1. Full manual | Human does everything | Pre-AI development | 100% human |
| 2. Copilot | Human codes, AI suggests | GitHub Copilot autocomplete | Human writes, AI assists |
| 3. Human-in-the-loop | AI codes, human approves each step | Cursor with agent mode, approving each file change | Human gates every action |
| 4. AFK with checkpoints | AI does bulk work, human reviews at gates | Sand Castle: explore → implement → human review → merge | Human at key decision points |
| 5. Auto-approve for safe changes | Internal refactors, no behavior change → AI auto-approves | Agent refactors module internals, tests pass, auto-merge | Human skips safe changes |
| 6. AI review of AI code | Agent writes; different agent reviews; human spot-checks | Implement agent → Review agent → Human random audit | Human only audits samples |
| 7. Rich review formats | AI produces video walkthrough; human watches at leisure | TTS narration over code walkthrough video on PR | Human reviews asynchronously, richly |
| 8. Self-improving feedback | Bug → auto-issue → auto-explore → auto-fix → human: "review?" | Telemetry catches bug, creates issue, agent fixes, human gets one-click review | Human at final gate only |
| 9. Full autonomy (theoretical) | System self-improves, self-reviews, self-deploys | Closed loop: detect → fix → verify → ship → monitor | Human out of loop entirely (not recommended yet) |
What do you gain from human review? Pocock identifies two distinct benefits:
Preventing dangerous things from reaching production. Security vulnerabilities, data leaks, breaking changes. This is the obvious benefit, and the one that can be partially automated as the harness improves.
"You don't want to lose that second one because we're talking about the harness. You want to improve your harness over time and you want some observability into it." Watching the agent work gives you insight into how to improve the system.
You don't want to lose that second one because we're talking about the harness. You want to improve your harness over time and you want some observability into it. Matt Pocock
The rich review format idea is particularly striking. One team, instead of doing boring PR reviews on 20 autonomous fixes at end of day, records a video of the AI walking through its code changes. The AI calls a text-to-speech API, overlays narration, and produces a video on the PR. "The AI is talking to you while it walks through the code and you just have a video on the PR of the thing working."
Or, instead of PR review, get a custom Teach Skill HTML report at end of day: "Here are the common patterns in the bugs that were fixed today. Here's what you should learn. Here's what the system should improve." Review becomes a learning experience, not a chore.
The SaaS debate in the AI community is polarized. Some argue SaaS is more valuable than ever, just add seats for AI agents, charge per agent, grow revenue linearly with compute. Others argue SaaS is dead: AI agents can build custom solutions on demand, why pay for a SaaS subscription when you can generate exactly what you need?
Pocock's take cuts through the noise with characteristic grounding:
I don't think that much has changed about it. If you're building a business, what you need to do is the fundamental stuff. Go and talk to customers. Figure out what they need. Build prototypes that look like what they need and solve their actual problem. Matt Pocock
I don't think AI gives you any particular advantage there because what you need to do is go out in the real world and have conversations and figure out what it actually is people need. All of the classic product design books will still make sense here. Matt Pocock
| Business Activity | AI Impact | Pocock's Advice |
|---|---|---|
| Customer discovery | Minimal — AI can't talk to customers for you | "Go and talk to customers. Figure out what they need." |
| Problem validation | Minimal — real-world validation requires real-world interaction | Nothing replaces genuine conversations with users |
| Prototype building | Massive — AI can build prototypes in hours, not weeks | Use AI to accelerate the build-test-learn loop |
| Feature prioritization | Some — AI can help analyze user data and feedback | Ask AI: "What can I REMOVE from my app?" |
| UX simplification | Significant — AI can suggest UX improvements and simplifications | "How do I make this simpler? How do I improve the UX?" |
| Scaling infrastructure | Significant — AI handles ops, deployment, monitoring | AFK agents for DevOps — but human for architecture decisions |
| Marketing & sales | Moderate — AI assists with content, analysis | AI is a tool, not a replacement for human connection |
And then the counterintuitive twist:
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 actually focus in on what people want instead of ending up with one of those dreadful VC-funded apps with a thousand features. Matt Pocock
AI's greatest business value isn't in adding features, it's in removing them. The "dreadful VC-funded apps with a thousand features" are a failure mode of feature-driven development, where every stakeholder request becomes a feature, and the product becomes an unusable mess. AI can help you resist this by asking: "What can I remove? What doesn't users actually need? What's bloat?" This is the harness philosophy applied to product: strip it down to essentials, then build on a clean foundation.
Pocock introduces a new distinction that's likely to become standard vocabulary in the AI-assisted development world: DX (Developer Experience) vs AX (Agent Experience).
| Dimension | DX (Developer Experience) | AX (Agent Experience) |
|---|---|---|
| Primary user | Human developers | AI agents (Claude, GPT, Fable, Codex) |
| Key concerns | Readability, navigability, consistency, documentation | Token efficiency, clear interfaces, well-scoped modules, predictable patterns |
| File structure | Intuitive naming, logical grouping | Same — plus flatness helps (fewer directories to traverse) |
| Code patterns | Idiomatic, familiar, well-documented | Consistent, predictable — agents learn from patterns in context |
| Error handling | Clear error messages for humans | Structured error responses that agents can parse and act on |
| Documentation | READMEs, comments, architecture docs | Same — plus structured metadata that agents can ingest efficiently |
| Testing | Clear test names, organized suites | Tests as guard rails — agents use them to validate their own output |
| Overlap | Massive overlap — "Often people forget about improving the codebase for better AX" | |
Often people forget about improving the codebase for better AX. They forget about all the edges you can get with good software fundamentals. Matt Pocock
The massive overlap between DX and AX is the good news. The same principles that make a codebase pleasant for humans, clarity, consistency, good naming, logical structure, clean interfaces, make it work well for agents. The senior developer who knows how to build good DX is already building good AX, whether they realize it or not.
Pocock offers a surprising hiring heuristic that cuts against conventional wisdom:
Drives rapid learning, experimentation, and AI tool adoption. The enthusiastic developer tries new approaches, iterates quickly, and treats AI as a collaborator rather than a threat.
The non-negotiable foundation. Without understanding architecture, interfaces, scope, and quality, enthusiasm burns bright but produces nothing reliable. Fundamentals channel enthusiasm into results.
Enthusiasm + fundamentals + AI tools = unprecedented individual velocity. A single developer with this combination can produce what teams produced before. The economics are transformative.
After 62 minutes of frameworks, philosophy, and architecture, Pocock closes with a single, radical, immediately actionable piece of advice. It's not "install more tools" or "add more skills." It's the opposite:
First thing I would do is I would delete every single skill, every single plugin, every single MCP server. I would go back. Delete your claude.md, delete your agents.md, go back to absolutely nothing, and then observe the agent. See what it does. Matt Pocock
| Step | Action | Rationale |
|---|---|---|
| 1 | Delete everything — skills, plugins, MCP servers, claude.md, agents.md | "Go back to absolutely nothing" — establish a clean baseline |
| 2 | Observe the agent in basic mode | "See what it does" — understand what the bare model is capable of without your modifications |
| 3 | Layer things back on — PROCEDURES, not abilities | Procedures are invoked by you, not the model. They don't leak into context. They keep you in control. |
| 4 | If you genuinely miss something (brainstorming, plan mode, Grill Me), bring it back | Only add what you've verified you need — not what you assume you need |
| 5 | Customize and experiment with what you bring back | Make them yours. Tune them. Iterate. The harness is controllable — exercise that control. |
| 6 | For problems: find solutions yourself, delegate implementation to an AFK agent | "AFK is just an incredible way to work. It just takes a little bit of setup, but once it's set up, it just goes crazy." |
The method is a direct application of the Model vs Harness framework. If the harness is half the outcome, and most people's harnesses are bloated with unnecessary complexity, then the highest-leverage action is to reset the harness to zero and rebuild it intentionally. Not by adding everything that sounds useful. By adding only what proves itself necessary through observation.
All eight frameworks from the interview, cross-referenced by their practical application domains. Use this as a quick reference to understand which frameworks apply to which problems.
| Framework | Architecture | Workflow | Learning | Hiring | Cost |
|---|---|---|---|---|---|
| Model vs Harness | ✅ Core | ✅ Core | — | — | ✅ Core |
| Tactical vs Strategic | ✅ | ✅ | — | ✅ | — |
| Skills as Multiplier | — | ✅ | ✅ | ✅ Core | — |
| Knowledge → Skills → Wisdom | — | — | ✅ Core | — | — |
| Abilities vs Procedures | ✅ | ✅ Core | — | — | ✅ |
| AFK & Queues | ✅ | ✅ Core | — | — | ✅ |
| Token Economics | ✅ Core | — | — | — | ✅ Core |
| DX vs AX | ✅ Core | ✅ | — | ✅ | ✅ |
After 62 minutes of conversation, what emerges is not a collection of scattered tips but a coherent philosophy of AI-assisted development. Let's synthesize the eight frameworks into a unified mental model:
1. Split your world 50/50. The model is the engine, you can't control it. The harness is everything else, you can. Stop obsessing over the model and start investing in the harness. This is the Model vs Harness framework.
2. AI ate tactical programming. The day-to-day work of writing code, fixing bugs, and committing changes is now AI territory. What remains for you is strategic programming, winning the war, not the battle. You are a general commanding an infinite fleet of tactical programmers. This is the Tactical vs Strategic framework, drawn from John Ousterhout.
3. Your skills are the ceiling. AI is a multiplier, not an equalizer. Seniors get a 10× boost; juniors get a small boost. The fastest way to get more from AI is to improve your own skills. This is the Skills as Multiplier framework.
4. Knowledge → Skills → Wisdom. AI can teach knowledge. AI can guide skill practice. But wisdom, knowing WHEN to apply what you know, requires real-world context and lived experience. Wisdom is the irreplaceable human layer. This is the Knowledge-Skills-Wisdom pyramid.
5. Prefer procedures over abilities. Abilities leak into the context window and delegate thinking to the model. Procedures keep you in control, you invoke them when you choose. Grill Me (4-5 sentences) is the poster child: an adversarial interviewer that interrogates your thinking before you implement. This is the Abilities vs Procedures architecture.
6. Development is a queue, not a loop. AFK (Away From Keyboard) agents parallelize you, suddenly there are two of you, or three, or four, or five. Each agent picks tasks from a queue, works autonomously, and returns results for human review at defined checkpoints. Over time, push those checkpoints further right. This is the AFK & Queues framework.
7. Harness optimization is the optimization that scales WITH compute. Rich Sutton's Bitter Lesson says raw compute beats clever tricks. But harness optimization, cleaner architecture, better scoping, clearer interfaces, isn't a clever trick. It's making the road smoother so any engine performs better. Good codebase = cheaper model = same output. This is the Token Economics framework.
8. Build self-improving systems. When AI finds a bug, don't just fix it. Ask: "Why did this happen? What system can I add so it never happens again?" The harness should improve with every interaction. Bug → auto-issue → auto-explore → auto-fix → human review → merge → learn → improve harness. This is the Self-Improving Systems framework.
The unifying thread: Control what you can control. Invest in what compounds. Delete what bloats. Observe what emerges. The harness is yours, make it work.
ARLI membership: the notes from the workshop
One site of yours, measured, with the price for the work in the same document
ARLI, Inc., a Delaware corporation. Questions: hq@arliwork.com.