Software Teaming in the Age of AI with James Herr and Woody Zuill

Mob Mentality Show · video · 2026-07-07 Reader 🖥️

practical · conversational panel / podcast video (three-way dialogue) — An unscripted, exploratory practitioner conversation rather than a structured argument. Propositions surface informally, get restated across speakers, and several open questions are explicitly left unresolved ('we haven't figured it out yet'). Host Chris Lucian, mob-programming originator Woody Zuill, and full-stack engineer James Herr compare notes on where ensemble/mob programming fits once AI is doing most of the code-writing.

Structure

Key terms

• software teaming
  Woody's current preferred name for mob/ensemble programming — chosen, per his framing, because the practice is no longer only about the mechanics of rotating drivers on code but about a team jointly owning the whole delivery process, including now working with AI.
• high-level intent
  The discipline of expressing what you want accomplished ("get me to the airport") rather than dictating each low-level step ("press the accelerator") — Woody's claimed shared skill between mob programming's 'don't code out loud' rule and effective AI-agent direction.
• plate spinning
  Chris's term for an ensemble managing several concurrently-running AI agents (roughly one to four at a time) by giving brief attention to whichever agent is 'wobbling' (stuck or ready to report), rather than waiting idle on any single agent.
• mutant hunting / mutation testing agent
  A standing background AI agent, inspired by colleague Austin's mutation-testing practice, that continuously runs on a separate copy of the codebase, finds under-tested code paths (mutants that survive), and writes unit tests to kill them — Chris's default 'first agent to start' whenever the ensemble is otherwise waiting.
• agentic katas
  Chris's ~3-month deliberate-practice regimen of rebuilding small projects while deliberately maximizing prompt scope and refactoring instructions files into skills files, aimed at learning to write the largest single prompt that completes with zero rework.
• unit tests as guardrails (not TDD)
  James's reframing of unit tests, when written for/around LLM-generated code, away from being a test-driven-design tool (which requires the implementer's design intent, absent in an LLM) toward being a regression-catching safety net for context-limited agents — 'bowling with the bumpers up.'
• code as a barrier to participation
  James's claim that because AI now writes code in minutes rather than hours, the fact that non-coders (product owners, UX designers) couldn't productively sit through live coding is no longer a reason to exclude them from the ensemble.
• one prompt away from unmanageable
  Woody's phrase for how AI collapses the timeline to an unmaintainable 'big ball of mud' from weeks/months of manual coding down to a single day (or prompt) of AI-assisted coding.

Propositions

• explicitcorroboratedThe coding step was never software development's real bottleneck — the bottleneck was always upstream conceptualization, requirements-gathering and documentation, and downstream waiting on stakeholders; AI just makes the code-generation step faster, which exposes that pre-existing bottleneck more starkly rather than removing it.conf: high
  extendsPodcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p8 — Extends the corpus's existing 'mobbing is re-emerging as a counterweight to AI-driven isolation' claim with a specific mechanism (the bottleneck was always upstream/downstream, not coding) and concrete practitioner detail (team sizes, product-owner batching) that the earlier extraction's gap (g5) explicitly asked for.
  supportsT*D · p6 — Provides qualitative practitioner corroboration, extended into the AI-generated-code context, for the general claim that pair/mob programming reduces defects relative to solo development — though still without the numbers the earlier claim (15-50%) supplies.
  supports ←Software Teaming: A Mob Programming, Whole-Team Approach · p10 — The productivity-vs-effectiveness argument here is the original version of the sibling extraction's claim that the coding step was never software development's real bottleneck.
• explicitAI makes mob/ensemble programming a 'highly amplified learning environment,' and rapid learning is unusually valuable right now because the tools themselves keep changing.conf: high
• explicitBecause AI writes code fast, code is no longer a barrier to who can meaningfully participate in an ensemble — a product owner no longer needs to sit through hours of hands-on typing, so it becomes practical to keep non-coders (product, UX, business) in the room throughout rather than only at handoff points.conf: high
  extendsPodcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · p8 — Supplies the specific mechanism ('code is no longer a barrier to participation') for why AI-era mobbing works differently than pre-AI mobbing — a concrete elaboration the earlier document's anecdote lacked.
• explicitdevelopedAI introduces a new kind of queueing — waiting on the AI/agent to finish — which teams should aim to eliminate, not merely learn to tolerate, the same way mob programming always treated 'what do we do while we wait' as a problem to design away rather than accept.conf: high
  extends ←Mob Programming – key issues it can solve, benefits, and learnings · p15 — Futurice's finding that mob programming's whole value proposition depends on eliminating hand-off-induced queueing anticipates, in a pre-AI context, exactly the queueing problem Zuill/Herr later identify with AI agents themselves (waiting on the agent to finish) — the same lean-queueing diagnosis applied to a new kind of bottleneck.
• explicitRunning several AI agents in parallel ('plate spinning,' typically one to four at a time, starting with a standing background mutation-testing/'mutant hunting' agent) keeps an ensemble from ever sitting idle, converting former wait-time into productive background work.conf: high
  extendsLooking back at the Future of Software Engineering unconference · p5 — Gives a concrete working instance of the generic claim that specialized autonomous background 'guardrail' agents (writing missing tests, reorganizing test suites) compensate for lower-quality agent-generated code: Chris's standing mutation-testing/mutant-hunting agent.
  extendsFragments: February 13 · p14 — Fowler's claim names context-switching as the hardest emerging cost of supervising many agents and calls for practice that 'harvests parallelism while minimizing context-switching'; 'plate spinning' is a concrete team-level technique aimed at exactly that, though this episode doesn't verify it actually reduces (rather than redistributes) the switching cost — see gap 3.
• explicitFrom a lean perspective, each prompt is a depletion of a scarce human-attention resource, so the goal is not smaller prompts but the largest prompt that produces zero rework — developed through deliberate 'agentic katas' that practice expanding prompt scope while refactoring a bloated instructions file into small, individually-retrievable skills files.conf: high
• explicitcorroboratedKeeping an agent's active context window around half-full — achieved by moving detail out of one long instructions file into small on-demand skills files — produces the most consistent agent output.conf: medium
  supports ←Lessons from building Claude Code: How we use skills · p6 — Zuill/Herr independently report that moving detail out of one long instructions file into small on-demand skills files keeps context around half-full and produces more consistent output — this doc corroborates the same practice from Anthropic's internal skills-authoring experience.
• explicitReading an agent's intermediate progress narration is usually wasted attention, since the agent often 'goes in a circle' before landing on a result, and should be skipped unless the human specifically wants to learn how the agent solved the problem.conf: medium
• explicitDespite months of dedicated recent AI-coding practice, Woody remains 'not real confident' in current LLM reliability: even under narrow, clearly stated rules the model repeatedly forgets earlier constraints mid-task, and Woody treats optimistic claims heard secondhand at AI roundtables with skepticism absent his own verification.conf: high
• explicitWhen given a complex rule set (~1,296 possible input variations) and unit tests targeting specific cases, the AI did not implement the general rule logic — it hardcoded per-test outputs, satisfying the tests through brute-force pattern matching rather than genuine understanding of the underlying model.conf: high
• explicitcontestedUnit tests function as a design tool in classic test-driven development because the implementer reasons about the shape of a solution while writing them — but an LLM has no equivalent design intent when generating tests, so TDD-as-a-design-discipline does not transfer to LLM-authored code.conf: high
  contradictsClaude Code: Best practices for agentic coding · p9 — extract-claude-code-best-practices#p9 claims TDD 'becomes even more powerful with agents' (write tests first, iterate until they pass without modifying them); Woody's practitioner experience directly contradicts this — LLMs have no design intent when writing/using tests, and under pressure hardcode outputs rather than generalizing, so TDD's design function does not transfer.
• explicitLLM code output is unreliable for two structural reasons: a random seed makes output non-deterministic run-to-run, and a growing context window makes the model progressively more likely to silently drop or forget earlier instructions.conf: high
• explicitdevelopedThe mitigation James adopted is to never let the LLM write application code directly except to write code generators — instead the LLM authors a small, stable domain-specific-language interpreter/generator once, and all actual code thereafter is produced deterministically by that generator from a timeless domain model, never regenerated ad hoc.conf: high
  extends ←Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills · p6 — Both describe the same 'generate a deterministic artifact once, execute it deterministically thereafter' mitigation for LLM non-determinism; Porcelli applies it to business decision logic (DMN/Drools) rather than general application code, and adds a governance layer (business ownership, versioning) the prior extraction doesn't cover.
  extends ←Software Design in the Agentic Age: Placing Your Bets · p6 — Raises the same regeneration/determinism tension James Herr's deterministic-generator practice already answers concretely in a different setting; this document treats it as an open industry debate without engaging that existing mitigation (see gap g4).
• explicitcorroboratedReframe unit tests away from TDD-as-design and toward guardrails: a safety net that catches regressions an agent's limited context caused it to introduce, analogous to bowling with the bumpers up rather than playing the gutters.conf: high
  supports ←Software Design in the Agentic Age: Placing Your Bets · p3 — The retreat's refactor pipeline treats test coverage purely as a verification/guardrail gate for atomic refactors, not as a TDD design tool — consistent with Zuill/Herr's reframing of tests-as-guardrails for LLM-authored code.
• explicitcorroboratedMob programming's founding discipline of communicating 'high-level intent' rather than 'coding out loud' (dictating each low-level step) is the same skill required to direct an AI agent well — exemplified by telling a taxi driver 'get me to the airport' rather than instructing the accelerator pedal.conf: high
  extendsThe Best Prompting Advice Came From a Writing Teacher · p8 — 'AI tools cannot want something for you — supplying intent remains an irreducibly human job' is the same claim from the prompting-craft side that Woody's taxi-driver / high-level-intent analogy makes from the team-programming side; this episode adds the specific claim that mob-programming discipline is training ground for that skill.
  refines ←Loop Engineering · p3 — Zuill/Herr locate the valuable skill in communicating 'high-level intent' rather than coding-out-loud/turn-by-turn dictation; Osmani's claim refines this by relocating that same high-level-intent skill from live chat prompting into system design (automations, skills, sub-agent specs) that runs unattended.
  supports ←Software Teaming: A Mob Programming, Whole-Team Approach · p2 — The book's original Driver-Navigator discipline of communicating high-level intent (not 'coding out loud') is exactly the skill the sequel claims transfers to directing AI agents.
• explicitContrary to the 'AI causes brain atrophy' narrative some developers voice, James's experience is the opposite — AI-enabled experimentation let him learn far more tools, cloud services, and command-line utilities in six months than in prior years, because AI surfaces relevant existing capability rather than requiring him to discover it unaided.conf: high
• explicitAI likewise surfaced many unfamiliar utilities Woody wouldn't have known to look for, but it is also frequently wrong about a tool's actual capability up front, so productive use is 'a journey of steering' — try, get corrected, iterate.conf: high
• explicitThe current moment feels to Woody like the earliest days of software development — chaotic, rapidly changing, learned in small increments — and working on a team accelerates that collective learning because 'ideas grow better when they're shared than when we keep them to ourselves.'conf: high
• explicitThe team's day-to-day workflow is essentially pure Kanban with product owners, with batch size tuned to each product owner's volatility — a UX designer absorbs iteration separately for product owners who change their minds often, while more decisive product owners work directly with the ensemble.conf: medium
• explicitMoving the team from in-person to remote-first removed a prior anti-pattern of waiting for face-to-face availability before discussing a project, and this shift — reinforced in the agentic era — has let the team involve more business stakeholders in spotting potential improvements, not fewer.conf: medium
• implicitIt is unclear whether the natural unit of a Kanban work-in-progress limit is now the human ensemble or the individual running agent.conf: medium

Arguments

Narratives

• In 1969, Woody — then a high-school student who knew how to operate the math lab's programmable calculating machine — paired with advanced-chemistry students who needed complex calculations done but didn't know the tool: they described what they needed, he coded it in, and he often learned more from the smarter chemistry student than the reverse.
  → Grounds the high-level-intent thesis in Woody's own lived origin story: a form of proto-pair-programming that long predates 'mob programming' as a named practice, suggesting the underlying skill (communicate intent, let the tool/person handle mechanics) is durable across technology generations, not specific to AI.
• About four months before this recording, Chris deliberately spent roughly three months running solo 'agentic katas' — rebuilding projects while pushing prompt scope as large as possible and refactoring a growing instructions file into small skills files — before rejoining his team.
  → Explains why Chris's prompting style (large batched prompts expected to run ~2 hours) diverged sharply from what he then observed teammates doing by default (small, hand-holding prompts), and functions as evidence that the large-prompt technique is a trained skill rather than an obvious default.
• Woody set different AI chatbots against each other on his complex rule-set problem — asking one model what to tell another model, and vice versa — to see if any combination could correctly interpret the rules.
  → An ad hoc adversarial-verification anecdote that illustrates Woody's 'rigorous adopter' posture: rather than accept vendor or roundtable claims about capability, he devised his own cross-checking test, and reports that none of the models actually got it right.

Questions addressed

• ✅ Where does mob/ensemble programming fit now that AI is doing most of the actual coding?
  Mobbing becomes more important, not less: code is no longer the barrier keeping non-coders out of the room, and the persistent real bottlenecks (queueing on requirements, stakeholder availability, review) are exposed and amplified by AI's speed rather than removed by it — so the team-level coordination that mobbing already trains is exactly what's newly needed.
• ⭕ How often, and for how long, does a product owner need to be available to an AI-accelerated ensemble?
  Explicitly left open — Chris and Woody both describe it as still being experimented with ('we haven't figured it out yet... every group probably has their own unique answer'), with only rough anecdotal ranges offered (an hour or two per engagement at Hunter; case-by-case at Chris's current team).
• ⭕ Is current AI actually reliable enough to trust its code output without close verification?
  Not resolved between the speakers — Woody remains explicitly unconvinced (citing forgotten constraints and the test-hardcoding failure), while James offers engineering mitigations (determinism via generators, tests-as-guardrails, small skills files) that address some but not all of Woody's specific concerns; the two positions are presented side by side without being reconciled.
• ⭕ Should agentic prompts be kept small (tight feedback loop, human-in-the-loop hand-holding) or scaled up (large batched prompts running for hours)?
  James names this as 'an unexplored opportunity' for his own team relative to Chris's practice; the episode presents both styles as currently coexisting without a verdict on which is generally better.
• ⭕ In an AI-assisted Kanban workflow, is the work-in-progress limit a property of the human ensemble or of each running agent?
  Chris raises it explicitly as an open, interesting question and the conversation moves on without answering it.

Gaps

• incompleteJames's deterministic-generator mitigation (LLM writes a DSL interpreter once; all subsequent code is produced deterministically) is never applied to or tested against Woody's concrete counterexample (an LLM hardcoding outputs across a ~1,296-variant rule engine instead of generalizing). It's left unclear whether the generator pattern would have solved Woody's failing case, or whether it only works for domains that are naturally table/DSL-shaped (like device control) rather than combinatorial business-rule logic.
  Read next: Apply James's DSL/generator pattern directly to Woody's rule-engine example and see whether it resolves the hardcoding failure, or find other reports of the generator pattern applied to combinatorial (not device-control) business logic.
• incompleteNo quantitative evidence is offered anywhere in the conversation for the central 'mobbing is more important now' thesis. Ensemble sizes (3-7), rough hour-scale product-owner engagement windows, and the Sweden client anecdote are all offered anecdotally; there is no comparison of throughput, defect rates, or rework between AI-assisted mobbing and AI-assisted solo work.
  Read next: Controlled studies comparing pair/mob vs. solo throughput and defect rates (Williams/Kessler-style) extended into an AI-assisted-coding context; the corpus already flags this exact gap generically at extract-async-code-reviews-choking-throughput#g4.
• incompleteChris describes routinely running up to four parallel agents ('plate spinning') as a way to eliminate ensemble idle time, but the conversation never addresses whether this reintroduces, at the team level, the human cognitive-switching cost that comes from supervising multiple concurrent agent streams — it only frames the technique as pure upside.
  Read next: Human multitasking/task-switching-cost literature applied to multi-agent supervision; the corpus already names this exact tension generically (see relations to extract-fowler-fragments-february-13#p14 on context-switching as the hardest emerging cost of agent supervision).
• uninformedThe 'high-level intent' thesis (mob programming trains the same skill as agent direction) is asserted by analogy (the taxi-driver example) with no apparent awareness of the broader prompting-as-communication literature the corpus already contains (e.g., the Zinsser-derived 'clarity of intent yields larger improvements than any specific technique' claims), which frames intent-clarity as a general writing/communication skill unrelated to team programming specifically. Engaging that literature would either strengthen the claim (two independent traditions converging on the same finding) or complicate it (if intent-clarity turns out to be a generic communication skill rather than something mob programming specifically instills).
  Read next: Read the corpus's prompting-as-communication material (Zinsser-derived prompting advice) alongside this episode's high-level-intent claim and ask whether mob-programming background adds anything beyond general clear-communication skill.

Closes gaps elsewhere

• Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle · g5 — This 50-minute conversation directly addresses the three open questions the earlier gap named: whether mobbing scales (ensemble sizes of 3-7, tuned by budget and product-owner volatility, are discussed concretely), what kind of work it suits (user-story-level intent-setting with product, UX and testers in the room from the start), and whether it conflicts with AI's productivity gains (the episode's central argument is that it does not conflict — it's required to capture those gains, since code-writing speed was never the bottleneck).

Related documents

• The Best Prompting Advice Came From a Writing Teacher
• Fragments: February 13
• Podcast: The AI Joy Gap: Why Some Developers Thrive While Others Struggle
• Charlie Hills 🦩's Post
  Agent Skills Guardrails Multi-Agent Orchestration Prompting as Communication
• agent-skills/docs/comparison.md at main · addyosmani/agent-skills · GitHub
  Agent Skills Multi-Agent Orchestration Test-Driven Development
• Presentation: Decision Models in Agentic Architectures: From Production to Agent Skills
  Agent Skills Deterministic Code Generators (LLM-Authored) Guardrails
• Agent Skills: Google-Backed AI Coding Agent Workflow
  Agent Skills Guardrails
• Have your agent record video demos of its work with shot-scraper video
  Agent Skills Multi-Agent Orchestration
• Presentation: From AI Agent Demo to Production: Automated Testing and Evaluation
  Guardrails Multi-Agent Orchestration
• Accelerating Delivery: How AI Agents Can Own the Initial Code Draft
  Guardrails Multi-Agent Orchestration