Debt at agent speed

In one minute Popular open-source projects built with coding agents carry about 4.5 times the share of too-big functions that projects started in 2021 and 2022 had at the same age, and about 3 times after accounting for codebase size.¹ The step lands in 2025, when coding agents arrived, and it shows up whether or not a project credits agents in its commits. There are more too-big functions, and a list of them is still short enough to name and give an owner.

What we measured

Does a codebase built with agents age differently? We answered that with our study of 200+ popular open-source repositories. A young project and a ten-year-old one are not a fair match, because old code has had years to sprawl. So we compared projects at the same stage of life: at 90 and 180 days old, and at their 300th and 1,000th commit.

We counted too-big functions: functions so long, so branchy or so deeply nested that a reviewer would ask for them to be split. The exact rule is 200 or more lines, 40 or more independent paths through the code, or blocks nested 6 deep.²

The main comparison set agent-built projects against projects started in 2021 and 2022. Agent-built means a popular project started from April 2025 where at least a quarter of commits carry an agent trailer, a line in the commit message that credits a coding agent. There are 52 of them, against 40 projects from 2021-22.

At six months old, 1.42% of functions in the agent-built group were too big, against 0.32% in the 2021-22 group.¹ That is roughly 1 function in 70 against 1 in 300. Allowing for codebase size, since bigger codebases have more chances to hold a large function, the odds are about 3 times higher.

The gap holds at every stage we measured. It is widest early, at about 6 times at 90 days old. By the 1,000th commit it is about 2.4 times, 1.14% against 0.47%, as the older projects slowly grow their own large functions.³

These really are agent-built projects. Most of them added an agent config file, such as AGENTS.md or CLAUDE.md, within two months of their first commit. Only one of the 40 older projects did.⁴

The step lands in 2025

Figure 2.1

Sort every project by the date it started and the pattern turns into a step. Projects started before mid-2024 sit below 0.6%. Projects started in 2025 or later sit between 1.4% and 1.8%.⁵

The projects from 2023 to mid-2024 settle the timing. They started in the chat-assistant era, and many of them are AI tools themselves. Their numbers look much like 2021 and 2022. The step arrives in 2025, which coincides with coding agents that edit many files and commit on their own.

We tried to explain the gap away, and it held each time. Young projects that barely credit agents in their commits sit at the same level as the agent-built ones. Within the agent-built group, the share of too-big functions does not rise with the share of commits that credit an agent. Older AI and machine-learning projects, the same kind of product, do not show the step. Allowing for commit speed and team size leaves the gap where it was. And a fresh set of projects, set aside before we saw the first results, gave the same answer.⁶

The study is observational. It shows when the step arrived, and that the obvious alternatives do not explain it.

Bigger, not more copied

The popular story about AI-written code is copy-paste and constant rewriting. Across all agent-era projects (started 2025 or later) and pre-agent projects (started 2021 to mid-2024), our data pointed the other way on both. Copied lines were lower in agent-era repos, 9.1% against 14.5%, and so was code rewritten within three weeks of being written.⁷ Agent-era repos also carried far more test code per line of product code.

What went up was size and complexity. Functions that are hard to follow, meaning a reader has to track many branches and nested conditions at once, were more than twice as common.⁷

The big functions are real code. Two independent AI reviewers, who could not see which project a function came from, read 100 random too-big functions. None of the ones from agent-era repos were generated boilerplate. Three in four were real application logic or screen code that a reviewer would ask to split.⁸

Why the big functions matter to you

A function that handles every checkout path becomes a crossroads. Each new feature adds a branch to it. Agent sessions read it, extend it and move on, because extending the existing path is the easy move.

One likely path runs like this. An agent asked to add a discount rule finds the function that already handles prices and adds ten lines. That is a sensible local choice, and a busy engineer would make the same one. The difference is volume. As chapter 4 shows, each contributor in an agent-era repo adds over three times as much new code a week. Repeat that sensible choice often enough and one function holds the logic for half the product.

In every group we studied, too-big functions were the ones most likely to need a bug fix within three months.⁹ Agent-era projects have more of them. Even at 1 in 70, the list in a typical repository is short enough to name, give an owner and plan for. Chapter 6 covers how to pay it down, and chapter 8 turns the tracking into a maturity level.

Do this on Monday

1. List the too-big functions in your busiest repository with the free tool lizard (command in the appendix), and keep the 20 largest.
2. Count how often each one's file changed this quarter with git log --since="90 days ago" --no-merges --oneline -- <file> | wc -l.
3. Take the five that are both big and busy to your next planning meeting, and give each a named owner.

How Repowise does this Repowise scores every file from 1 to 10 for code health using fixed rules and no model, then lays git history on top. The output is the Fix first list: a short weekly queue of large functions that also change often, each with the reason it is there.

Sources