Why Software Factories Fail

What happens when a team stops reading the code its agents produce? StrongDM’s software factory offers an ambitious example: agents implement and validate software without human code review. Humans still specify intent and constraints, but the surrounding narrative pushes further—spend more tokens, remove the human bottleneck, and ship more.

Production introduces a harder test. Dex Horthy recalls Mario’s warning at AI Engineer Europe that coding-agent mishaps were causing outages at companies that should know how to avoid them. He also cites Faros AI’s engineering findings, describing more and longer review comments, more unreviewed merges, and rising incidents and bugs per developer. These are reported warning signs, not proof that coding agents caused every deterioration.

The promise Horthy challenges is 10–100× faster development with high quality and no human code review; it is not a measured result. Better prompts, more loops, and adversarial review bots may improve a workflow, but a harness cannot by itself repair a missing training objective. To understand the limit, follow the software factory from its feedback loops into the reward signals used to train coding models, then back into a workflow that preserves human ownership.

Horthy traces the term software factory to a 1968 NATO conference, but starts his working model with an ordinary team before widespread AI coding. Engineers, product managers, and leadership decide what should happen. A tracker such as Linear or Jira records that work as a state machine. Someone selects a task and implements it, with automated or manual testing along the way.

A pull request introduces another checkpoint: automated checks, human code review, and sometimes someone pulling down the change to test it. Failures send the work back to implementation. Once deployed, the change reaches users, whose bug reports and feature requests return to the team. Monitoring provides another feedback path, including the incident that wakes an engineer during the night. Production is part of the development loop, not its endpoint.

In Horthy’s baseline, implementation and review can each take hours or days. That makes discovering disagreement during review expensive. Architecture proposals, sprint planning, and team discussion move decisions earlier, reducing the likelihood of rework and the amount of reasoning a reviewer must reconstruct from the finished code. The next wave of factory claims—companies saying agents now produce 75% of their code—changes who implements the work, but does not automatically remove this need for alignment.

Replace the human implementation step with an agent backed by orchestration, a harness, a sandbox, a model, and perhaps computer use. In Horthy’s comparison, agent implementation takes minutes or hours while human review and testing still take hours or days. Agentic code review and regression testing speed up the checking stage, but review can remain the limiting step.

The same factory can accept more inputs automatically. Monitoring can route an incident into a coding task, allowing an engineer to wake up to a proposed fix rather than an untouched alert. User feedback can go straight into the implementation queue. Neither path establishes that the resulting patch is correct: the remaining human work is deciding how much to request and how quickly to review and test the results.

The lights-off proposal, which Horthy introduces with a credit to Dan Shapiro, removes code reading from that remaining work. Investment shifts toward testing, monitoring, rollout controls, and the other systems surrounding implementation. If those safeguards are sufficient, throughput becomes a question of how much work people can ask the agents to do. The maintenance problem appears when those safeguards fail to reveal what the codebase is becoming.

The constraints matter. Horthy invokes Addy’s distinction between a small side project and an established enterprise system: advice that works for one may be irrelevant to the other. His concern at HumanLayer is solving hard problems in complex, existing codebases. Such a codebase need not be an old Java application. Horthy suggests that rapidly changing repositories can become difficult for agents after three to six months, an observation from his experience rather than a universal threshold.

HumanLayer tried full lights-off development in July 2025. Horthy describes the eventual recovery problem: an issue resists better prompting, research, and attempts to reproduce it, so a person must investigate code they stopped reading months earlier. While users experience downtime, the engineer has to recover both system behavior and lost familiarity with its implementation. The time saved by skipping review can return as difficult incident work.

Maintainability means being able to change one part of a system without unexpectedly breaking others. Horthy connects the problem to Martin Fowler’s shotgun surgery code smell and points toward software-design work such as John Ousterhout’s. His diagnosis is that models do not reliably maintain or improve codebase quality over time without substantial human steering.

Better performance on an isolated bug or a new marketing site does not establish better long-term maintenance. Horthy explicitly acknowledges that he cannot prove his broader quality claim with the available benchmarks. It is an experience-based diagnosis and an evaluation gap: the tests that show agents improving at individual tasks do not yet settle what happens to a repository after sustained autonomous development.

Consider Claude Code’s rise. Horthy cites $4 billion and, tentatively, $9 billion in revenue within a year, without specifying an accounting basis. Those figures serve as a growth anecdote, not a verified business comparison. His technical question is more useful: why did this agent stand out when Aider and Codebuff already offered tools for reading, writing, editing, searching with grep, and running bash?

Horthy attributes the difference to training a model against the same harness distributed to users. In his account, Claude Code marked the first such integration by a model lab. The advantage is not merely having the right tool names; training can make the model better at choosing and sequencing those tools in an agentic loop. He cites an OpenAI talk arguing that a harness builder unable to update model weights through reinforcement learning is disadvantaged relative to a builder controlling both the model and its environment.

Using slides credited to Calvin French-Owen, Horthy reduces each agent step to its essential interface: the context window enters the model, and the next action emerges. The harness controls the environment and what comes back into context. Training changes which actions the model is likely to choose. That distinction makes the reward attached to a successful coding attempt consequential.

A simplified coding-agent reinforcement-learning loop generates multiple attempts at the same problem, records their traces, and scores the results. Weight updates make rewarded behavior more likely and unsuccessful behavior less likely. Horthy introduces SWE-bench Multilingual as an example of this task shape. He characterizes its tasks as roughly 15-minute problems with binary rewards for fixing the issue without regressions, mentioning repository work such as Redis, jq, and Django.

The worked example is a Ruby issue in fastlane: a missing nil check causes a failure and stack trace. Horthy walks through the following evaluation procedure:

1. Check out the base commit from before the historical human fix.
2. Keep both the reference solution and the behavioral test patch hidden from the model.
3. Let the agent attempt the fix and save its patch.
4. Undo the agent’s edits to test files, preventing it from obtaining success by weakening or commenting out tests.
5. Apply the held-out test patch and run both the existing and new tests.
6. Award the reward only if both sets pass.

The reference solution and the held-out tests have different roles: the agent proposes the implementation, while the evaluator checks behavior using tests the agent did not control.

This reward procedure measures passing behavior, not the future cost of changing the implementation. A patch can satisfy the tests without receiving any penalty for poor program design or eroded maintainability. Horthy’s examples are unnecessary exception handlers and expedient type casts, with the latter credited to Vaibhav. These shortcuts illustrate the gap between making a test green and making the system easier to work in.

An execution failure can appear during the coding episode. Bad architecture may impose its largest costs months or years later, when another change exposes tangled dependencies or forces widespread edits. Horthy describes verifying maintainability as far harder than checking whether code runs and tests pass. The difficulty is also one of credit assignment: how should a later maintenance failure alter the reward for a particular earlier coding decision?

Longer and richer evaluations begin to address this gap. Benchmarks and training verifiers must use separate datasets, as Horthy acknowledges; their similar task structures nevertheless help explain what kinds of behavior can be evaluated. His examples progress from longer tasks to more demanding acceptance criteria.

Horthy describes SWE-Marathon through roughly 400-hour tasks and an Excel-feature-cloning example; these are his characterizations of its scope. DeepSWE’s tasks are written afresh rather than taken from completed historical changes. That originality addresses one route to contamination, although it does not independently establish what every model has seen during training.

FrontierCode adds a particularly useful check: agent-written tests should fail against the pre-patch code. Otherwise, the tests have not demonstrated that they detect the behavior the patch is meant to repair. A judge model also assesses adherence to code-quality rules. Horthy remains skeptical that model judgments alone can resolve the maintenance problem: review agents and extra tokens can raise the floor, but their ceiling still depends on what models can learn from the available training signals.

Future models may overcome these limitations. For current work, Horthy’s response is to restore human code review and make it less expensive through earlier planning. The objective is not to abandon automation: use AI to prepare the decisions that would otherwise surface as objections to a completed patch.

Start with product review. Establish the problem, the desired behavior, and any mockups needed to make that behavior concrete. Horthy shows a recent feature mockup as an example of this level of discussion. Small changes can still go directly to the agent; the workflow does not require a large design exercise for every edit.

Next, review system architecture: component contracts, data models, constraints, and how the systems fit together. An architecture document creates a shared high-level picture before implementation. But agreeing on that picture does not settle all the design decisions the agent will face inside the program.

Program design fills the gap between architecture and code. Inspect the types, method signatures, program layout, call stacks, and interactions that will realize the architecture. Horthy emphasizes that getting the high-level architecture right is not enough to leave all remaining choices to the model. He cites Dylan Mulroy’s use of call graphs in planning as a concrete way to examine those interactions.

Then plan vertical slices: the implementation order, coordination across repositories, and checks between phases. The plan should explain how the work will progress across the system and how each stage will be tested. Horthy contrasts this with the horizontal plans models often produce, referring to his AI Engineer Miami talk for the fuller treatment. In this recording, the examples focus on documents that make the tests and intermediate steps explicit.

Horthy’s practical estimate is that 30 minutes of planning and alignment can save hours of review, not a controlled measurement of the workflow. The mechanism is straightforward: resolve consequential choices while they are still cheap to change, so reviewing the implementation becomes checking agreed decisions rather than discovering and debating them for the first time. That makes reading every line more feasible.

A queue of pull requests is not just a volume problem. A well-aligned PR lets the reviewer recognize the decisions already discussed and verify their implementation. A misaligned one forces both reviewer and author back into design work. Horthy uses a PR needing 20% rework as an illustrative case of substantial intellectual and emotional burden, not a measured average. Even a mostly usable patch can be expensive if the remaining changes require difficult negotiation and reconstruction.

AI-assisted planning can shorten alignment by gathering the relevant information. Prior agreement can shorten review, and agents can shorten implementation. These gains reinforce one another when the stages fit together: humans still read the changes and own the code, but they spend less time repairing avoidable misunderstandings after implementation.

The engineering task remains to solve problems under the constraints that actually exist. Models are strong at some parts of development and weak at others. Horthy’s closing advice is to use loops where they help, seek ways to multiply engineering effort, and keep tackling difficult problems without assuming that automation has removed the need for judgment.

He presents HumanLayer as an AI IDE and collaboration platform supplying building blocks for this kind of software factory. Its shared workspace is compared to Figma for Claude Code and Codex, with workflows intended to support the planning and review process described here. Better software-quality verifiers are presented as forthcoming, not as a demonstrated solution already in place.

At the close, Horthy invites design partners and founding engineers in San Francisco, says the slides are available, and describes HumanLayer as free for small teams at the time of the talk. The proposed direction is collaborative, model-assisted engineering: make hard changes in complex codebases while retaining enough understanding to maintain what gets shipped.