AI-generated summary of AI-Friendly Code - The Missing Link for Speed with Quality, Adam Tornhill. Not written or verified by the author.

Takeaways: AI-Friendly Code - The Missing Link for Speed with Quality

2026-11-05 · Source: https://www.youtube.com/watch?v=ciRTdOIhNCc · Adam Tornhill, GOTO Copenhagen 2026 talk. Read from auto-captions, so names and terms may be misheard: "code house" is code health, "cloud" is Claude, "refactoring receipts" is probably "recipes", "Street Fighter free" is probably Street Fighter III.

Gist

Agents make teams 2 to 3x faster, but they often write code they can't safely change later. Studies he cites show the speed gain turning into complexity, defects, and incidents within months. His fix is an objective code quality metric, "code health", wired into the agent loop. Every agent edit gets a code health review, and the agent refactors until the code passes. Legacy code needs the same uplift before agents work in it, and the uplift can be agentic too. Case study: a 300,000-line C codebase raised to a perfect score in under a week for about $4,000 in tokens.

Vendor talk. The metric, the MCP server, and most of the research come from his own team. Background, not from the transcript: Tornhill founded CodeScene, which sells the metric. Every number below is from his slides and not checked here.

Takeaways

• Fundamentals stay stable. Tools change weekly, but the fundamentals last decades. He applies behavioral code analysis, from his book, to agentic coding.
• Agentic is harder. He wrote his last line of code by hand in September 2025. Working with agents is "significantly harder" than coding by hand. His team tracks task completion times and saw a 2 to 3x speedup after a few months.
• Speed buys reach. The value is what speed enables: tasks that weren't possible before, and unblocking yourself. He never learned GitHub Actions, so he used to interrupt a colleague. Now an agent does the simple cases and nobody context-switches.
• Studies he cites, unverified:
  • Late 2025, production data: 41% more defects after developers got AI coding tools.
  • 1,000+ open-source projects: velocity up 200% in the first weeks. Two months later the gain was gone and the projects were slower than before AI. Cause, per the study: a large rise in code complexity. He says AI runs in "self-harm mode."
  • "AI Whiplash" report, summer 2026, telemetry: bugs up 54%, incidents up 242%.
  • Alibaba research team: a simulated 6 months of maintenance. Agents do well on the first isolated tasks and break down over time. Quote: "the consequences of past decisions accumulate."
• Code health. A numeric score from 10.0 down to 1, built before generative AI. His "Code Red" paper: healthy code allows up to 10x faster task completion and up to 15x lower defect risk than unhealthy code. Controlled for task complexity and codebase size.
• AI is pickier than humans. His "Code for Machines" paper used an open competitive-programming dataset, chosen for its strong test suites, and measured how often an agent broke the tests. The score was calibrated so 9 means comfortable for humans. At 9, AI break rate is already up almost 60%. He says to aim for at least 9.5, ideally 10.
• What an agent wrote. He asked an agent to add keypress analytics (Amplitude) to a legacy C++ codebase. It worked on first run, but: one function with many responsibilities, deep nesting, resources that leak when an exception is thrown, and a catch-all that swallows every exception. He says research ties deep nesting to about 20% of programming mistakes (unverified). AI code it can't safely iterate on later makes a "self-enforcing death march loop."
• Illusion of instant software. The first version was never the hard part. 95% of a project's cost comes after the first release, where quality, maintainability, and architecture matter.
• Safeguard every agent edit. An MCP server runs a code health review each time the agent writes or changes code. Findings (low modularity, deep nesting, other smells) go back to the agent, which refactors and re-checks until healthy. He calls it a "self-correcting refactoring loop." The human sees only the final version. Demo: payment validation code went from low health to passing in three attempts.
• Average codebase scores 5.15. Far below 9.5. Legacy code and technical debt will bottleneck enterprise agentic adoption, so companies must uplift their code first.
• Agents refactor better with a target. Without guidance, an agent fixed about 50% of code health issues in low-health code and about 20% in better code. It turned conservative, with small changes like renames. With code health feedback from the MCP server, results rose sharply (exact figure not stated). His reason: a goal plus a description of what blocks it lets the agent plan.

Case study: legacy C uplift

• Target: 25-year-old C game code, 300,000 lines, mostly low health. Goal: every file at 10.0 with behavior unchanged.
• Correctness: a replay trace harness hashed frames and screenshots before and after each refactoring. They had to be "identical to what was seen before the refactoring." Colleagues also built and played the game after each iteration.
• Signal: code health as the objective quality signal and the direction.
• Playbook: when a refactoring worked, the agent documented when it applies, its constraints, and its mechanism. He calls this critical at scale. The idea: refactoring gets more effective as the agent reuses what it learned.
• Models: GPT models refactored well but documented poorly, so they settled on Claude Opus 5.5.
• Effort: two colleagues, part-time. About 2 weeks to set up the process, tests, and model choice. The uplift itself took a few days.
• Result: every file at 10.0. His estimate for doing it by hand: 12 to 18 months, 5 or 6 C experts who know the domain, high risk of failure.
• Outcomes he claims: healthy code needs 40 to 45% fewer tokens per feature on average, varying by language. For this codebase: 17% fewer AI-induced defects and new features 45% cheaper in tokens. Total uplift cost about $4,000 in API tokens.

Codebase-specific refactoring recipes

• The playbook began with generic refactorings: extract function, guard clauses, extract class. Deeper in, the agent had invented and named recipes specific to this codebase, such as "shared index range" and "action parameter", each with constraints and context.
• Action parameter: two functions ran the same process, one on X coordinates and one on Y. The agent extracted the shared process into one function. The originals became one-liners that pass in the part that varies, as a C function pointer.
• That mechanism is the Strategy pattern. His point: telling an agent at scale to "apply Strategy to deduplicate code" would be a mess. Narrow, local recipes bridge a codebase's specific problems to the general patterns the LLM already knows. That made agentic refactoring "predictable and mechanical" at scale.

Merge conflicts are a design smell

• Talks he saw in New York agreed: faster coding brings recurring merge conflicts at enterprise scale. The usual answers are stacked PRs, merge queues, and smarter conflict resolution. He calls those "patching symptoms."
• His root cause: socio-technical. The work agents do doesn't fit what the architecture supports.
• Author density map: colors files by how many authors touch them. Now he counts agents and shrinks the window from about 6 months to the past month.
• Example: Meta's folly. The async socket code is the hottest spot, one file touched by 58 authors. He says over 6 months, despite the one-month window above.
• Smells he saw there: a complex if followed by a long comment block, which signals a separate responsibility; scattered deep nesting; hundreds of functions in one file. That's a god class, "a module that compulsively collects behaviors and responsibilities." It forces agents on independent features into the same code: "god classes are our traffic jams." Refactoring it reduces organizational friction too.
• Next frontier: module-level quality is "largely solved" by this automation. AI-friendliness at the design and architecture level is the next challenge. He's writing about it on his Substack.
• Close: organizations with strong engineering practices that took code quality seriously are thriving with AI. Others struggle.

Patterns

• early speed gains reverse when output raises the cost of later change ← "the consequences of past decisions accumulate"
• the first version is cheap, most cost comes from changing it ← "comes after the first release"
• a machine reader needs a higher quality bar than a human ← "more sensitive and picky about code quality"
• gate each output on an objective check so humans review only passing work ← "never have to see these intermediate steps"
• a measurable goal plus named obstacles turns timid effort into a plan ← "the moment it gets a goal"
• a playbook of what worked, written while working, compounds over repetitions ← "refactorings should become progressively more effective"
• narrow local recipes bridge specific problems to general knowledge ← "serve as a bridge from specific problems"
• a central hub forces independent work to collide, so fix structure, not tooling ← "god classes are our traffic jams"