▶ YouTube Summaries

• YT :: https://www.youtube.com/watch?v=zcLPGC-tvgk
• Original title :: LIVE: Uncle Bob on Software Fundamentals in the Age of AI

Matt Pocock talks live with Robert C. Martin (Uncle Bob), author of Clean Code, about why software fundamentals still matter when coding agents write the code. Bob's approach: instead of steering agents with long instruction files, which they treat as mere guidelines, he wraps them in deterministic tools (CRAP score, mutation testing, dependency-rule checkers) and a pipeline of single-purpose agents, so he does not have to read the code. He rejects up-front spec-driven planning in favour of agile-style small increments, since the cost of change has collapsed, and argues fundamentals remain the way humans and models alike organize complexity.

From human review to deterministic checks

Bob started experimenting with agents around December: fast, but they left a mess ("dog dew") and then got stuck in loops, fixing one thing while breaking another. Agents are subject to messy code as humans are, perhaps with a different threshold. Early 2000s ideas that were impractical for humans become cheap for agents: CRAP (test coverage mixed with cyclomatic complexity into a per-function score) and mutation testing (flip operators, expect the test suite to fail, kill surviving mutants). His principle now is to let agents run these tools, constrain them to do a good job, and not impose his slowness on them by reviewing every line; he watches CRAP scores and spot-checks.

Why not steering instructions

Bob's early prompts held pages of rules on TDD and clean code, but the models treat rules like the Pirates of the Caribbean code: guidelines. Because of "lost in the middle", only the start and end of the context get priority, and long instructions sink. Matt relates it to the smart zone and dumb zone of a context window. Deterministic tools do not disappear from context; they put the agent in a loop ("change the code until the tool says OK"). The cost is productivity: Bob still gets a factor of 2 to 4 over a human, and has not found where too many checks defeats the purpose.

Multi-agent gauntlet

Advantages of multiple agents: parallelism, and focused context windows (agents born, do one task, die, so the next starts clean). Disadvantages: startup time and re-learning the context. Bob's pipeline: a specifier (human document into Gherkin acceptance tests plus a QA procedure written from a human operator's view), a coder (unit tests, code, Gherkin passing), a cleaner (CRAP analysis, code review), a hardener (merciless mutation testing), and a QA agent (turns the QA document into an executable script). A task that takes a single agent five minutes with questionable results takes about an hour here, versus half a day for a person, with much higher quality. Matt adds the idea of context trajectory: whatever steered a session early keeps shaping it, and only clearing context resets it.

Architecture and module design

Bob used to interrogate agents about the module structure, got scared by the answers, and then designed the structure himself. He had agents build an architecture viewer (clickable UML-like diagrams that drill down to code) and a dependency-rule checker with a specification file agents cannot violate; they fix violations by inverting dependencies, inserting interfaces or splitting modules. Well-partitioned modules help models for the same reason as the coffee and soap opera example: a consistent context avoids confusion. He agrees with Matt (citing John Ousterhout's deep modules) that models read interface names and tests rather than implementations. He has not managed to automate the architecture step.

What to change from the book

Thresholds: agents have large and accurate short-term memory, so Bob relaxes CRAP from about 4 for humans to 6, maybe 8, allowing larger functions. Disciplines: he does not enforce TDD on agents; they fall back to writing a function then its test, which is fine. His rule: do not impose human disciplines (behaviours) on agents, do impose human values (clean code); thresholds may move.

Planning, specs and agile

Heavy up-front planning with agents repeats the 1970s waterfall mistake: plans fall apart as agents run, and agents love writing gorgeous plans. Bob predicts spec-driven development will not work and returns to agile: do a story or two, look at the architecture, reorganize. His $1-per-change house-building analogy: when change costs almost nothing, fiddle until it looks right. Specifications are ephemeral and not kept in the repo; the end result is the specification. He tells people not to download his tools (CRAP for several languages, mutation tester, harness) but to point their agents at them and have them build their own. Both note the asymmetry that agents read everything humans write while humans do not read what agents write.

Learning strategic programming

Following Ousterhout, tactical work (the sergeant) is what agents do well; strategic work (the general) is what they do badly. Bob's advice to newcomers: write code for a year, learn the basics up to assembly, and when hired, be treated like an agent by the lead: same tasks, same deterministic tools, several months of being unproductive but learning. He recognized agents thrashing because he had been through that struggle; novices would not. Read the old books (DeMarco, Yourdon, The Pragmatic Programmer) and filter out the archaic parts.

Why fundamentals still matter

Software is the most complicated thing humans attempt, and fundamentals are how we organize that complexity so it can be conceived of by humans and by models modeled after humans. Each step up the abstraction ladder (binary, assembly, compiler, model) drew the same claim that everything would be ruined, and the same fundamentals applied. People who think fundamentals no longer matter will hit the wall, as Bob did; the rules thrown away get picked up off the floor a year later.