I run a company called lights-out, and we use the term for business processes, not for code. In a lights-out process, such as matching supplier invoices or handling returns, agents run without anyone watching each step, because every result can be checked as it happens. A lights-out software factory is something else: agents write the code and nobody reads it. So when someone stands on a stage and explains why those factories fail, I listen.
The talk is Why Software Factories Fail by Dex Horthy of HumanLayer, recorded at AI Engineer and published on the AI Engineer YouTube channel on 23 July 2026. It runs about nineteen minutes and is worth your time. Here is what I took from it, and what I think it means for anyone who decides how AI is used in their organisation.
The pitch everyone is hearing
The story goes like this. The models are good enough. Code is free. Humans are the bottleneck, so take them out. Let agents build, let agents review, route incidents and customer feedback straight into the queue, and stop reading the code. Invest in tests, monitoring and rollout instead.
Horthy tried it. In July 2025 his team went fully lights off (8:18 in the video). A few months later they hit a problem no agent could solve. The site was down, users were angry, and the team had to dig through a codebase they had stopped reading three months earlier.
He is not alone. He cites a report from Faros AI, The AI Engineering Report 2026, published in April 2026. It covers 22,000 developers in more than 4,000 teams. As teams moved from low to high use of AI, pull requests merged with no review at all rose 31.3%, bugs per developer rose 54% and incidents per pull request rose 242.7%. These are correlations in telemetry, not proof of cause.
It is not a skill issue
The usual answer is that you are holding it wrong. Write better prompts. Add another review bot. Spend more tokens.
Horthy's point is sharper, and I think it is correct. In his words, "no amount of harness engineering or loops maxing can solve what is fundamentally a model training issue" (2:53).
Here is the mechanism, simplified. Coding models are trained by rewarding them when they solve a task: the new test passes and the old tests still pass. One or zero. Nothing in that reward punishes a design that makes the next change harder. As Horthy puts it, "there's no way in this system that we can penalize it for poor program design or for eroding the maintainability of our systems" (12:52).
So the model learns to get the test green. A try/catch where none is needed. A type cast to make the error go away. Each change works. The codebase gets a little worse every time.
The reason this is hard to fix is time. "The cost function of bad architecture is measured in months and years" (13:23). A training run cannot wait six months to find out whether a change was a good idea.
And using another model as the quality judge only goes so far. His line: "if the model knew what good code looks like, it would probably write it in the first place" (14:35).
Why lights out works for some things and not for others
This is where the talk sharpened my own thinking.
When I talk about lights out for business processes, I mean things like matching supplier invoices, handling returns or updating product data. In those flows every transaction can be checked when it happens. The invoice matches the order or it does not. The quality is visible today.
Code is different. A change can pass every test today and still make the system harder to change next quarter. The cost of a mistake shows up months later, far away from the change that caused it.
That gives a simple test for any AI initiative: when does the cost of a mistake show up?
- If it shows up immediately and can be checked automatically, you can let agents run with the lights off.
- If it shows up months later, a human has to own the judgment. Not every keystroke, but the design and the final review.
Move the human, do not remove the human
Horthy does not argue for going back to the old way. He argues for moving the human effort earlier. Agree on the problem. Agree on the architecture. Then do something he says is under-emphasised: program design, meaning the types, the function signatures and how the pieces call each other. Then build in thin slices that can be checked along the way.
His claim: "30 minutes over here in pre-planning and alignment can save you hours in review" (16:50). And when reviews are drowning: "If you're drowning in PRs, you actually have too many bad PRs" (17:06).
This matches what I see in the agent teams I work with. Independent AI reviewers catch a lot and raise the floor. They do not catch a design decision that will hurt in six months. The work that makes the biggest difference happens before the first line is written, when a person decides what the change should look like and how big it may be.
It also fits what I wrote about how the bottleneck has moved. Building is no longer the expensive part. Deciding and reviewing are. The answer is not to delete the review. It is to make each review small and expected.
What I would ask as a decision maker
- Who owns the code? Not who wrote it. Who can explain it and change it at three in the morning. If the answer is "the agent", you have a risk on your balance sheet.
- What are we measuring? "Share of code written by AI" says nothing about quality. Look at incidents, review time and how long a typical change takes, over quarters, not weeks.
- Where does the human time go? If it all goes into reviewing big pull requests at the end, move it forward into planning and design.
- Which processes can really run in the dark? Sort them by when the cost of a mistake shows up. Start lights out where it shows up today.
Horthy ends on a point I agree with. These are constraints, not a verdict. Models are very good at some things and still weak at others. The job is to design around that, not to pretend it is not there. With planning done well, you move faster, as he says, "but you're still reading everything and you're still owning the code" (17:46).
*Source: Dex Horthy, HumanLayer, "Why Software Factories Fail", AI Engineer, youtu.be/Ib5GBkD555M. Quotes are from the video's automatic English captions, and the times refer to the video.*
Want to see how this works in practice? Read What a code factory waits for on emberloom.ai, or book an introduction.