AI-Friendly Code: The Missing Link for Speed with Quality • Adam Tornhill • GOTO Copenhagen 2026
Adam Tornhill explores why AI agents produce fast early gains that often erode under growing code complexity, and how the Code Health metric, safeguarding loops, and codebase-specific refactoring can keep agentic development sustainable at scale, including a 300,000-line legacy case study.
Software fundamentals change far more slowly than the tools built on them, and Adam Tornhill argues that the same stable principles should guide how we use AI agents to write code. His own experience is a useful starting point. He wrote his last line of code by hand in September 2025 and has worked agentically ever since, producing more software in the past year than in the decades before. Agentic development is significantly harder than writing code manually, yet his team’s task completion times dropped by a factor of two to three within a few months. For him, the real value is not the speed itself but what speed enables: tackling work that was previously out of reach, and unblocking individuals so colleagues don’t have to context-switch to help with tasks like GitHub Actions.
The quality problem behind early AI gains
Quality is where the trouble starts. A late 2025 study using real production data found 41% more defects after developers adopted AI coding tools. A study of more than 1,000 open source projects showed a striking pattern: velocity jumped roughly 200% in the first few weeks, but after two months those gains were not just canceled out but reversed, and the projects were slower than before AI adoption. The cause was a massive increase in code complexity. Tornhill describes this as AI operating in a kind of self-harm mode, producing code it cannot safely modify itself. Managing accidental complexity is therefore central to succeeding with agentic coding.
To measure this, he uses Code Health, a metric that predates generative AI and scores code on a numeric scale from 1.0 to 10.0. In the “Code Red” research, healthy code allowed task completion up to 10 times faster than comparable work in unhealthy code, and reduced defect risk by up to 15 times. Healthy code is also easier to navigate for both humans and agents. A well-structured codebase makes the right place to change feedback evaluation obvious and limits the blast radius of changes.
Why AI needs stricter quality bars than humans
A follow-up study, “Code for Machines”, asked whether AI cares about code quality. Using a competitive programming dataset with strong automated tests, the team measured how often agents broke working programs. The Code Health scale was originally calibrated so that a score of 9 indicated code humans can comfortably work with. At that level, however, AI defect risk had already risen by almost 60%. For agents, the bar needs to be at least 9.5, and ideally a perfect 10.
Legacy rewrites don’t escape this. Tornhill walked through AI-generated C++ code that added keyboard-press statistics to a legacy codebase. The code worked on a first test drive, but it concentrated too many responsibilities in one function, nested logic deeply, leaked resources whenever an exception was thrown, and swallowed exceptions in a catch-all clause. When something goes wrong, it fails badly and silently. His verdict is that AI frequently generates unhealthy code that it cannot later iterate on safely, creating a self-reinforcing doom loop.
The illusion of instant software
Building a first prototype has never been the hard part of software. Tornhill argues that roughly 95% of the cost of a software project comes after the first release, where maintainability, architecture, and code quality start to matter. An Alibaba research paper simulating six months of real maintenance found that coding agents perform well on isolated tasks but break down over time, because the consequences of past decisions accumulate. Production telemetry in the AI engineering “whiplash” report points the same way, with bugs up 54% and incidents up 242%.
Safeguarding every change
The response is to safeguard all AI-generated and AI-edited code for health. Tornhill’s team packaged the Code Health metric as an MCP server connected to Claude. Each time the agent generates or modifies code, the server reviews its health and returns concrete findings, such as lack of modularity or deep nesting. The agent then runs a self-correcting refactoring loop until the code is healthy. In a payment validation example, the first attempt had low health, the second was better but still imperfect, and the third was healthy. The human reviewer never sees the intermediate steps and starts from healthy code. Because LLMs work well toward a defined target, this loop can keep new code healthy.
Uplifting legacy code at scale
Safeguarding new code is not enough, because existing business-critical code also needs to be AI-friendly. The average codebase has a Code Health of 5.15, far below the level where defect risk climbs steeply. Tornhill sees this gap as a bottleneck for enterprise adoption of agentic coding, meaning many organizations will need to uplift their codebases, ideally with agents.
Early experiments were discouraging. Asking an AI to fix code health issues without guidance resolved roughly half of the issues in the best case, but for healthier code success fell to around 20%, with the AI becoming conservative and making trivial changes like renaming variables. Once the agent received Code Health data through the MCP server, giving it a direction and a description of what prevents the goal, it formed plans and worked its way toward healthy code.
In a case study, the team took Street Fighter 3, a 25-year-old C codebase of about 300,000 lines, with the goal of reaching a 10.0 code health while preserving functional correctness. Correctness was verified with a replay trace harness that hashed frames before and after each refactoring, plus playtesting by colleagues. The agent was instructed to build a refactoring playbook, documenting the conditions, constraints, and mechanisms of each successful refactoring, so that later refactorings became progressively more effective. Two part-time colleagues spent about two weeks setting up the process. GPT models refactored well but documented poorly, so Claude Opus was chosen for its better playbook capture. The uplift itself took a couple of days, and every file reached a 10.0. Tornhill estimated that the manual equivalent would have taken 12 to 18 months and a team of five or six senior experts with deep domain knowledge.
The most interesting finding was in the playbook. Alongside generic refactorings like extract function and extract class, the AI had invented codebase-specific refactorings, such as the “action parameter” pattern. Two near-identical functions differing only in their X or Y coordinate transformation were consolidated into a shared internal function that takes the varying behavior as a parameter, similar to the strategy pattern. Broad instructions to apply strategy at scale would have failed, but narrow, codebase-specific refactorings bridge local problems to general design knowledge already encoded in the LLM. That mapping is what made agentic refactoring predictable and mechanical at scale.
Engineering and business outcomes
Healthy code is also token-efficient. On average, features in healthy code required 40 to 45% fewer tokens to implement, varying by language. The uplift yielded a 17% reduction in AI-induced defects, and new features are projected to cost 45% less in token spend. The API cost of the complete uplift was roughly $4,000, which gives a concrete business case.
Merge conflicts point to architecture
Recurring merge conflicts in enterprise agentic workflows are, in Tornhill’s view, symptoms of socio-technical problems: a disconnect between what agents are doing and what the architecture supports. Rather than just building better PR tooling, he applies behavioral code analysis to find coordination hotspots. Where he once measured developer contention over six months, he now measures agent contention over the past month. In Meta’s Folly codebase, one file responsible for asynchronous socket communication had been modified by 58 different agents. Code review revealed deep nesting, long comment blocks signaling separate responsibilities, and hundreds of functions of similar shape: a “god class” that forces agents working on independent features into the same code.
Module-level code quality is largely solved by this kind of automation, Tornhill says, but scaling AI-friendliness to design and architecture is the next big challenge. Organizations with strong engineering practices are already thriving with AI, while others struggle to see any benefit, and focusing on engineering fundamentals is an absolute prerequisite.