Why AI Software Factories Fail

In "Why Software Factories Fail", Dex Horthy describes an uncomfortable limit of agentic software development: more loops, better harnesses, and faster review bots are not enough if nobody owns the long-term shape of the code.

The piece pushes back against the idea of the "lights-off software factory": tasks enter a queue, agents write code, tests and review agents approve it, and monitoring reports problems later. That sounds like productivity. In mature codebases, it can create the opposite: more code, faster, that becomes harder to change later.

The Factory Is Not The Problem

A software factory is not a new idea. Even before AI, development already moved through loops: product idea, ticket, implementation, pull request, review, deployment, monitoring, user feedback.

AI agents mainly accelerate the implementation step. What used to take hours or days can now take minutes or a few hours. That moves the bottleneck:

• Humans write less code themselves.
• Humans have to evaluate more output.
• Review becomes the scarce resource.
• The temptation to automate review rises.

That is where the risk starts. When humans leave the code review loop, the remaining question often becomes: "Do the tests pass?" That is not enough.

Tests Do Not Measure Maintainability

The strongest point in the article is not that coding agents are bad. It is that today's models and benchmarks reward solutions that pass visible tasks, while bad architecture is only indirectly penalized, if at all.

An agent can fix a bug, keep every test green, and still make the codebase worse:

• broad try/catch patches
• weak typing
• hidden coupling
• logic in the wrong place
• changes that make future features more expensive

The problem does not show up immediately. Tests give feedback in seconds. Bad architecture costs weeks or months later, when a small change suddenly touches eleven files.

Harness Engineering Has A Ceiling

Harness engineering matters: good tools, clean sandboxes, clear edit mechanics, linting, tests, regression checks, and agentic review all improve results.

But a harness can only compensate so much for what the model has not reliably learned. Dex argues that if training and verification need fast, unambiguous signals, maintainability remains hard to optimize. There is no simple oracle for "will this code still be easy to change in six months?"

That does not make automated software factories useless. It makes them bounded. The limit is not speed. The limit is design responsibility.

The Countermodel: Lights On

The productive answer is not to slow agents down. It is to place human judgment where it has the most leverage.

The article names four phases:

1. Product design: what is being built, for whom, and how will success be recognized?
2. System architecture: which services, data models, endpoints, and dependencies are involved?
3. Program design: which types, signatures, call stacks, and file boundaries does the implementation need?
4. Vertical slices: build, test, and resteer in small working increments.

This is not nostalgic "humans must do everything themselves" thinking. It is a leverage model. Agents can move fast, but humans define the structure that keeps speed from turning into technical debt.

The ag3nt.id Take

Agentic engineering does not win through autonomy alone. It wins through better division of labor.

Coding agents are strong when they get clear context, bounded tasks, working checkpoints, and hard verification points. They are risky when they produce code for weeks that nobody truly understands anymore.

The mature software factory is therefore not "lights off." It is "lights on": agents handle implementation, research, tests, variants, and review preparation. Humans keep product judgment, architecture judgment, and final responsibility for maintainability.

The practical sentence for teams is: move 2-3x faster without making the codebase blind. Teams chasing 10-100x faster while treating review as an annoying leftover may not be building a factory. They may be building a debt machine.

Conclusion

"Why Software Factories Fail" is a useful counterweight to the autonomy hype. It does not say: do not use coding agents. It says: do not confuse throughput with quality.

The next stage of agentic software development will not come only from better loops. It will come from better interfaces between agent work and human design judgment.

Source: Dex Horthy / HumanLayer, "Why Software Factories Fail"

Further reading: Agentic Engineering: Why CLI-First Changes The Productivity Boundary