Why Software Factories Fail (or: harness engineering is not enough)
Why Software Factories Fail
(or: why harness engineering isn't a silver bullet)
Disclaimer: I lead HumanLayer, a company focused on the intersection of human and agent collaboration. Consequently, my perspective here might be slightly biased. However, I believe the core arguments are compelling and relevant to anyone navigating the current AI landscape.
The Race Toward "Lights-Off" Coding
Currently, there is a frantic rush to integrate AI coding agents into production environments. The dominant trend is loop engineering—the belief that the solution to everything is simply more loops.
We've seen extreme examples of this:
- StrongDM described a "lights-off" software factory where neither the writing nor the reading of code requires human intervention.
- OpenAI's Symphony (discussed by Ryan Lopopolo) pushes a similar narrative.
The underlying premise is simple: Humans are the bottleneck.
While I have immense respect for the intelligence of the people building these systems, a cynical observer might argue that this narrative is primarily designed to funnel more venture capital into the "slop cannon."
The Cost of the "Slop Cannon"
The reality on the ground is often messier. At AI Engineer Europe, Mario warned us to decelerate, noting that companies are experiencing outages caused by coding agents—outages they had no business having in the first place. As Matt Pocock observed, codebases are currently deteriorating at an unprecedented rate.
While definitive data on the "dark factory" model (like StrongDM's) is scarce, other signals are worrying. A report from Faros AI suggests that since the mass adoption of AI coding tools in early 2024:
- Pull-request (PR) review quality has plummeted.
- The volume and length of comments have increased.
- A significant number of PRs are being merged without any human review at all.
While this is a correlation rather than a "smoking gun," it aligns with the general trend of increasing software "slop."
The "Skill Issue" Gaslighting
When developers struggle with these tools, they are often told it's a skill issue. The narrative suggests that if you aren't seeing magic results, you just aren't token-maxxing correctly.
I'll admit, I've contributed to this. Some of my own videos on "how to use agents better" have garnered millions of views. I mention this not to brag, but to establish that I have spent a significant amount of time deep in the trenches of context engineering and have seen what actually works.
The False Promise of Harness Engineering
The current "hype" suggests that through sheer harness engineering, we can achieve a utopian state:
| The Promise | The Mechanism | The Expected Result |
|---|---|---|
| Velocity | More loops + better prompts | |
| Quality | More linters + "adversarial" bots | High-quality, bug-free code |
| Effort | Automated PR reviews | No more manual code reviews |
The belief is that if we just sprinkle enough "magic words" into our review bots, the software will essentially build itself.
The Core Thesis: It's a Training Problem
I want to argue that no amount of loopmaxxing or harness engineering can fix a fundamental model-training issue. To reach this conclusion, I had to analyze how coding models are actually trained and evaluated via RLVR (Reinforcement Learning from Verifiable Rewards) and standard benchmarks.
Here is what I will explore in this series:
- The History: How software factories have evolved since 1968 and the AI's role in that evolution.
- The Benchmark Paradox: Why models can ace "frontier" benchmarks while still generating mountains of slop.
- The Middle Path: How to maintain high velocity without incinerating your codebase.
I aim to move past the "AI-psychosis" of daily plugin updates and provide general principles that work regardless of the specific framework you use.
A Note on "Vibe Coding"
It is crucial to distinguish between two very different activities, as Addy Osmani has pointed out:
Vibe Coding: A developer building a side project that maybe a dozen people will ever use.
Enterprise Engineering: A team struggling to keep a decade-old legacy system operational for another quarter.
These two scenarios share almost no constraints. Most of the advice currently circulating is tailored for the former, but applied to the latter—which is a recipe for disaster.
Related Resources:

This post expands upon my keynote delivered at the AI Engineer World's Fair 2026. Special thanks to @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, and @jeffreyhuber for their insights.