Paying it down without breaking things

In one minute Agents can now do most of the typing in a refactor, so the hard part is choosing what to split and where to cut. In our study, when a team split a big function, the new helper functions took 41% to 57% of the later edits in that area, and the area as a whole stayed about as busy as before. Plan each split around how the code actually changes, and judge it by the whole area, not the one function.

The bill was already large

Technical debt is the extra work you pay later for shortcuts taken earlier. It was a heavy cost long before coding agents. In a 2018 survey for Stripe, developers said they spent 13.5 hours of a 41.1-hour week dealing with it.¹ That is about a third of the week, measured before AI tools arrived, and any speed-up from agents has to be counted after that bill is paid.

Much of the cleanup itself is mechanical. Renaming, moving a block into its own function, updating every caller, running the tests: an agent does these quickly and never gets bored. A refactor that used to take a week of careful hand edits can now take an afternoon.

So the hard part has moved from typing to judgement. Someone still has to decide which file deserves attention this month, where a big function should be cut, and how you will know afterwards that it helped. Ask an agent to "clean this up" and it will make those choices for you, and they will not reflect how your team actually works in that code.

What happens after you split a big function

We wanted to know what a refactor buys in practice. So in our study of 200+ popular open-source repositories, we looked for the most common kind: lifting part of a big function out into a new, smaller helper function. We found 450 of these splits across 58 projects, and compared each split function with similar functions nobody touched, over the following 60 days.²

Three things showed up in every sample we ran, including a set of projects we kept aside until the end.

The original function got quieter. It was edited less often than the functions nobody split, so in that narrow sense the refactor worked.

The new helpers picked up the work. Between 41% and 57% of the later edits in that area landed in the helpers that had just been created.

The area as a whole did not cool down. Counting edits to the original function and its new helpers together, the total stayed about where it was. A split changes where the edits land, and the area keeps its workload.

Figure 6.1

What this means for how you refactor

A split is a bet about where future changes will land. A good split puts each spot that keeps changing into its own small function, where a change is easy to read and easy to review. A bad split cuts along lines that look tidy on screen, and the next few changes all have to touch several helpers at once.

So refactor by plan. Before anyone splits a function, look at its recent history. Which lines change together? Which parts have needed fixes? Cut along those lines. An agent asked only to "make this smaller" will skip exactly that step.

A good request to an agent comes in two steps. First ask for the plan: which lines move, what each new function is called, which callers change, and why those cut points match the history. Read it. It takes a few minutes, and it is where the judgement lives. Only then ask for the edit.

Protect the change before it starts. Name the tests that cover the area and run them before and after. If there are none, have the agent write a few tests that pin down what the code does today, odd parts included, and commit those first. A refactor should change the shape and keep the behaviour, and those tests are how you check.

Then measure the area. Count edits to the old function and everything it was split into, for the 90 days before and the 60 days after. If the area is as busy as ever but each change now touches one small helper, count that as a win, because the same work is now easier to review. If each change touches more files than before, the cut was in the wrong place.

Start with deletion, then aim the budget

The cheapest debt to pay is code nothing uses. Deleting it removes lines that reviewers still read and agents still search through, and nobody has to learn a new structure afterwards. Agent work can leave orphans of its own, such as a helper written for a first attempt and abandoned when the second attempt worked.

Take care with whole files. A file nothing imports can still be loaded by a build script, a config entry or a loader that reads it by path. Search the whole repository for the file name, including config and scripts, before you delete it. Remove dead code in small pull requests, one directory at a time, so each one is easy to undo.

After deletion, decide where your review time goes. Most teams have a fixed amount. Spend it on files that score poorly on code health and also change often, since that is where problems tend to surface. Code health here means a score for a file built from its size, nesting, duplication and change history. At the same review budget, ranking files by Repowise's health score found 2.3 times the defects that CodeScene's score did, across 21 repositories.³ That is the job the score is built for: deciding what to look at first when you cannot look at everything.

Keep the output short. A debt backlog with hundreds of items is a list nobody reads. A "fix first" list of a handful of items, each with a reason, a first step and the tests to run, gets acted on. Review it monthly, and drop anything in a file nobody has changed this quarter. Quiet code is cheap to leave alone.

Do this on Monday

1. Pick three files from your most-changed list, and count the edits to each one's folder in the last 90 days.
2. Delete one unused module, after searching the whole repository, including config and build scripts, for its name.
3. Ask your agent for a split plan based on the function's git history before you ask it to split anything.

How Repowise does this Repowise scores every file for code health and lays git history on top. The output is the Fix first list: the few files that are both weak and busy, each with a reason, a first edit and the tests to run. Repowise never edits your code; your team or your agent makes the change.

Sources