AI and agents · Agentic engineering · 7 min

Dark factories: what an experiment reveals about agents and architecture

Automating code writing and testing does not, on its own, automate architectural judgment. A case reported by HumanLayer helps show where human review is worth keeping.

Dark factoryCoding agentsArchitectureHuman review
Three software factory modelsConceptual comparison of different human oversight points in flows that include agents. The main difference is where human judgment comes in; the categories are an explanatory frame, not a measured performance scale.01Lights-off02Agent works alone03Slow review04Review at the end05Leverage point06Design and slices
Three software factory modelsThe main difference is where human judgment comes in; the categories are an explanatory frame, not a measured performance scale.
Local feedback and late signalsTests provide fast signals about the properties they check; maintainability requires observation and review over time. Combining automated tests with review and operational signals helps detect risks a single suite may not cover.01Small change02Tests and CI03Design review04Production use05Team learning
Local feedback and late signalsCombining automated tests with review and operational signals helps detect risks a single suite may not cover.

The promise of turning off the lights

The idea of a “dark factory” is to delegate the full cycle of a software task to agents, from ticket to integration or deployment, with minimal human reading of the code. The appeal is clear: expand capacity and shorten cycles. The risk appears when the volume of changes grows faster than the team’s ability to understand them.

In a 2026 talk, Dex Horthy described an internal “lights-off” automation trial his team had started in 2025 and decided to stop after running into a problem that was hard to diagnose. The story is an experience reported by one team, not proof that every autonomous system degrades within three months, nor a comparative benchmark.

A green test answers a limited question

A suite can confirm that certain behavior cases still work. It does not automatically show that the design is easy to extend, that the boundaries between components are right or that the next change will be cheap. The result depends on what the tests check and on the quality of their oracles.

That is why “CI passed” and “the architecture keeps its properties” are different statements. Bringing them closer requires design reviews, static rules, contracts, integration tests and human review proportional to the impact of the change.

Three ways to combine agents and oversight

The source material contrasts three operating models. A “lights-off” factory removes human reading; a slow-review factory lets the agent produce large changes and inspects them at the end; a leverage-point factory invests human judgment before implementation and keeps deliveries small. These are explanatory categories, not a normative taxonomy or a universal measure of productivity.

The third option aims to reduce uncertainty before delegating: agree on purpose, constraints, architecture and a first verifiable slice. The agent then speeds up execution within a frame the team can still understand and correct.

Automate without losing ownership of the system

A sustainable practice assigns autonomy by risk. Start with small, reversible and measurable tasks; have the agent open reviewable changes instead of deploying without gates; evaluate not only the output but also diffs, dependencies, tests and operational signals.

The useful question is not how many lines an agent can generate, but whether the team can explain, maintain and revert what it produced. Early oversight protects that shared knowledge.

Sources and rigor

References

Conclusion

Agents can increase execution capacity; preserving the architecture and intellectual ownership of the system still requires adequate signals, understandable changes and human accountability.

Keep exploring

Related articles