Bad Code Does Not Find the Bottom

Physical systems announce some of their limits. A beam bends. A bearing overheats. A truck can carry only so much weight before it refuses the load in a way nobody can ignore. Software is less considerate. It can remain available while becoming harder to understand, riskier to change, and more expensive to operate. The screen still loads, so the decline gets mistaken for stability.

That is why weak systems can survive for years. Every local decision can look rational: duplicate this branch to meet the deadline, bypass that check to unblock a release, add another exception because the old exception is now part of the workflow. No single change has to collapse the product. It only has to make the next good change slightly less likely.

There is no automatic moment when the repository declares bankruptcy and closes itself. The business keeps choosing between today's visible request and tomorrow's less visible cost. Without a hard boundary, today usually wins. The system can sink a long way before revenue, reliability, or regulation finally turns internal decay into an external event.

Human delivery accidentally limited some damage. A team could only type, review, and release so much code in a week. Coordination was expensive, but it also created pauses. Agent-run delivery removes many of those pauses. A factory can attempt more changes, explore more branches, and revise more quickly than a human team can follow line by line.

That speed is an advantage only when rejection scales with production. If the agent can generate ten plausible fixes while acceptance still means a tired person scanning the diff, the system has multiplied its ability to hide weak decisions. The reviewer sees syntax and style. The accumulating cost lives in duplicated concepts, tangled ownership, missing boundaries, and behavior nobody can safely remove.

A better model does not solve this on its own. Models optimize the task and context they receive. If the factory rewards passing the nearest test, shipping the requested surface, and avoiding an immediate error, the worker can succeed while the system gets worse. Intelligence does not create a quality floor. Controls do.

A quality standard matters when it can stop the route. Start with the properties the business cannot afford to lose: permission boundaries, data integrity, recovery, understandable ownership, bounded complexity, and the ability to reproduce important behavior. Turn those properties into tests, architecture rules, budgets, and evidence requirements that run before acceptance.

The boundary has to measure the system, not merely the patch. A change can be clean in isolation and still add a third way to represent the same state. It can have excellent unit coverage and still make recovery depend on an undocumented sequence. It can satisfy the ticket while widening the authority of every future worker. Local correctness is necessary. It is not enough.

This is also why the builder cannot be the only judge. An agent that chose the implementation will naturally prove the interpretation it used. Independent gates need to ask whether the repository still holds its contracts, whether the operating path can recover, and whether the change increased a risk budget beyond its allowed boundary. The evidence should survive after the agent session disappears.

Teams often treat technical cleanup as a future project because the next feature has a customer, a deadline, or an executive attached to it. Cleanup has none of those until the system fails. That makes it structurally easy to postpone. A backlog item cannot compete with a release gate because only one of them can stop today's work.

The factory should charge degradation to the change that creates it. If complexity crosses its budget, the same work packet pays it down. If a new exception weakens a policy, the route demands a narrower design. If an incident exposes a missing invariant, the invariant becomes machinery before the next similar change ships. The cost stays close to the decision instead of becoming an inheritance for a future team.

Not every judgment can become a metric, and forcing one can make the system worse. People still decide which tradeoffs are acceptable and when an unusual consequence earns an exception. But an exception should be explicit, bounded, and recorded. Human judgment belongs at the edge case, not inside a permanent promise that somebody will clean up the ordinary damage later.

Our position is that agents will replace roles built around repeatable software production. That makes the quality system more important, not less. When fewer people touch each change, the organization cannot rely on experience leaking through conversation or on one veteran noticing that a familiar shortcut is becoming dangerous.

The durable knowledge has to live in the route: the rule that blocks the shortcut, the replay that reproduces the failure, the budget that catches the drift, and the record that explains why an exception exists. Every accepted change teaches the factory what it permits. Every rejection should teach it what it refuses next time.

Software will not find the bottom for you. It will keep running while the cost of a safe change climbs and the number of people willing to touch it falls. Set the floor before you scale the workers. Then make it mechanical enough to hold when nobody is watching the code arrive.