The Factory Needs a Complexity Budget

For years, maintainability had a crude but useful alarm: an experienced engineer would open a module, follow its branches, and get lost. That feeling created friction. Before adding one more exception, somebody would argue for a refactor because the next change had become too hard to predict or review.

That alarm was never reliable. Deadlines could silence it, ownership could be unclear, and cleanup was easy to push behind visible features. Still, the person doing the work eventually had to confront the mess. The code had to fit inside a human reasoning process before the human could safely change it.

Agents weaken that constraint. They can search a larger surface, trace callers quickly, and keep moving through structure that would exhaust a person. The immediate result looks excellent: another change lands without the expensive pause. The delayed result is a system that keeps accepting complexity because the worker does not experience confusion the way the old maintainer did.

A worker's ability to complete the next task says almost nothing about the condition of the system. It proves that one route through the code was available under the current context, tools, and model. It does not prove that another worker will find the same route, that a reviewer can judge it, or that the fiftieth exception will remain safe.

The cost still arrives. Tangled logic forces every future run to retrieve more files, trace more branches, reconcile more exceptions, and carry more assumptions. The model may not complain, but the factory pays in context, latency, retries, and wider test surfaces. Complexity has become an operating expense even when no person feels lost.

It also weakens proof. A review cannot challenge a change it cannot bound. A test suite can cover known cases while the interaction surface grows beyond what anyone intended. When the explanation for a module becomes 'the agent understands it,' the organization has handed both execution and interpretation to the same machine. That is dependency, not control.

Do not ask an agent to remember to value clean code. Put complexity on the work route. Track signals that expose the mechanism: branching added to already dense logic, dependencies crossing a module boundary, the number of files required to explain a change, repeated exceptions to the same rule, and verification that expands every time the area moves.

No single number can decide whether a design is good. That does not make the signals useless. Start with a budget for change, not a universal score for the repository. If a task crosses the budget, the factory must take a different path: propose a boundary, simplify the rule, split the change, or send the structural decision to a human who owns the consequence.

The gate has to change what happens next. A dashboard that says complexity rose after the merge is an obituary. A review comment the builder can wave away is advice. The useful control blocks the ordinary route and demands either a smaller surface or an explicit exception with an owner and an expiration date.

A complexity budget does not give agents permission to rewrite whatever looks inelegant. Refactoring changes working behavior, often across the exact paths that are hardest to see. The factory should require the same discipline it expects from feature work: a stated invariant, focused acceptance conditions, an incremental route, and proof collected outside the builder's narration.

Start where the factory is already paying. Find a module that repeatedly consumes broad context or produces the same review objection. Record the behavior that must survive. Then let the agent create a narrower boundary and prove that both the old cases and the intended change pass through it. The goal is not prettier code. The goal is a cheaper, more governable next change.

Keep the evidence after the refactor. If the context surface shrinks, checks become more focused, and later work touches fewer unrelated files, the intervention earned its cost. If none of those things change, the factory moved code without reducing the operating burden. Do not confuse motion with improvement.

Our position is that agents should take over repeatable implementation work, including much of the refactoring. But the trigger cannot depend on a worker feeling overwhelmed. Machines do not owe you the same discomfort that once warned a senior engineer to stop.

Human judgment still decides which boundaries matter, how much complexity a product can carry, and when a rewrite creates more risk than it removes. The factory should preserve those decisions as budgets, gates, and evidence requirements. That moves judgment higher in the system instead of summoning a person to rediscover the same tangled module on every change.

The agent will keep going. That is why you hired it. Your job is to make sure 'keep going' does not mean 'keep making the next change more expensive.' Give the factory a complexity budget, make crossing it alter the route, and refactor when the evidence says the system is spending too much to understand itself.