A finished live-stream conversation between Matt Pocock and Robert C. "Uncle Bob" Martin, author of Clean Code. The subject: what a 50-year veteran of software craft actually changed in his practice once coding agents arrived, and what he refused to change.
What this video is about
The job changed from writing code to caging the thing that writes it. Agents are fast but leave a mess and, like humans, they thrash and eventually give up once code gets messy enough. Uncle Bob's goal now is to not look at the code at all, and instead build a scaffold of automated checks around it so the agent physically cannot ship a mess. (09:23)
Old, "impractical" quality techniques are now affordable because agents are cheap labor. The CRAP score (complexity vs coverage) and mutation testing were good ideas in 2000 that cost too much human time. Agents run them tirelessly, so they become routine build steps. (05:43)
Stop steering with prose; enforce with deterministic tools. Long rule documents (the Clean Code book stuffed into a prompt) get treated as "guidelines" because of "lost in the middle": the middle of a big context window loses attention. Trim the prompt to its minimum, then enforce quality with checkers that run after the agent writes. (13:28)
His pipeline is a gauntlet of single-purpose agents: specifier → coder → cleaner → hardener → QA. It turns a 5-minute single-agent job into an hour, but that hour still beats a human's half-day and produces higher quality than a human would. (17:44)
Impose human VALUES on agents, not human DISCIPLINES. Don't force test-driven development on an agent (it's a workaround for human short-term memory), but do keep the value it protects (test coverage), adjusting thresholds because agents tolerate more complexity than people. (33:10)
Heavy up-front planning fails the same way waterfall did. The cost of change has collapsed toward zero, so the agile move wins: do a story or two, look at the architecture, correct, repeat. Specs are ephemeral now; "the end result IS the specification." (37:42)
Fundamentals endure because they organize complexity into a form that can be conceived, by humans and by the models that were trained on humans. Those who think fundamentals no longer matter "will learn that the hard way, and it won't take very long." (53:15)
---
1. Who Uncle Bob is, and the December that changed his mind (00:00–05:43)
Bob has programmed for over half a century: first program in 1964 at age 12 (a three-bit finite state machine built by placing white tubes on pegs), a real job at 18, and never stopped. He wrote several books; one, Clean Code, "seemed to take off" and is the software-engineering book most often quoted back at Matt. (02:50)
The turn came around December of the prior year. Bob had been unimpressed by ChatGPT and Grok, then got his first agent (an early Grok), asked it to write code, and it "did a poor job but it wrote the code." Working with it on a live project, he found himself constantly cleaning up after it, and coined his running metaphor: the agent leaves "dog do" behind. His first read: interesting because it's fast, frustrating because it makes me slow. Then the reframe that drives the whole talk: because it's fast, it can do things I cannot. (04:22)
2. Old ideas, finally affordable: CRAP and mutation testing (05:43–09:39)
Two early-2000s techniques had caught Bob's eye and then been shelved as impractical:
The CRAP score (Change Risk Anti-Patterns). Run test coverage over your code, measure each function's cyclomatic complexity, and combine them into one number that scores how "crappy" a function is. Back in 2000 he ran it over a big project, found the crappy functions, then spent forever fixing them by hand. Interesting, unaffordable. (05:58)
Mutation testing. A program walks your source and flips operators (negative↔positive, <↔>, =↔≠), and for each flip runs your whole test suite expecting it to fail, because the meaning changed. A flip that does not break any test is a "surviving mutant" that must be killed (it proves a gap in the tests). In 2000 Bob had to run this overnight, several hundred runs against a four-minute suite. It found real gaps, and it was impractical. (06:21)
The January insightagents are fast, don't care how boring the work is, and do what they're told. So have the agent run CRAP over everything it just wrote and clean up its own mess; have it run mutation testing (30 minutes instead of an overnight run) and plug every hole. The techniques didn't get better; the labor to run them got free. (07:52)
His resulting principleset the agents working, have them run these tools, and work hard to reach a state where he doesn't have to read the code at all. He verifies indirectly instead: watch the CRAP scores stay low, spot-check occasionally, run a battery of other tests. "They are fast with code. I am slow with code. So I'm going to let them have the code and deal with the stuff around it." (09:23)
3. Why messy code still matters, even for fast agents (09:39–12:08)
Matt pushesif agents are so fast, why care about clean code at all, why not just push through until the bugs vanish?
Bob's answer is empirical. Early on he watched a small Grok agent leave mess, then build on the mess, then build on more mess, and slow down: it would change one thing and inadvertently break another, fix that and break a third, and start going in circles. His conclusion: agents are as subject to messy code as humans are, maybe at a higher threshold, but the threshold is still there. Past it, the agent "just starts to spin and make the mess even worse." He has literally had one give up: paraphrasing, "I just can't deal with this anymore." (10:37)
So clean code is not aesthetics; it's what keeps the agent inside the zone where it can still function. Dirty code degrades the agent the same way it degrades a person.
4. Steering vs deterministic checks: lost in the middle (12:08–15:58)
Most people, hitting the mess, respond by steering: pouring instructions into CLAUDE.md/agents.md, adding a rule every time they see something bad, until they have a five-to-ten-page document. Bob started there too (here's TDD, here's clean code, here are all the rules) and could have "fed the whole Clean Code book into it." (12:08)
What he observedmodels treat those rules "in the Pirates of the Caribbean sense, they're more like guidelines." (Matt: the same metaphor came to him independently.) The technical reason is "lost in the middle": as the context window fills, the beginning and end keep prominence while the middle loses attention. Anything long you put at the start gets shoved into the middle; maybe the first three sentences survive as priority, but sentence 50 and sentence 80 are gone. (13:28)
Matt's framing for the same effect: the smart zone vs dumb zone of the context window (a term he credits to Dex Horthy). The first stretch (Matt says ~150k tokens) is smart; past it, the transformer's attention relationships get strained and diluted, "like everyone's shouting in a crowded room and the room's getting more crowded." (15:32)
The takeaway is the spine of Bob's method: deterministic tools don't disappear into the middle. So trim the initial prompt to its absolute minimum (to get as much of it as possible into the priority region), and do the deterministic checks after the fact. (14:02)
5. How much checking is too much? Loops and the productivity margin (15:58–17:44)
Because checks don't consume context the way steering instructions do, you can layer them (strong types, tests, more tools) far higher. Is there a ceiling? Bob: obviously yes, eventually you slow the agents below human speed and "you've lost the game." But as long as you keep the productivity margin above a human, you're ahead, and he's been getting a factor of two-to-four even while slowing the agents "a lot." (15:58)
A deterministic tool is really a loop: change the code until this tool says it's okay. The agent circles (add tests, cut cyclomatic complexity, split functions) until it conforms. You are spending productivity for quality; somewhere that trade gives way, but he hasn't found the end point yet. (16:13)
Bob is now wiring multiple single-purpose agents that hand off to each other. Two advantages: they can run in parallel (his laptop handles far more than three), and focusing each agent on one task keeps its context window small, so "lost in the middle" bites less and you can pile a few more rules at the top. You can also make agents that are born, do one task, and die, so the next starts with a clean context. The cost is startup overhead: 10-15 seconds each, plus re-deriving context. (19:15)
The pipeline, in order:
Specifier. Takes a human-written document and produces two things: a Gherkin file (given/when/then, a high-level acceptance test) and a QA procedure (a system test written from a human's point of view: "you are a human operating this system at the UI; you must prove it works"). (20:32)
Coder. Writes the unit tests and the code that implements the story, and gets the Gherkin passing. (21:21)
Cleaner. Runs CRAP analysis and general code review, cleaning up "whatever mess the implementer made, because the implementer will have made a horrible mess by that point."
Hardener. Runs the mutation testing, "absolutely merciless," pushing to 100% coverage, killing every surviving mutant. This one takes a good long time.
QA agent. Turns the written QA document into an executable script that drives the system and yields a deterministic pass/fail. (21:21)
Get through all of that and "you've got a pretty working program." The economics: a task a single agent does in ~5 minutes "with questionable results" takes this gauntlet about an hour, but a person would take half a day, so it's a 4-5x productivity gain at much higher quality. And it's an investment: you spend productivity early to gain it later in your own codebase. (22:33)
Matt's cross-check: he's been skeptical of "I fired my whole workforce, now I have 100 agents with their own email accounts" theater, but he makes an exception for implementer + reviewer, which works like red-green-refactor: the implementer just makes it work (writes the bad test, makes it pass, doesn't make it beautiful), then the reviewer comes in already holding the diff, so it doesn't have to re-explore, and you can load moresteering into the less-constrained reviewer task. (17:44)
7. Context trajectory: the coffee-and-soap-opera effect (23:00–24:09)
Matt names a related ideaa context window has a trajectory. Steer the agent one way and everything downstream in that same session follows: tell it "test the UI here" once and it keeps testing the UI on every later change, no matter what. The only way to clear a trajectory is to clear the context window. That's another argument for the born/do/die single-task agents: the implementer's loose trajectory ("just get it working") shouldn't leak into the hardener's harsh one ("100% coverage or nothing"). (23:00)
Bob confirms it with the effect he's seen even with non-programmers: you're having a nice conversation with a model about brewing coffee, someone walks by talking about a soap opera, that leaks into the context, and "from that point on all the coffee references have to do with the soap opera." The model can't tell who put what in the context. Keep the direction unconfused and everything consistent, and you avoid the crazy hallucinations people usually blame on the model. (24:09)
8. Module architecture, a dependency checker, and deep modules (24:09–31:40)
Matt raises the piece the automated checks don't cover: if your APIs and module boundaries are badly shaped, none of the coverage and mutation testing saves you. How much does Bob think about internal structure?
Until the last month or so, manually, but using the agents to do it: he'd have the agents build something, then interrogate them ("what's the structure here, what are the modules, how do they talk?"), "get scared to death because the answers were horribly frightening," design a proper module partition himself, and hand the agent an implementation plan to execute. (26:10)
Two tools he built for this
A self-built architecture viewer. A UML-style diagram of the system's modular structure and dependency directions; click a module to see its sub-modules, click those to pop the actual code on screen. Drill down to any level. (26:10)
A deterministic dependency checker. He defines which module should and should not depend on which, and how dependency should flow, in a tight specification file "the agents cannot violate." A checker runs at the end; on a violation, the agent must fix it, usually by inverting a dependency, inserting an interface, or splitting a module. He's trying (with "not a lot of luck") to automate the design step itself. (27:41)
Why well-designed modules pay off so heavily: it's the same argument as clean vs dirty code. Anything well-partitioned with disciplined interfaces is graspable, humans compartmentalize in their minds and so do the models (maybe at a different threshold). A module with a clear trajectory doesn't confuse the model with unrelated topics; load a module with "every bit of stuff under the sun" and the poor agent wonders what it's even doing in there. (29:11)
Matt brings in John Ousterhout's deep modules: a shallow module has a wide interface hiding little; a deep module has a small interface hiding a lot. Deep modules suit models especially, because they can read the interface without reading the implementation. Bob agrees: models pay attention to interface names and structure, which lets them skip the code beneath (both a danger and an advantage, safe "as long as the code is consistent"), and they read the tests to understand what the system does. (Aside: Clean Code's second edition has a long, fun Bob-vs-Ousterhout debate in the appendix.) (31:01)
9. What to change in the book: thresholds, and disciplines vs values (31:40–35:53)
Would Bob update any advice in the book (say, "keep functions small")? Two answers:
Thresholds. Agents handle different complexity than humans because they have huge, perfectly accurate short-term memory. So Bob widens the allowed function size by adjusting the CRAP threshold: for a human he keeps it below four; for agents he's set it at six and is considering eight. With 100% coverage a CRAP score of six means six tested pathways through the function. He's hunting for the real threshold and it isn't easy to find (and you can't fully trust the agents' own opinion that "six is probably good"). (33:10)
Disciplines vs values. TDD is a human discipline (write one line of test, one line of production code, repeat), wired to how humans work; it makes no sense to force an agent to do it, and even when told to work at high TDD discipline the agents always fall back to the Ousterhout style (write a function, then its test, then the next). Bob lets them. The rule he draws: it's probably a mistake to impose a human discipline on an agent, but not a mistake to impose human values, though the thresholds may need to change. (34:23)
Matt reframes it cleanlyTDD is great precisely because humans have low short-term memory (enough to write the test, enough to make it pass, then go get a coffee). An agent's memory is different, so the discipline is the wrong fit even when the value (coverage) is right.
10. Planning: waterfall's ghost, agile's return, the $1 house (35:53–43:11)
How much planning before the gauntlet? The temptation is to specify, specify, specify, then hand it over. Bob names it as the same temptation that produced waterfall in the 1970s, which the agile revolution answered: heavy up-front planning makes a mess because what comes out never looks like the plan. He's tried it with agents (was trying it "just this week") and it's "always a disaster," always the same failure: the agents run half-cocked because you didn't think of everything and they aren't as wise as you, so you stop, back up, rewrite the plan, restart. (36:10)
So he's turning to the agile approach: let them do a story or two, look at the architecture at the end, get manually involved to sort things out, then a few more stories. He suspects the manual organizing step may never fully disappear. (37:42)
The economic argument is the $1 house: if every change to a house cost exactly one dollar (including the foundation and roof), you wouldn't pay an architect thousands for a perfect one-shot plan; you'd tell the contractor "foundation here, kitchen there... no, move it... move the stairs" and fiddle until it's right. The cost of change has "plummeted to as close to zero as I think we're ever going to get it," so why spend on expensive up-front planning? Just fiddle until it looks right. Matt agrees completely. (40:17)
On spec-driven development specifically, Bob is skeptical ("probably not going to work; my experiments didn't work particularly well"). Agents love writing plans, "gorgeous and beautiful," spelling out every detail, and then they fall apart at the end. Matt's issue is with the label: prompt engineering, a one-line "fix that loading issue in the header" to a colleague, and a formal spec are all "specification" by some reading. Bob's distinguishing question: do you persist your specifications? He does not, they're ephemeral, they change constantly, "there is no equivalent to source code" anymore, because humans wrote source code and now humans aren't the ones writing it. Many people feel that lack and want a human artifact that defines everything up front. (41:40)
11. The end result IS the specification; build your own tools (43:11–44:56)
Bob's recent move: instead of writing a spec that defines what he wants, look at the end result and call that the specification. His tools (CRAP for Clojure/Java/Go, the mutation tester, the agent harness, mostly written by his own agents) embody it. His advice to others: don't download my tools; I wrote them for me. Point your agents at them, have the agents read them, and build your own. That customizes the essence of the tool to your own need. (43:25)
The asymmetry he finds funnysend an agent something and it actually reads it (versus maybe a 20%, generously, hit rate for a human handed a big spec). The flip side: the things agents write, humans don't read. "They're expecting us to read everything they write, and we just don't." (43:25)
12. Tactical vs strategic, and how juniors learn when AI ate the tactical rungs (44:56–52:50)
Ousterhout's other distinction: tactical programming (the sergeant fighting the battle) vs strategic programming (the general directing the war). Agents are very good at tactical, very bad at strategic. So if AI has eaten the tactical rungs people used to climb, how does a newcomer learn strategic? (45:50)
Bob doesn't claim a perfect answer, but here's how he thinks about it:
Write code for a while first (say a year) so you know what the agents are dealing with. (46:58)
Get treated like an agent. A junior joining an agent-heavy company should be handed the same kind of tasks the agents get and subjected to the same deterministic tools, and spend several months "horribly unproductive but learning a hell of a lot." Get through that gauntlet and maybe you can be trusted to run an agent of your own. Matt's gloss: "become a sub-agent of the agent." (46:58)
The assembly-language weekend. Bob's older advice still holds: if you've only ever written Java, "you live in a fantasy world," so spend a weekend writing assembly to see what's really going on. The learning path runs binary → assembly → some C → some Python → agent work with deterministic tools → finally running an agent strategically under supervision. (48:30)
Read the old books. The strategic lessons were learned in the 70s and 80s: Tom DeMarco, Ed Yourdon, The Pragmatic Programmer. Filter out the archaic parts, keep the strategic sense. Then you learn the rest by feeling it. (51:39)
On feedback loopsstrategic programming traditionally had a very long loop (your mistakes surface nine months out, so a dev who quits every six months may never see their own mistakes and never learn). Agents shorten that loop, you get feedback on mistakes sooner. And the skill Bob used to spot trouble in December wasn't reading the dog-do; it was recognizing the thrash, the agent's struggle, "since I have been through that struggle." The novice's problem is not recognizing the struggle. (50:06)
13. Why fundamentals still matter, and the abstraction-ladder parallel (52:50–56:35)
Do software fundamentals still matter, and what to say to those who claim they don't? Bob: fundamentals matter for the reason they always have. Paraphrasing Dijkstra, software is the most complicated thing humans have ever attempted, and the fundamentals are how you organize that complexity into a form that can be conceived, not just by humans but by our models, "since our models are modeled after humans after all." People who think the fundamentals don't matter "will learn, and they'll learn the hard way, and it won't take very long." He's watched agents hit that wall and doesn't want to hit it again. (53:15)
The closing parallelwe've climbed an abstraction ladder, binary → assembly → compiler → and now the model sits above the compiler. At every rung, the people on the step below said the same thing: "this will ruin everything, we won't even have jobs, five-year-olds will write the code." It was never true, and the same fundamentals kept applying for the same reasons. Bob's line: "The rules you throw away are the ones you're going to pick up off the floor in a year, dust off, and remember why you need them." Matt caps it with Plato, who claimed writing would make people stupider; the abstraction complaint is at least that old. ~1,500 people were watching live. (55:00)
---
Tools and resources
Name
What it is
Reference in video
CRAP score (Change Risk Anti-Patterns)
One number combining cyclomatic complexity and test coverage to flag risky functions. Formula CC^2 * (1 - cov)^3 + CC; classic "crappy" threshold 30, but Bob runs 4 (human) / 6-8 (agent).
CRAP formula and origin. Verified: CRAP(m) = CC² × (1 − cov)³ + CC, introduced 2007 by Alberto Savoia and Bob Evans on the Google Testing Blog; the classic "crappy" threshold is 30. Bob's 4/6/8 numbers are his own personal thresholds for this workflow, not the classic cutoff. (Source: multiple CRAP-metric references, Aug 2026.)
"Lost in the middle" is a real, documented phenomenon (Liu et al., 2023, "Lost in the Middle: How Language Models Use Long Contexts"), not just an anecdote. Consistent with the transcript.
Smart zone / dumb zone attribution. Verified: the framing is Dex Horthy's (HumanLayer): a "smart zone" (roughly the first ~100k tokens) vs a "dumb zone" beyond. Matt says ~150k tokens in the video; treat the exact number as approximate. Bob mispronounces the name as "Dex Hardy."
Dijkstra quote. Bob hedges the attribution himself ("I'm going to get this wrong"). The idea that software/programming is among the most complex human endeavors is widely attributed to Dijkstra; the exact wording in the video is a paraphrase.
Plato on writing. The claim that writing weakens memory/makes people worse is from Plato's Phaedrus (the Socrates/Thamus myth); it is Socrates' framing, relayed by Plato, so "Plato says" is loose but directionally right.
Name transcriptions (auto-caption garbling): "John Aster / John Ora / John Alart / John Asterhow" = John Ousterhout; "girkin" = Gherkin; "cyclatic" = cyclomatic; "Dystra" = Dijkstra; "Forran / Cobalt / PL1" = Fortran / COBOL / PL/I; "closure" (as a language) = Clojure.
Glossary
Coding agent: an AI system that reads a task and writes/edits code by calling tools in a loop, rather than only returning text.
CRAP score (Change Risk Anti-Patterns): a single risk number for a function, computed from its cyclomatic complexity and its test coverage; high means complex-and-undertested.
Cyclomatic complexity: a count of the number of independent paths through a function (roughly, one plus the number of branch points); higher means more ways for it to behave.
Code coverage (test coverage): the fraction of code actually executed by the test suite, from 0 to 1.
Mutation testing: a technique that deliberately introduces small changes ("mutations") into the code and checks whether the tests catch them.
Surviving mutant: a deliberately introduced code change that no test caught, proving the tests have a blind spot there.
Gherkin: a structured plain-language format (Given / When / Then) for writing high-level acceptance tests that both people and tools can read.
Acceptance test: a test that checks the system does what a user story asked for, at the level of observable behavior.
QA procedure (system test): a test that drives the whole running system the way a human user would, end to end through its interface.
Unit test: a test that exercises one small piece of code (a function or class) in isolation.
Test-driven development (TDD): a human discipline of writing a failing test first, then the minimum code to pass it, then refactoring, in tiny cycles.
Context window: the span of text (tokens) a model can attend to at once, holding the prompt, the conversation, and everything it has read.
Lost in the middle: the tendency of a model to attend well to the start and end of a long context but poorly to the middle.
Smart zone / dumb zone: an informal name for the same effect, the early context where the model reasons well vs the later context where recall and reasoning degrade.
Steering: shaping an agent's behavior by adding natural-language instructions (rules, style guides) to its prompt or its CLAUDE.md/agents.md.
Deterministic tool / check: a program that gives the same pass/fail answer every time (a linter, a coverage gate, a mutation tester), unlike a model's probabilistic output.
Loop (agent loop): running an agent repeatedly against a check until the check passes ("change the code until this tool says it's okay").
Trajectory (context trajectory): the direction a session has been steered in, which later turns tend to keep following until the context is cleared.
Hallucination: a model output that is fluent but not grounded in the given context or reality.
Module: a self-contained unit of code with a defined boundary and interface, hiding its internals from the rest of the system.
Interface: the small surface (names, signatures, contracts) other code uses to call a module, separate from how the module is implemented inside.
Deep module: a module with a small interface hiding a large, rich implementation (Ousterhout's ideal); a shallow module has a wide interface hiding little.
Dependency inversion: flipping who depends on whom (usually via an interface) so a high-level module doesn't depend directly on a low-level detail.
Waterfall: a sequential process that plans everything up front before building; contrasted with agile.
Agile: an iterative process that builds a little, gets feedback, and adjusts, instead of committing to a full up-front plan.
Spec-driven development: writing formal specifications and having agents implement from them; Bob is skeptical it works well because agents' plans look great and fall apart.
Tactical programming: writing code to get the immediate feature working; agents are strong here.
Strategic programming: shaping architecture and long-term design so the system stays workable; agents are weak here.
Assembly language: a low-level, human-readable form of a CPU's machine instructions, one step above raw binary.
Abstraction layer: a level that hides the details beneath it (binary, then assembly, then the compiler, now the model), letting you work in simpler terms.
Bob runs single-purpose agents in a fixed handoff chain, specifier → coder → cleaner → hardener → QA, each with a narrow context, turning a 5-minute one-shot into a higher-quality hour.
System value
This is a concrete, ordered instantiation of the orchestrate-flow adversarial-gate idea. Anthony's flow already gates with Opus/sonnet/Fable subagents; the gauntlet adds named single-responsibility stages (spec → build → clean → harden → QA) with a clean context per stage, which directly attacks lost-in-the-middle.
Proposed form
a fleet/orchestrate pipeline preset (a "gauntlet" mode) that spawns one born/do/die agent per stage against a shared work item.
Target project
fleet-control (orchestrate-flow).
2
Deterministic quality gates instead of steering prose
Bob argues long rule documents get treated as "guidelines" because the middle of the context loses attention, so he trims the prompt to a minimum and enforces quality with checkers that run after the agent writes.
System value
Anthony's CLAUDE.md is large and his enforcement already leans on hooks. This is the principled version of that instinct: move as many "rules" as possible out of always-loaded prose and into deterministic PostToolUse/Stop hooks and CI gates, keeping the always-on prompt short. It's a lens for a future CLAUDE.md-hygiene / hook-vs-instruction audit.
Proposed form
a review pass that identifies steering rules in CLAUDE.md that could become deterministic hooks/linters, plus a "keep the always-loaded core tiny" principle.
Target project
fleet-control hooks / CLAUDE.md hygiene.
3
CRAP + mutation testing as {agentic} DONE conditions
CRAP score and mutation testing become routine, cheap build steps once an agent runs them; a "hardener" pushes to 100% coverage and kills surviving mutants.
System value
Anthony's {agentic} items need concrete, checkable DONE lines. For code tasks, "CRAP score under N and zero surviving mutants" is a machine-verifiable finish line an unattended fleet run can prove, stronger than "tests pass."
Proposed form
a reusable DONE-line template and a small checker (CRAP + a mutation-testing pass) wired into the agentic verification step for code repos.
Bob defines allowed/forbidden module dependencies in a spec file "the agents cannot violate"; a checker runs at the end and forces a fix (invert a dependency, insert an interface, split a module) on any violation.
System value
This is architecture enforcement that survives lost-in-the-middle because it's a gate, not a rule in the prompt. For Anthony's growing code repos it keeps agent-written modules from drifting into a tangle over many unattended runs.
Proposed form
a per-repo dependency-rules file plus a CI/hook checker that fails the build on a boundary violation.
Target project
code repos (~/Projects).
5
"End result is the specification" tooling philosophy
Bob treats his built artifacts (tools, tests) as the spec and tells people not to download his tools but to point their agents at them and generate their own.
System value
A stance for adopting anything from these playbooks: don't clone another team's skill/tool wholesale, have an agent read it and regenerate a version fitted to Anthony's stack. It also reframes persisted specs as optional; the passing gauntlet is the contract.
Proposed form
advisory principle for how /yt candidates get "routed" (regenerate, don't copy) and how skills are adopted.
Target project
advisory (skill/tool adoption practice).
6
Impose values, not disciplines, on agents (adjust thresholds)
Bob keeps the value (coverage) but drops the human discipline (strict TDD ceremony) for agents, and widens complexity thresholds because agents tolerate more than humans.
System value
A tuning rule for Anthony's agent instructions: audit CLAUDE.md / skill rules for places that impose a human workflow on an agent (do X then Y then Z in this order) versus a checkable outcome, and convert the former to the latter with agent-appropriate thresholds.
Proposed form
a checklist item in the CLAUDE.md-hygiene / agent-facing-writing pass ("is this a human discipline being forced on an agent?").
Save the playbook to read later, or hand the raw notes to your favorite AI.
What's this?
The Markdown file (a .md file) is a plain-text copy of this whole playbook, written in the simple format AI chat tools read best. It keeps the headings, links, timestamps, and captions and drops all the page styling. Think of it as the raw notes behind this page, ready to hand to an assistant.
To use it, download the file and drag it into ChatGPT, Claude, or any AI chat (or just paste the text in), then ask for what you want: “Summarize this into a one-page cheat sheet,” “Turn these steps into a checklist I can follow,” or “Quiz me on the key ideas.” Because the file is already structured, the assistant works from the real content instead of guessing.
