Resources / Agent Engineering
Every dark factory is one review gate away from a lit one.
Loops, harnesses, and factories, walked through with real interactive diagrams instead of another wall of prose. Then the part most articles on this topic skip: what a lit factory looks like once it has actually shipped in production, with a human owning the outer loop.
Credit where it's due
We did not coin "software factory," or light vs dark.
"Software factory" traces to Bob Bemer's 1968 paper on the economics of program production, written around the same NATO Software Engineering Conference that gave the industry the phrase "software crisis." Hitachi was the first company to formally build a division around the idea, branding it Software Works in 1969.
The light vs dark factory framing, and the review gate as the bottleneck that will not scale with compute, comes from two more recent sources. Dex Horthy, co-founder of HumanLayer, gave a talk called "Harness Engineering is not Enough: Why Software Factories Fail," arguing a fully automated dark factory corrupted a codebase over three months, and proposing that humans stay involved earliest, at planning and architecture, rather than only at a final review. Addy Osmani's "Software Factories, Light and Dark" built on both, and put it plainly: "verification, not generation, is the real constraint on a factory."
What we bring is not the term or the framing. We've been running the lit-factory shape in production internally, before this vocabulary existed: the AY multi-agent build cycle that plans, locks, builds, adversarially reviews, tests, and merges, with a human owning two checkpoints in the outer loop. The diagrams below are that system running, not a theory of one.
The atom, the walls, the org chart
Three words, three sizes. A loop is one task retrying itself. A harness is what keeps one loop from breaking things. A factory is many harnessed loops sharing a queue and a gate.
1. Loop
One task, act, check, repeat, until a condition is met or it gives up.
2. Harness
Tools, retries, structured output, and guardrails wrapped around one loop so it can act safely.
3. Factory
Many harnessed loops running at once, routed through a shared queue and one review gate.
The closed loop, end to end
Intent and signals feed a queue. The queue feeds a harness. Automated checks catch what they can and retry. Everything that survives reaches the review gate, and monitoring after deploy feeds the next round of intent.
The amber box is the review gate: the one step in the loop that does not scale by adding compute. Everything before it can run faster with more hardware. The gate only scales with how much a human, or an unfakeable automated check, can actually verify.
Same pipeline, different lights
The difference between a dark and a lit factory is not whether a human exists. It's where their judgment sits in the pipeline. Toggle between the two below.
Design
Human hereGenerate
Verify
Human hereReview gate
Human hereDeploy
Judgment moves upstream to design, stays at verify, and holds at the review gate. Same pipeline, three lights instead of one.
Back pressure: generation is not the limit
You can only hand a loop as much autonomy as you can cheaply and reliably verify. Drag the slider and watch where the queue actually backs up.
Illustrative model, not measured data. Verification throughput is held fixed because review capacity is the slow-changing side: more reviewers or better checks move it, more generation does not.
Wide generation mouth → narrow verification neck
Comprehension debt compounds quietly
Tests stay green while the gap between what shipped and what a human could explain keeps growing. It does not fail loudly. It fails the day someone has to touch the part nobody understood.
Illustrative, not measured data. In a dark factory, tests stay green while the gap between what ships and what a human on the team could actually explain keeps widening. Comprehension debt does not fail loudly. It fails the day someone needs to change the part nobody understood.
What earns a loop the dark
A decision, not a default. Most work should stay lit until it earns its way to running unattended.
Earns the dark
- The check is cheap to run, so it can fire on every single attempt.
- The check runs at high frequency, not once at the end of a long batch.
- The oracle is unfakeable: a type gate, a property test, a green or red signal that cannot be gamed.
- The loop is short, roughly three to ten steps, before context starts to drift.
- A wrong answer is cheap to undo and does not touch a live customer.
Stays lit
- Verification is expensive or slow, so it cannot run on every attempt.
- The blast radius is large: auth, billing, public APIs, anything customer-facing.
- The loop is long or open-ended, past the point where context reliably holds.
- The spec is ambiguous or still drifting, so there is no stable oracle to check against.
- Getting it wrong is expensive, embarrassing, or hard to reverse.
Our /go cycle, as a lit factory
Not a mockup. This is the actual shape of the AY framework's build loop: a human approves the plan before code is written, and a human reviews the code before it ships. Everything between those two checkpoints runs fast and automated, with a real loop-back on failure instead of a rubber stamp.
The amber boxes are the two places a human owns the outer loop: approving the plan before any code is written, and reviewing the code before it ships. Everything between those two boxes, the build and the adversarial review, runs closer to dark: fast, automated, and retried without waiting on a person for every step.
Stop Theorizing About the Factory. Have One Built.
Tell us the workflow. We'll tell you honestly what can run dark, what has to stay lit, and place a forward deployed engineer to build the harness and the review gate if you need one.
Book a 30min Free Strategy Call
In this call, we'll walk through your project scope, timeline, and goals - so we can both check if we're a fit. No obligation, no slide deck, just a working session.
Don't want a call? Email walid@ayautomate.com
“The team is super fast - sometimes we had to slow them down. We managed to scale the company without investing into hiring.”
Elie Salame
COO, Adstronaut.io
We've created products featured in
Walid Boulanouar
View LinkedInConsultation
This call is for teams ready to move. If that's you, pick a time.
Recommended services
Forward Deployed Engineers
The embedded engineers who wire the harness, the checks, and the review gate inside your stack.
Graph Engineering
The topology and mechanics of the agent graph running inside the factory: nodes, edges, shared state.
AI Agent Development
Custom agents built with guardrails, evals, and human approval points where the action is high risk.
Agent Swarms Architecture
How AY's multi-agent swarm coordinates roles, handoffs, locks, and the tracking layer.
FAQ
Software Factory Questions
What is a software factory in AI-assisted coding?+
A software factory is a harnessed loop running at scale: many agent loops, each wrapped in a harness of tools and retries, routed through a shared queue and a review gate before anything ships. The term is decades old and predates AI coding, but the framing is being reused right now to describe how AI coding agents run in production.
What is the difference between a light and dark factory?+
A dark factory ships a diff that no human has read: the only judgment applied is whatever an automated check can catch. A lit factory keeps a human in the loop, but not just at the end reading a diff. Judgment sits upstream, at design and architecture, backed by a real review gate before deploy.
Who coined the term software factory?+
The concept traces to Bob Bemer's 1968 paper on the economics of program production, written around the same NATO Software Engineering Conference that named the software crisis. Hitachi was the first company to formally brand a division "Software Works" around the idea, in 1969. AY did not coin this term and does not claim to.
What is back pressure in a software factory?+
Back pressure is the limit on how much autonomy a loop can be handed, set by how cheaply and reliably the output can be verified, not by how fast it can be generated. Generation capacity scales with compute. Verification capacity scales with how many reviewers and checks you actually have, which is why the queue backs up at the review gate, not at the generation step.
What is comprehension debt?+
Comprehension debt is the widening gap between how much code has shipped and how much of it a human on the team could actually explain. It accumulates quietly in a dark factory because tests stay green while the gap grows, and it does not fail loudly. It fails the day someone has to change the part nobody understood.
What earns a loop the right to run dark?+
A loop can run lights-out when the check is cheap enough to run on every attempt, the oracle is unfakeable (a type gate, a property test, a clean green or red signal), the loop is short before context drifts, and a wrong answer is cheap and reversible. Expensive verification, large blast radius, long-lived ambiguous work, and high cost of being wrong all argue for keeping it lit.
How does AY run a lit factory in production?+
Our internal /go build cycle is a graph of scoped agent loops (plan, build, review, test) with a human owning two checkpoints in the outer loop: approving the plan before any code is written, and reviewing the code before it merges. Everything between those two checkpoints runs closer to dark, fast and automated, with adversarial review looping back to the build step instead of rubber-stamping it.
Want the topology and mechanics of the agent graph running inside the factory? See Graph Engineering or the embedded engineers who build a lit factory inside your stack on Forward Deployed Engineers.