Adam Tornhill on AI-Friendly Code and Sustainable Agentic Development

Some aspects of software development change weekly, but the fundamentals remain surprisingly stable. I want to use behavioral code analysis to understand how those fundamentals apply to agentic coding.

I wrote my last line of code by hand in September 2025 and have worked agentically since. In my experience, working with agents is harder than writing code manually, but our team’s task completion times improved by a factor of two to three after a few months.

The most interesting benefit is what that speed makes possible, including tasks we would not have attempted. Agents also help me unblock myself: for simple GitHub Actions changes, I no longer have to interrupt a colleague and cause a context switch.

Quality is an obvious concern. I show research from 2025 reporting 41% more defects after AI adoption. Another study of more than 1,000 open-source projects found an initial velocity increase that had disappeared after two months as code complexity increased.

My interpretation is that agents can write code they cannot safely modify later. Managing accidental complexity is therefore central to successful agentic development. I use a particular metric called code health to discuss the problem.

Consider a dense function full of nested conditions. It is difficult to infer even the domain from it. After refactoring, its intent as an agent loop becomes visible, with an obvious place to change feedback evaluation. That helps both people and agents navigate and limits the blast radius of a change.

Our earlier Code Red research associated healthy code with substantially faster task completion and fewer defects. Those results predate generative AI, so our research team asked whether code health also matters to coding agents.

In our Code for Machines study, we used an open competitive-programming dataset with strong automated tests. Agents were given tasks, and a test failure counted as a break. The open dataset makes it possible for others to repeat the experiment with different models or measures.

The relationship was stronger than I expected. On our code-health scale, a score of nine was calibrated to be readable for humans, but the study found markedly greater agent defect risk than in the healthiest code. I argue that agents need an even higher quality bar, around 9.5 or above on this particular scale.

Can an agent simply rewrite legacy code for us? I asked one to extend C++ code so it would report keyboard presses to an analytics service. The result appeared to work initially, but it packed too many responsibilities into one function and used deeply nested logic.

The generated code also lacked robust error handling: exceptions could leak resources, and a catch-all could silently swallow the error. My concern is not merely that the first version is untidy, but that the agent may struggle to safely iterate on the code it created.

This is the illusion of instant software. A first prototype is only the beginning; the substantial maintenance work comes after release, where architecture and maintainability matter. I cite a study simulating six months of maintenance in which performance deteriorated as prior decisions accumulated.

I also point to an engineering report that associates AI adoption with increases in bugs and incidents. These figures are findings from the reports I cite, not a guarantee about every team. My conclusion is that generated and modified code needs a quality safeguard.

Our approach packages the code-health metric in an MCP server. After the agent writes or changes code, it checks the result, receives specific issues such as deep nesting or poor modularity, and refactors before checking again.

In a payment-validation example, the first version scored poorly. The feedback prompted another attempt and then a third. The aim is for a person to begin review with code that has already passed this automated health check, not to replace human validation.

Safeguarding new changes is only the first step. Existing business-critical code also has to be workable for agents. In our dataset, I report an average code-health score of 5.15, well below the level I recommend for agentic work.

That gap suggests legacy code can constrain adoption. We investigated whether agents could improve it themselves. In one experiment, an agent fixed more obvious issues in poor code but became conservative as health improved, often making changes such as renaming that did little to improve the underlying design.

When we supplied specific code-health findings through the MCP server, the agent had a goal and a description of the obstacles. It could form a plan, act on the findings and measure progress. We then asked whether this approach could work at scale.

For a case study, we chose a roughly 25-year-old Street Fighter III codebase: about 300,000 lines of C. Our goal was to improve its code-health score while maintaining functional correctness, so that agents could add features more safely.

The team used replay traces and compared hashes of captured frames before and after changes, alongside actual play testing. Code health supplied the quality signal. The agent also built a refactoring playbook, documenting successful transformations, their conditions and constraints.

Two colleagues worked on the project alongside other responsibilities. They spent about two weeks establishing the process and tests, then the automated uplift took less than a week. We tried several models and selected one that better documented its refactorings for the playbook.

By the end, the files reached a score of 10 on our metric. I would previously have expected a manual effort of this size to require a specialist team and many months; the result was striking to me. The score is a measure within our framework, not proof that all possible defects have been eliminated.

The playbook included familiar transformations, such as extracting functions, but also narrowly defined recipes tailored to this particular codebase. Each recorded the contexts and constraints under which the transformation applied.

One example deduplicated two functions that applied the same transformation to the X and Y coordinates. The agent extracted the common process and passed the varying operation as a function pointer. The underlying mechanism resembles the strategy pattern.

The useful innovation was the specificity of the recipe. A broad instruction to apply the strategy pattern everywhere could cause trouble; a narrow recipe maps a local problem to general knowledge and can be reused mechanically when its conditions hold.

A score should not be a vanity metric. Our research associates healthy code with lower token use, averaging 40–45% fewer tokens for comparable work across languages. For this case study, I estimate lower future defect risk and token costs; the API token cost of the uplift was about $4,000.

Beyond individual files, faster agentic coding raises coordination problems. Teams often respond to recurring merge conflicts with better pull-request queues or conflict-resolution tools, but those can treat the symptom rather than the architectural cause.

Behavioral code analysis can show where many contributors or agents repeatedly touch the same files. In a visualization of Meta’s Folly project, one asynchronous socket file had contributions from 58 authors over six months, a signal worth investigating rather than a diagnosis by itself.

Looking at that file, I see nested logic and many responsibilities in one large module. Such a god class becomes a traffic jam: even people working on independent features must change the same place. Modularizing the code can reduce organizational friction as well as local complexity.

I see making architecture AI-friendly as the next challenge beyond module-level code health. Organizations with strong engineering practices are better positioned to benefit from agents. My conclusion is to keep investing in software-engineering fundamentals as the tools change.