[FULL WORKSHOP] AI Coding For Real Engineers - Matt Pocock, AI Hero

AI Engineer (channel); speaker: Matt Pocock (AI Hero) · video · 2026-04-24 source ↗ Reader 🖥️

practical · mixed — Primarily practical (a workshop that teaches a concrete workflow for shipping production code with AI agents), expository in its conceptual sections (smart zone / dumb zone, deep modules, push vs. pull), and narrative in its demos (the gamification feature lifecycle is one long worked example). The thesis is prescriptive: pre-AI software-engineering fundamentals are what make AI coding work in production.

Structure

Key terms

• smart zone / dumb zone Context Rot & Context Limits
  The smart zone is the portion of an LLM's context window (Pocock pins it at roughly 100k tokens regardless of advertised window size) in which attention relationships are not yet strained and the model makes good decisions; the dumb zone is everything beyond, where token-to-token attention scales quadratically and quality collapses. Originally from Dex Horthy (Human Layer).
• Memento agent (LLM as the guy from Memento) Context Rot & Context Limits
  An LLM session always resets to its system prompt; the developer should embrace and exploit this — clear context rather than compact — so every session starts in a known, optimal state. Pocock prefers clearing to compacting.
• specs-to-code (the movement he opposes) Spec-Driven Development
  The view that you author specs, pass them to AI, and only edit the specs when output is wrong — never reading the code. Pocock equates this with 'vibe coding by another name' and rejects it: 'the code is your battleground.'
• grill-me (skill) Spec-Driven Development
  A short skill that instructs the agent to interview the developer relentlessly, one question at a time, walking down each branch of the design tree, providing its own recommended answer with each question, until shared understanding is reached. Operationalises Brooks's 'design concept'.
• design concept (Brooks) Software Design Fundamentals
  Borrowed from Frederick P. Brooks's The Design of Design: the shared idea among all participants in a design effort. Pocock's reinterpretation: what the developer needs to reach with the agent before any plan or code.
• destination document / journey document Spec-Driven Development
  Two complementary planning artifacts. The destination document (the PRD) defines where you're going (problem, solution, user stories, definition of done, out-of-scope). The journey document (the vertical-slice Kanban) defines how to get there.
• PRD (product requirements document) Spec-Driven Development
  A summary of the design concept written by the agent after grilling; contains problem, solution, user stories, implementation decisions, testing decisions, out-of-scope. Pocock explicitly does NOT read it — he trusts LLMs at summarization once alignment has been established.
• tracer bullet / vertical slice Agent Planning Artifacts
  From Pragmatic Programmer: a thin slice of functionality that crosses every layer of the system (e.g., schema change + new service + minimal front-end representation) so you get end-to-end feedback after the first slice instead of after the last layer. Pocock contrasts this with horizontal slicing, which AI defaults to (do all schema, then all API, then all front-end).
• agent-ready issue / independently grabbable issue Agent Planning Artifacts
  A markdown-file issue produced by the PRD-to-issues skill, sized as a vertical slice, with explicit blocking relationships to other issues so the whole backlog forms a DAG that multiple agents can work in parallel.
• AFK (away-from-keyboard) task vs. human-in-the-loop task Human-in-the-Loop
  AFK tasks can be safely handed to an agent that runs autonomously — implementation almost always qualifies. Human-in-the-loop tasks require a human (or several humans, including domain experts) to sit there because the cost of misalignment is too high — alignment/PRD phases qualify. Issues are tagged in the Kanban as AFK or human-in-the-loop.
• day shift / night shift Human-in-the-Loop
  Metaphor for the workflow split: humans do the day shift (idea, grilling, PRD, Kanban) which queues work; agents run the night shift (AFK implementation) consuming the queue.
• Ralph (Wiggum) loop Agentic Loop
  A simple agent loop named after a Simpsons character: specify a destination, then repeatedly tell the agent 'make a small change that gets us closer'. Pocock acknowledges it works but prefers more structure; his once.sh / loop.sh scripts are a structured Ralph loop.
• deep module vs. shallow module (Ousterhout) Software Design Fundamentals
  From John Ousterhout's A Philosophy of Software Design: a deep module exposes a small interface to a lot of functionality; a shallow module is a small file exporting a small surface. Pocock argues unaided AI produces shallow-module codebases, which fragment test boundaries and degrade agent performance.
• feedback loops (as ceiling) Feedback Loops
  Automated tests + type checks + lint + build that an agent can run autonomously after each change. Pocock asserts: 'the quality of your feedback loops influences how good your AI can code. Essentially, that is the ceiling.'
• red-green refactor / TDD with an agent Test-Driven Development
  The agent writes a failing test first, confirms red, implements until green, optionally refactors. Pocock claims this materially reduces test cheating because the test instruments the code before the code exists; the workflow is so valuable he 'warps his whole technique around getting TDD to work better.'
• push vs. pull (for coding standards) Progressive Disclosure
  Push = unconditionally inject tokens into every agent context (e.g., CLAUDE.md). Pull = make information available behind a description header that the agent can choose to load (skills). Pocock's design: implementer pulls, reviewer pushes — the implementer must be free to ignore irrelevant rules, but the reviewer must always compare against the rules.
• sub-agent Multi-Agent Orchestration
  An LLM call delegated to an isolated context window that returns only a summary to the parent. Pocock uses it to spend ~94k tokens on exploration without polluting the orchestrator's smart zone.
• dock rot (doc rot) Technical Debt
  Old PRDs/plans persisting in the repo and being treated as authoritative by future agents even though the code, names, and requirements have drifted. Pocock's answer: don't keep them in the repo; close them as GitHub issues — visible-as-done but retrievable.
• Sandcastle Coding Agents
  Pocock's TypeScript library for orchestrating parallel agent loops: a planner reads the backlog and chooses parallelizable issues; each issue runs in its own git worktree inside a Docker sandbox with its own Claude instance; a reviewer (Opus) reviews the implementer's (Sonnet) work; a merger merges branches and resolves conflicts.
• QA (manual, by the developer)
  Pocock's most opinionated step. After AFK implementation, the developer manually exercises the feature to 'impose my opinions back onto the codebase, how I impose my taste'. Teams that try to automate QA 'end up with apps that lack taste and are bad'. QA is also the place new Kanban issues are generated.

Propositions

• explicitAI is not actually a new paradigm for software engineering; the fundamentals that make working with humans effective also work with AI.conf: high
• explicitLLM attention degrades quadratically with context length; meaningful quality collapses around ~100k tokens regardless of the advertised window size.conf: high
  refinesCharlie Hills 🦩's Post · p4 — Pocock supplies the mechanism behind the long-session tip: attention degrades quadratically with context length, collapsing around ~100k tokens.
• explicitClearing the context every session is preferable to compacting; the LLM behaves like Memento — embrace the reset instead of fighting it.conf: high
  supportsHarness design for long-running application development · p2 — Pocock independently converges on clearing context over compacting, matching Anthropic's finding that fresh-agent resets with handoffs beat compaction.
• explicitcorroboratedMisalignment between developer and agent — not capability — is the primary failure mode in AI coding; alignment is achieved by adversarial dialogue (the grill-me skill), not by writing better plans.conf: high
  refinesAgent Skills: Google-Backed AI Coding Agent Workflow · p6 — Agrees capability is not the bottleneck but relocates the primary failure from agent discipline to developer-agent misalignment, fixed by adversarial dialogue.
  supports ←mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p4 — Reinforces the workshop claim that alignment is achieved by the grill-me adversarial dialogue, not by writing better plans — the fixes protect that alignment step from short-circuiting into implementation.
• explicitcontestedThe 'specs-to-code' approach (edit specs, never look at code) is just vibe coding renamed and does not work; the code is the developer's battleground.conf: high
  contradicts11) AI-spesial med Vilde Opsal og Anders Sveen · p1 — Pocock rejects the code-as-regenerable-artifact framing: specs-to-code is vibe coding renamed, and the code remains the developer's battleground.
  contradictsSam Hatoum's Post · p10 — Pocock insists the code is the developer's battleground and specs-to-code does not work, directly denying Hatoum's claim that the spec-implement-verify cycle can run without human coding intervention.
  contradicts ←Vibe coding and agentic engineering are getting closer than I'd like · p1 — Willison reports productively shipping without reviewing every line, against Pocock's claim that not looking at the code does not work because code is the developer's battleground.
• explicitVertical slices (tracer bullets) are strictly better than horizontal layering for agent work, because end-to-end feedback arrives at the end of slice one instead of slice three.conf: high
• explicitUnaided AI defaults to horizontal slicing and shallow modules; the developer must explicitly direct it otherwise.conf: high
• explicitcorroboratedBad codebases produce bad agents; the quality of automated feedback loops (tests, types, lint) is the ceiling on the agent's output quality.conf: high
  supports ←11 Tips For AI Coding With Ralph Wiggum · p6 — Same author, same claim in compressed form: the quality of automated feedback loops (tests, types, lint) is the ceiling on the agent's output, and bad codebases produce bad agents ('agents amplify what they see'). Tip 5 restates the workshop's ceiling principle as a non-negotiable loop requirement.
• explicitImplementation can become an AFK task; alignment cannot — it requires human (and sometimes multiple human) presence and benefits from no parallelization.conf: high
  refinesSkill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI · p4 — Narrows the full-autonomy prescription: implementation can be AFK, but alignment requires human presence and resists parallelization.
• explicitDeep modules (Ousterhout) make codebases easy for agents to navigate AND let humans retain a mental model of the codebase while delegating implementation behind module interfaces.conf: high
• explicitReviewing a session's own implementation inside the same context window forces the review to happen in the dumb zone; clear the context first so the reviewer works in the smart zone.conf: high
• explicitPush (CLAUDE.md) and pull (skills) serve different roles: implementers should pull coding standards (so they aren't drowned in irrelevant rules); reviewers should be pushed coding standards (so they always compare).conf: high
• explicitTDD with an agent (red-green-refactor) materially reduces test cheating because the test instruments the behaviour before the implementation exists; without TDD, agents tend to write tests that conform to the implementation after the fact.conf: high
  supportsThe Future Of Software Engineering · p2 — Independent confirmation that TDD prevents agents from writing tests that conform to broken implementations after the fact.
  refinesHarness engineering for coding agent users · p9 — Offers a condition under which AI-generated tests become trustworthy for behavioural verification: TDD ordering instruments behaviour before implementation exists.
  supportsPresentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · p8 — Same mechanism independently observed: without test-first discipline the LLM fits tests to the implementation instead of to intended behaviour.
• explicitcorroboratedDevelopers are now doing more code review than ever; there is no clean way to reconcile small-PR discipline with parallel AFK loops — accept the increased review burden.conf: high
  supportsGenie Lessons: Nobody Wants Agents · p2 — Pocock, though pro-agents, concedes parallel AFK loops irreducibly increase the human review burden — confirming Beck's coordination-burden-shifts-to-user claim from the other camp.
  supports ←With Android CLI, Google is Making the Android Toolchain Agent-Friendly · p8 — Independently locates the new binding cost in verification and review of agent output rather than generation speed.
• explicitcorroboratedManual QA by the developer is non-negotiable; it is where developer taste is imposed back onto the codebase and where new Kanban issues are generated; teams that automate QA produce 'slop'.conf: high
  supports ←You can't unit test for taste · p11 — Pocock: manual developer QA is where taste is imposed and automating it produces slop. Tryggvason's resolution is exactly 'manual overrides,' spot-checking and reverting hallucinations by hand.
• explicitDevelopers should own their planning stack rather than adopt off-the-shelf frameworks (SpecKit, OpenSpec, TaskMaster); without ownership, when the stack fails you have no observability.conf: high
• explicitcorroboratedPRDs and plans should NOT be kept in the repo long-term; doc rot will make them poison subsequent agent sessions. Close them in an issue tracker as a visual record without keeping the prose in-tree.conf: high
  supports ←mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p5 — Mapping the plan to GitHub issues (Tickets stage of the lifecycle) aligns with the workshop's stance that plans should live in an issue tracker as a visual record rather than rotting in-repo.
• explicitThe PRD itself does not need to be reviewed by the developer once alignment was reached during grilling, because LLMs are reliable summarizers of an already-shared design concept.conf: high
• explicitcorroboratedThe 1M-token context window does not extend the smart zone; vendors shipped 'more dumb zone'. Use long contexts for retrieval, not for coding.conf: high
  supports ←No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer · p5 — Both sources make the same claim in the same vocabulary (smart zone / dumb zone) that larger raw context windows do not expand the usable 'smart' portion — they just add more dumb zone.
• explicitcorroboratedPre-AI software-engineering literature (Pragmatic Programmer, Ousterhout, Brooks, Fowler's Refactoring) is the highest-leverage reading material for AI-coding practice; the workflows verbalize what those books already said.conf: high
  supports ←SWLW #701: Gazing at the misty AI Frontier, From Vibe Coding to Agentic Engineering, and more. · p3 — Both claim reading foundational pre-AI books remains the highest-leverage advantage precisely when agents can execute the tasks.
• explicitFrontend work resists AFK agents because frontend is multimodal in a way agents are not yet good at; use AI for throwaway prototypes that humans choose between, then feed the chosen prototype back into the grilling pipeline.conf: medium
• explicitWorking with AI in 2026 means working harder than before, AND losing your mental model of the codebase faster than before; the architectural prescription (deep modules with interfaces you design yourself) is the proposed defence.conf: high
• explicitdevelopedParallelization of agent work requires a DAG of independently grabbable issues plus orchestrator/merger machinery; a single sequential plan caps you at one agent.conf: high
  extends ←mattpocock/skills v1.1: does /wayfinder beat grill-with-docs? · p2 — Same author. /wayfinder is the concrete tool operationalizing the workshop's principle that parallel agent work requires a DAG of independently grabbable issues plus orchestrator/merger machinery, and that a single sequential plan caps you at one agent.
• implicitPair programming with an AI present (developer + domain expert + agent) is a genuinely productive setup because the agent is a third party that relentlessly probes the shared assumptions.conf: high
• implicitcorroboratedSandboxing each agent in its own git worktree inside Docker is the safe way to run multiple AFK agents in parallel.conf: high
  supports ←11 Tips For AI Coding With Ralph Wiggum · p11 — Tip 9's Docker sandbox (mount only the project directory) is the single-agent form of the workshop's containment prescription — sandbox each agent in its own git worktree inside Docker — as the safe way to run unsupervised AFK loops.
• explicitAsymmetric model assignment is rational: cheaper/faster model for implementation, stronger model for review (Pocock: Sonnet for implement, Opus for review).conf: high
  refinesCharlie Hills 🦩's Post · p5 — Agrees on asymmetric model allocation but assigns the strong model to review rather than planning, with the cheap model implementing.
  extendsCharlie Hills 🦩's Post · p5 — Pocock generalizes Hills's Opus-plans/Sonnet-builds heuristic into a principle: assign the stronger model wherever judgment concentrates, including review.
• implicitestablishedWithout human eyes, AI-built products lack taste; taste cannot be automated.conf: high
  supports ←How Anthropic Builds And How Engineering Will Change Soon | Thariq Shihipar · p19 — Both claim taste/human judgment is what makes AI-generated output actually good, and cannot itself be automated away.
  supports ←You can't unit test for taste · p1 — Pocock: 'taste cannot be automated.' Tryggvason gives the same claim a precise mechanism — there is no ground truth, hence no red/green test — arriving at it from a data pipeline rather than a coding workflow.
• explicitOptimizing the PRD beyond the alignment-with-AI point yields little value; the journey document is 'just a hint'; the place to spend effort is QA.conf: high

Arguments

Narratives

• Sarah Chen's Slack brief about gamification on the Cadence course platform — used end-to-end as the worked example from idea → grill-me → PRD → Kanban → AFK implementation → TDD → QA → migration error → fix.
  → Shows that even a vague stakeholder ask can be ground through the lifecycle; carries the implicit claim that this workflow handles real product briefs, not just toy problems.
• The video-editor module in mattpocock/coursevideo-manager: Pocock wrapped a browser-based video editor front-end-through-back-end inside a single deep module using a discriminated-union approach, making the whole flow testable from the outside.
  → Implicitly demonstrates that deep modules + outside-in tests = night-and-day difference in AI coding even on 'brutal' domains; this is his strongest single recommendation ('if you take one thing away from today').
• Pocock's own work repository (mattpocock/coursevideo-manager) with 744 closed issues, recording 1000+ videos.
  → Implicitly: this workflow is dogfooded at scale by one developer on a real product; the volume is the proof.
• Claude Code course launched with a 200k window on the same day Claude announced 1M; Pocock's reaction was that they 'shipped a lot more dumb zone'.
  → Carries the claim that bigger context windows are vendor-driven and don't actually expand the smart zone for coding.
• Demo of a Ralph loop crashing because the issues were created on GitHub instead of locally, with Pocock telling the agent 'you fool' and re-prompting it.
  → Implicit demonstration that the workflow tolerates and recovers from agent error in real time — the human-in-the-loop demos are themselves an argument for staying close enough to course-correct.
• Sandcastle, the TypeScript library Pocock built 'in maybe a week or so' to orchestrate parallel agent loops (planner + per-issue sandboxed implementer + reviewer + merger).
  → Implicit claim: the production-grade version of this workflow requires bespoke orchestration tooling; off-the-shelf solutions weren't satisfactory.
• Dex Horthy / Human Layer credited for the smart-zone/dumb-zone framing.
  → Locates Pocock's mental model in a broader practitioner community; honest attribution.
• Pocock dismissing Claude's built-in ask-user-question UI as 'broken' and saying 'I'm using Claude, but I don't like Claude very much. You're really free with this method to choose any system you like.'
  → Implicit: the workflow is harness-agnostic; the prescriptions hold across Claude Code, Cursor, etc.

Questions addressed

• ✅ How do you stop your agent sliding into the dumb zone?
  Track tokens visibly (status line); clear instead of compact; use sub-agents for exploration; size tasks via vertical slices.
• ✅ How do you reach alignment with an agent before generating any plan?
  Adversarial dialogue via the grill-me skill, optionally seeded with a meeting transcript from a domain expert.
• ✅ How do you split a feature into work an agent can do AFK?
  PRD as destination document; vertical-slice Kanban as journey document; each issue tagged AFK or human-in-the-loop with explicit blocking relationships.
• ✅ How do you parallelize agents safely?
  Independently grabbable issues forming a DAG; per-issue git worktrees in Docker sandboxes (Sandcastle); planner + implementer + reviewer + merger roles.
• ✅ How do you enforce coding standards on an agent?
  Pull standards in the implementer (skills); push standards into the reviewer (always-loaded).
• ✅ How do you stop AI from writing bad tests?
  TDD with red-green-refactor as the inner loop; the test instruments behaviour before the implementation exists.
• ✅ What do you do about a bad codebase?
  Refactor toward deep modules (Ousterhout); use the improve-codebase-architecture skill to find candidate consolidations; design module interfaces yourself and delegate implementation.
• ✅ Should you keep PRDs and plans in the repo?
  No — dock rot. Close them as issues to retain a visual record without polluting future agent context.
• ⭕ How do you reconcile parallel agent loops with small-PR review discipline?
  Pocock explicitly admits he doesn't know: 'I don't honestly know what the answer to this yet... I do think it's probably the way things are going.'
• ⭕ How do you make this work for a team rather than a solo developer?
  Pocock's answer is essentially: the upstream phases (idea → PRD) become team-shared assets argued over with RFCs; downstream the workflow is one or two developers managing the pipeline. He does not address onboarding, role design, review queues, or shared infrastructure.
• ⭕ How do you conform to existing architecture, API contracts, and security constraints?
  Pocock defers ('I'm going to answer that in a bit') and never fully returns; the answer is implicitly absorbed into 'push reviewer / pull implementer' standards, but no concrete demonstration is given for security or compliance constraints.
• ✅ How do you handle frontend work?
  Use the AI for throwaway parallel prototypes (three variants in a disposable route), let humans pick, feed the chosen prototype back into the grilling pipeline.
• ✅ How do you avoid losing your mental model of the codebase under aggressive delegation?
  Design the module interfaces yourself; treat modules as gray boxes whose behaviour-under-interface you know and whose implementation you delegate.

Gaps

• incompleteProject-shape selection bias is severe and unstated. Every demo is a greenfield TypeScript app (Cadence, coursevideo-manager) with mature tests, types, deep modules, and a tractable domain. The workflow is implicitly defined against this shape. There is no discussion of legacy Java/.NET monoliths, embedded systems, ML/data-engineering pipelines, infrastructure-as-code, mobile, or anything without a fast type/test/lint feedback loop. Pocock's own claim that 'feedback loops are the ceiling' implies the workflow is bounded to projects already capable of providing that ceiling.
  Read next: Read Cloudflare's Mythos production-AI-coding writeup for an opposing data point on what 'production' actually looks like at scale; read Anthropic's harness paper for the planner/generator/evaluator decomposition Pocock implicitly enacts but does not theorize; for legacy/non-TypeScript shapes, Beck's 'characterization tests' and Feathers's Working Effectively with Legacy Code address how to manufacture the feedback loops Pocock assumes exist.
  closed byDoorDash Used Copilot to Convert Its XCTest-Based iOS Test Suite to Swift Testing — Provides a non-TypeScript, mobile (iOS/Swift) data point: DoorDash manufactured the missing fast feedback loop via strict reliability gates (ten consecutive passes, Bazel integration) to make agent-driven migration work at scale.
• incompleteCost is never discussed at production scale. A single sub-agent exploration burns ~94k tokens (on Opus). A Ralph loop runs continuously. Sandcastle parallelizes implementers across N sandboxes plus an Opus reviewer per issue. The implicit premise that 'tokens are pretty cheap, and AI is actually really good at reviewing stuff' is stated once and not defended at organizational scale. There is no discussion of unit economics, when this workflow becomes uneconomical, or how to budget at team-level adoption.
  Read next: Cloudflare Mythos production data; Anthropic harness paper cost analysis; any team-level postmortem on agent costs (smallcode failure-mode catalog touches on this).
  closed byUber's Zero Growth Stack: Scaling Services, While Optimising Infrastructure and AI Cost — That gap flagged the absence of any production-scale unit-economics or team-budgeting discussion for AI coding workflows. Uber's article supplies exactly this: a real production case where AI-coding costs grew sixfold, per-developer spend hit $2,000/month, and the organisation responded with a $1,500/developer cap plus new granular ROI metrics (net code quality ratio, compute efficiency per feature) — i.e. concrete unit economics and team-level budgeting in practice.
• incompleteTeam adoption is treated as an exercise for the reader. Pocock's answer to 'how does this work in a team?' is essentially: 'the upstream becomes team-shared, the downstream is one or two devs managing the pipeline.' He gives no story for: review queue scaling, distribution of PRD-authoring authority, who owns skills/coding-standards as a shared asset, code-review burden as a team-wide labour question, or how juniors learn craft in a workflow where most code is agent-written.
  Read next: Cutler on overload and accountability culture; Beck on socio-technical change; Fearless Change for the adoption-of-practices angle in the user's hidden-layer interests.
• incompleteThe 'pre-AI books' recommendation is the closing thesis but is left underspecified. Pocock cites Pragmatic Programmer (tracer bullets), Ousterhout's Philosophy of Software Design (deep modules), Brooks's Design of Design (design concept), Fowler's Refactoring (small steps) — but does not give a reading list, nor a mapping of which insight from which book deploys at which point in the workflow. This is the load-bearing connection to the user's craft tradition and is left as a 'go buy them on Amazon.'
  Read next: The user's library already covers Beck (small steps, TCR, simple design), Hickey (Simple Made Easy), Yourdon & Constantine (Structured Design), Meadows (Thinking in Systems). The mapping work is for the orchestrator to do: e.g., Pocock's 'don't bite off more than you can chew' is Fowler-on-refactoring; deep modules is Ousterhout; tracer bullets is Hunt & Thomas; design concept is Brooks. The honest gap is that Pocock does not even mention Beck — surprising given Beck's TCR is operationally close to red-green-refactor as Pocock practices it.
• incompletePocock's workflow structurally mirrors Anthropic's harness paper (planner / generator / evaluator) and Böckeler's adaptive-control framing, but he does not name them or compare. The grill-me skill is alignment; the PRD-to-Kanban is planning; the AFK Ralph loop is generation; TDD + manual QA + reviewer-Opus is evaluation. Surfacing this overlap is essential to placing his workshop in the broader 2026 AI-coding discourse.
  Read next: Anthropic harness paper, Böckeler on adaptive control, Addy Osmani on agent patterns (in the user's saves) — all map onto Pocock's lifecycle with different vocabulary.
• incompletePocock conflates two definitions of 'done': (a) feature shipped with QA-imposed taste, and (b) commit produced by the Ralph loop with passing tests. The transitions between (a) and (b) — especially the merge-and-conflict-resolution at the end of multiple parallel sandbox branches — are sketched (the Sandcastle merger agent) but not interrogated for what happens when the merger itself produces semantically broken code. This is exactly where small-PR discipline matters and where he admits he doesn't have the answer.
  Read next: Beck on incremental design and TCR; trunk-based development literature; the smallcode failure-mode catalog if it covers merge-stage failures.
• incompleteThe implicit premise that the developer can read agent output well enough to QA, code-review, and impose taste is enormous. Pocock states 'understanding code deeply is going to make you a much, much better developer and get more out of AI' and 'bad codebases make bad agents' — but does not address the developer who is themselves junior, distracted, or not the original architect. The workflow may be most valuable to seniors and least usable by the engineers who most need leverage.
  Read next: Marcus on code quality (in user's recent saves), Beck on apprenticeship/teaching contexts, Cutler on directly-responsible-individuals and skill distribution.
• uninformedPocock specifically defers the question on conforming to security, architectural, and API-contract constraints ('I'm going to answer that in a bit') and never returns to it. For the user's organizational context (Norwegian senior leader watching governance signals), this is the highest-value question and is left unaddressed.
  Read next: Security-review skill, Schneier on Security, explainable-AI requirements paper in the user's library, organisational adoption studies on AI tooling in regulated industries.

Closes gaps elsewhere

• Presentation: AI-First Software Delivery: Balancing Innovation with Proven Practices · g2 — Pocock addresses the spec-bottleneck question directly: optimizing the PRD beyond the alignment point yields little (p28), specs-to-code without reading code fails (p5), and in-repo spec documents rot and poison later agent sessions (p17).
• Charlie Hills 🦩's Post · g2 — Gives the operational rationale for asymmetric model assignment — cheap/fast model for implementation, strong model for review — clarifying what 'think' vs 'build' means and why the split works.
• Presentation: Engineering at AI Speed: Lessons from the First Agentically Accelerated Software Project · g2 — Directly addresses the unexamined review cost: developers now review more code than ever with no clean reconciliation with small-PR discipline, lose their mental model faster, and deep modules plus fresh-context review are the proposed defences.

Related documents

• Genie Lessons: Nobody Wants Agents
• Skill Issue: Andrej Karpathy on Code Agents, AutoResearch, and the Loopy Era of AI
• 11 Tips For AI Coding With Ralph Wiggum
  Agentic Loop Context Rot & Context Limits Feedback Loops Human-in-the-Loop
• Have your agent record video demos of its work with shot-scraper video
  Agentic Engineering Coding Agents Feedback Loops Human-in-the-Loop
• No Vibes Allowed: Solving Hard Problems in Complex Codebases – Dex Horthy, HumanLayer
  Context Rot & Context Limits Human-in-the-Loop Multi-Agent Orchestration Progressive Disclosure
• It Ain't Broke: Why Software Fundamentals Matter More Than Ever
  Agent Planning Artifacts Feedback Loops Software Design Fundamentals Spec-Driven Development
• New Skills! v1.1 brings /wayfinder, /research, /implement, /to-spec, /to-tickets
  Agent Planning Artifacts Context Rot & Context Limits Human-in-the-Loop Progressive Disclosure
• Agent Harness Engineering
  Agentic Loop Capability Provisioning (right-sizing to the task) Context Rot & Context Limits Multi-Agent Orchestration
• Agentic AI and Code Reviews
  Coding Agents Feedback Loops Multi-Agent Orchestration Spec-Driven Development
• The Anatomy of an Agent Harness
  Agentic Loop Context Rot & Context Limits Feedback Loops Multi-Agent Orchestration