The one-line function problem in AI-generated code

What the pattern looks like

Here's a mild, real-shaped example. One task, four new functions:

function getUserId(user: User) {
  return user.id;
}

function isActiveUser(user: User) {
  return user.status === "active";
}

function formatUserLabel(user: User) {
  return `${user.name} (${user.email})`;
}

function buildUserLabel(user: User) {
  return formatUserLabel(user);
}

getUserId renames a property access. buildUserLabel is a pass-through: it calls one function, forwards the argument, adds nothing. Each is called once. A human doing this task would probably have written one function, or none.

Multiply that by every task, every day, for a quarter.

Why assistants write like this

Our best guess: the models absorbed twenty years of clean-code advice in which extracting a function is almost always praised and almost never questioned. Extraction looks like craftsmanship in a diff. And a diff is exactly the unit the model is optimizing, because a diff is what gets reviewed.

The cost sits at a level nobody reviews. Reading fragmented code means chasing every behavior through three trivial hops. Stack traces get taller. Grepping gets noisier. Review fatigue compounds, because fifteen tiny functions take longer to verify than the four lines of logic they contain.

Why review misses it

Reviewers see PRs. This pattern doesn't live in any PR; it lives in the sum of them. Three harmless helpers in Tuesday's PR, three more on Wednesday. No individual approval was a mistake, and yet six months later every file is a pile of indirection and the lead engineer is running a manual audit on their own codebase.

To be fair to the assistants: extraction is often right. A one-line function that names a business rule, isEligibleForRefund, is good code, and we'd defend it. The problem isn't any individual small function. It's the ratio.

It's not one team

We assumed this story was one team's bad luck, then went looking. Public GitHub is full of AI instruction files, the CLAUDE.md and .cursorrules files teams write to steer their assistants, and thousands of them carry rules against this exact behavior. PyTorch's executorch repo puts it plainly: "No trivial (1-2 LOC) single-use helpers." Nobody writes a rule against a problem they hit once, and there are thousands of these files.

The research record backs the reviewers up. One 2026 study found that 9.9% of AI-generated methods get deleted during code review, which the authors describe as unnecessary cognitive load on the humans doing the reviewing. GitClear's analysis of 623 million changed lines found cross-file function calls down 35% since 2023: new code increasingly stands alone instead of reusing what already exists.

One honest complication. The pattern varies by model and workflow: a large 2026 study of AI-generated files found some assistants fail in the opposite direction, producing fewer but fatter functions, still wrapped in deeper call hierarchies than human code. The constant is needless indirection. Sometimes it looks like a pile of tiny wrappers, sometimes like an extra abstraction layer around a five-line change. A useful detector has to count both.

The ratio is countable

That's the useful part. "The AI writes slop" is a vibe, and vibes lose arguments with velocity charts. But this particular slop has a signature you can count in any PR: how many new functions the change introduces, what fraction are trivial (one statement, give or take), what fraction are pass-through wrappers that forward to one call, and what fraction have exactly one caller.

A PR that adds 17 functions, 14 of them one-liners, 12 with a single call site, is over-fragmented. That's a number a lead engineer can put in front of a team, and a number a team can push back on. Both directions beat arguing about taste.

If you want to check your own codebase today, you can approximate this with a script and your language's parser in an afternoon. Count new function declarations per merged PR and sort by body length. In our experience the distribution tells you the story fast.

Where Qualyn fits, honestly

Qualyn today estimates how much of each change is AI-written and weighs it in the release call: safe to ship, why, and what would change the answer. It does not yet count fragmentation. We're building that detector now: a per-PR function inventory that reports exactly the signature above, with the offending function names and line numbers attached, so the conversation starts from evidence instead of suspicion.

Plenty of teams have already written rules telling their assistant not to do this. As far as we can tell, nobody measures whether it listened. That's the gap the detector closes.

The lead engineer in the story found the pattern with their eyes, at the cost of their own review capacity and a team-wide audit. That job should be automatic. If you want to run the detector on your repos while it's in beta, we're looking for teams to test it against real history.

Frequently asked questions