AI Agents and the Refactoring That Never Happens

A September 2026 essay on rosenfeld.page about a decision the author sees teams no longer making. The complaint is not that coding agents write bad code. It is that experienced engineers have stopped saying "this has become unmanageable, we need to refactor it before we go any further" ai-agents-refactoring-never-happens.

Getting lost was the trigger

The argument starts from why software is modular at all. Modularity, encapsulation and layering are presented as concessions to the size of human working memory: a system gets cut into pieces until each piece fits in one person's head, because that is the only way someone can change it safely or review someone else's change.

Code drifts out of that shape through ordinary requirement churn. A clean rule picks up a branch for a new case, then an exception, then a special case on top of the exception, until the code is nothing but exceptions and no rule is left. Every experienced developer knows the moment that follows, when you are debugging, you follow the code, and you get lost. The author's point is that this feeling used to be a signal. A senior engineer who got lost would stop and rewrite the thing so that they and everyone after them could reason about it again. The reflex was set off by a human limitation, and it was one of the main forces keeping long-lived systems maintainable.

He is careful not to blame agents for the weakness. Deadlines, roadmaps and managers asking why you are rewriting something that works were already pushing refactoring down the list, and senior engineers had already stopped pushing back as hard. What agents removed is the last internal trigger that still fired in spite of all that.

The agent never gets lost

An agent can read the tangled function, trace every caller, and correctly add the next branch and the one after it, inside code nobody on the team understands any more. So the signal never fires. Unless the harness, the prompt or the review criteria tell it to question the structure, it will maintain the mess indefinitely, because the mess is not a problem for the agent.

The failure the author worries about is on the human side. Nobody on the team can fully reason about key parts of the system, reviews turn into rubber stamps because the reviewer cannot follow the change, and the team trusts the agent more precisely because they understand the code less, which he calls exactly backwards. The loss arrives without any single alarming moment, because the moment that used to raise the alarm has been taken out of the loop.

Clean code is cheaper for the agent too

The essay then drops the principled framing for a cost argument that holds even for someone happy to let agents do all the work. Tangled code means more files to read and more branches to trace on every edit, so more tokens per change. When the relevant logic does not fit into a bounded slice, agents are also more likely to assume a branch does something it doesn't or miss an exception buried three levels deep. The same boundaries that keep a module inside a human's head keep a change inside something the agent can reason about reliably. This is the argument of clean-code-coding-agents, arrived at from the refactoring side, and benchmarking-opus-5-slopcodebench is one measurement of how agent-written code grows in complexity when nothing pushes back.

Putting the checkpoint back

The prescription is to ask deliberately what the agent will not ask: do I still understand this part, or have I let the agent understand it for me; could a human debug it without the agent; has the code become all exceptions and no rule; is now the time to pause features and refactor. Some of this can go into the harness, with agents told to flag modules that have grown past a reasonable size or branching complexity and to propose refactorings rather than only extending. The author says that helps but does not move the responsibility, since the humans are the ones who lose the ability to understand the system. His closing distinction is that "the agent can still make sense of it" describes the agent's capacity, while "the system is healthy" describes ours.

How it sits in the vault

The essay is short on evidence: it is one practitioner's observation of a trend, with no teams, numbers or incidents named. Its value is the mechanism it names. peril-of-laziness-lost makes the neighbouring argument that agents have no time constraint pushing them toward simplicity; this essay adds that they also lack the comprehension limit that used to stop humans in their tracks. The human half is ironies-of-automation and skill-atrophy-supervision-paradox: once the machine handles the routine case, the person loses the practice that let them notice when something is wrong, and rubber-stamp review is the vigilance problem in code-review form (see code-review-throughput-limits).

not-understanding-your-codebase is the counterweight. Goedecke argues that partial understanding is the normal state in any large system, which fits this essay only if the code still supports local reasoning, and that is exactly what the missing refactoring erodes. owning-ai-written-code makes the same point from the individual's seat rather than the team's: writing code used to force understanding, and with agents doing the writing, understanding becomes a separate cost someone has to choose to pay. back-to-coding-by-hand and building-syntaqlite-ai are first-hand accounts of what the drift looks like once it is noticed.