AI-Friendly Code (Code Health for Agents)

The idea, quantified by Adam Tornhill's research, that a codebase's health determines how safely and effectively AI can refactor it—AI-friendliness being the probability that AI-generated refactorings preserve behavior and improve maintainability.

Also known as: AI-friendliness, AI-friendly, Code for Machines, Not Just Humans

Part of: Code Quality

How authors use it

Oldest first (extraction date when no publication date is known).

Documents (5)

• Practices I Abandoned with Agents: An Ode to Test-Driven Development Adam Tornhill · 2026-09-03 source ↗ Reader 🖥️
  Granular, human-cognition-scaled Test-Driven Development does not survive the transition to agentic coding and should be replaced by a coarser, feature-level practice — tests (especially end-to-end) as the human/agent abstraction boundary, with failing-test discipline retained but no longer organizing work into small red-green-refactor steps.
• Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework Daniel Curtis · 2026-07-28 source ↗ Reader 🖥️
  Remix 3's beta preview is a ground-up architectural break from Remix 2 — dropping the React runtime for a forked, imperative Preact, rebuilding routing on raw Fetch/Response objects, and introducing server-driven 'frames' and a bundler-less 'unbundling' model — a deliberate bet that web-standards conformance beats framework abstraction, one so disruptive that it forces every existing Remix app into a full rewrite and has split developer commentary between praise for its explicit simplicity and skepticism toward a team already known for reinventing itself.
• Fragments: February 18 Martin Fowler · 2026-02-18 source ↗ Reader 🖥️
  AI-assisted software development is best understood as an amplifier of a team's existing practices rather than a disruptive break, so the field's real work is rebuilding the human-era practices that are predictably breaking—through emerging disciplines like the supervisory middle loop, risk tiering, TDD-as-prompt-engineering, and platform 'bullet trains'—amid far more shared uncertainty than settled answers.
• Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases Adam Tornhill, Markus Borg · 2022-03-08 Reader 🖥️
  Code quality, measured via CodeScene's Code Health metric, has a quantifiable and substantial business impact — low-quality code produces 15 times more reported defects, takes 124% longer to resolve on average, and is up to 9 times less predictable to resolve than high-quality code — so code quality must be treated as a business concern tracked with the same rigor as financial KPIs, not dismissed as a purely technical aesthetic.
• Software Design X-Rays Adam Tornhill · 2018-03 source ↗ Reader 🖥️
  The real cost and risk in a large codebase is invisible in the code's current structure and can only be recovered by mining version-control history as a behavioral record of how people actually work on it — and once recovered (as hotspots, change coupling, code age, developer fragmentation, and knowledge maps), that record should drive both technical refactoring priorities and the alignment of team structure with system structure (Conway's Law), because most expensive software problems are organizational problems wearing a technical disguise.

Propositions touching this concept (3)

By publication month, oldest first (extraction month when no publication date is known).

2026-02

• explicitAs coding shifts from typing to steering generation, organizations may converge on fewer tech stacks and codebase topologies than today, selected partly for 'AI-friendliness' — availability of a good harness — rather than purely for human developer experience or technical merit.
  Harness Engineering · p5

2026-04

• explicitestablishedDeep modules with simple interfaces make a codebase both testable and AI-friendly.
  It Ain't Broke: Why Software Fundamentals Matter More Than Ever · p11

2026-07

• implicitcorroboratedToken cost of a fixed representative task can function as an early, measurable proxy for a codebase's 'AI-friendliness' or architectural health — the same underlying idea as 'healthier code yields more reliable AI-generated changes,' but operationalized here as agent read-cost rather than defect risk.
  The Economic Benefit of Refactoring · p9

Tensions

Open gaps (9)

• incompleteThe article never explains what 'unbundling' concretely means for build tooling in practice — how source maps, tree-shaking, code-splitting, or third-party bundler-dependent tooling are handled once 'the runtime rather than a bundler is the source of truth' — so readers cannot assess the real tradeoffs of dropping the bundler model.
  Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework — read next: Remix 3's own documentation/source once the beta stabilizes; comparisons with other runtime-first, no-bundler approaches (e.g., Deno's native TypeScript execution, import maps) to see what unbundling typically costs or saves.
• incompleteThe article reports that a forked Preact replaces the React runtime but never quantifies the performance, bundle-size, or ecosystem-compatibility implications (e.g., React DevTools, existing React component libraries) of forking Preact rather than adopting it unmodified or retaining React.
  Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework — read next: Benchmarks and compatibility write-ups once Remix 3 ships stable; the fork's own diff/changelog against upstream Preact.
• illogicalThe article asserts Remix 3 is 'the boldest bet yet on web standards over framework abstractions' against Next.js, SolidStart, and SvelteKit, but never tests whether Remix 3's claimed full-stack breadth (auth, uploads, data/database management, theming) is actually delivered with comparable maturity to those competitors — the comparison is asserted, not demonstrated.
  Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework — read next: A hands-on feature-parity comparison across Remix 3, SvelteKit, and SolidStart on the specific claimed full-stack capabilities.
• uninformedThe article does not explain why the team chose to keep JSX as authoring syntax while dropping React's virtual-DOM/reconciliation model entirely — a design tension between 'web standards' purism and retaining a React-shaped authoring surface that is never addressed or justified.
  Remix 3 Beta Preview Ditches React for a Web-Standards Full-Stack Framework — read next: The team's own 'Wake Up, Remix' rationale post; any interviews with Michael Jackson explaining the JSX-retention decision.
• incompleteEvery social metric in the book (ownership, fractal value, knowledge maps, knowledge-loss simulation) is built entirely on human-author version-control identity as a proxy for who understands the code. The book has no answer for a world where a large share of commits are authored by AI agents under human supervision/review, which breaks the implicit equation of 'who wrote it' with 'who understands it' exactly where agent-authored commits are frequent and numerous. For AI-era teams, this suggests the next generation of these metrics may need 'who understands this code' decoupled from 'who/what wrote this code' — reviewer/approver identity or demonstrated modification history might be better proxies than raw commit authorship once agents are prolific contributors.
  Software Design X-Rays — read next: Look for post-2023 work that re-derives social code metrics (ownership, knowledge mapping, bus-factor-style analyses) using reviewer/approver signals rather than commit authorship, and for any extension of Tornhill/CodeScene's own Code Health work into the social half of this book.
• incompleteThe hotspot/interest-rate framework (technical half of the book) has a documented modern descendant — CodeScene's Code Health metric, shown elsewhere in this corpus (extract-codescene-refactoring-at-scale-with-agents) to predict agentic refactoring performance on at least one case study. But that validation covers only the technical metric; it remains untested in this corpus whether the book's social/organizational metrics (ownership, developer fragmentation, knowledge maps) predict anything about agent-era risk at all, since agents don't suffer diffusion of responsibility or the forgetting curve the way human teams do.
  Software Design X-Rays — read next: Look for empirical work correlating team-level social code metrics (fractal value, ownership diffusion) with outcomes in codebases where AI agents do a large share of the implementation work.
• incompleteThe study's data and conclusions are entirely pre-coding-agent (mined circa 2021, published March 2022): it establishes that Code Health predicts human-developer defect rates and cycle time, but says nothing about whether the same metric predicts AI-agent performance on the same code. That extension is only tested elsewhere in this corpus, not in this paper.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases — read next: See extract-codescene-refactoring-at-scale-with-agents for the agentic-era follow-on that treats this paper's validated metric as the optimization target for a coding agent refactoring a 300k-line codebase.
• illogicalCausality between Code Health and the dependent variables (defects, dev time) is not established, only correlation across 39 codebases -- the paper itself names this as a threat to internal validity (low quality could be a symptom of time pressure or churn rather than a cause) -- yet the Discussion and Conclusion sections repeatedly use causal framing ('the business advantage of high quality code should be unmistakably clear') without hedging to the same degree as the Threats to Validity section.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases — read next: Look for a follow-up randomized or quasi-experimental study (the authors propose RCTs or Bayesian causal analysis) that isolates the causal direction between code quality and defect/time outcomes.
• incompleteAll 39 codebases come exclusively from CodeScene's own customer base, and the paper cannot disclose selection criteria or codebase identities for confidentiality reasons. Companies that already pay for a code-quality tool are plausibly a non-random, quality-aware sample, which the paper notes as an external-validity threat but does not attempt to bound.
  Code Red: The Business Impact of Code Quality -- A Quantitative Study of 39 Proprietary Production Codebases — read next: Look for an independent replication using a non-CodeScene-customer dataset or a different code-health/quality metric to check whether the 15x/124%/9x figures hold outside CodeScene's own customer base.