Day 1 · Lesson 3 of the series
Stop producing code. Start producing the system that produces code.
Lesson 2 gave you the machine, the harness one agent runs inside. Now zoom out to the whole floor. The factory model is a small sentence with a large consequence for how you spend your hours: your primary output is no longer code.
From Lesson 2: an agent misbehaves. Where do you look first?
The harness, most failures are configuration failures. Hold that: the harness is the machine. This lesson is the factory the machine sits in.
The mental model that ties every Day-1 transformation together: the developer's primary output is the system that produces code, not the code itself.1 A factory manager doesn't assemble every widget by hand. They design the assembly line and ensure quality control. The modern developer designs the development system and ensures its output meets the bar.
That system has five parts:1
SPECS & CONTEXT ─→ AGENTS ─→ TESTS & QUALITY GATES ─→ output
(what to build) (build it) (verify it) │
▲ │
└──────────── FEEDBACK LOOPS ◄── (failures routed back)┘
GUARDRAILS wrap the whole line (keep agents safe + predictable)One line decides whether your factory hums or jams: "Success comes from giving agents success criteria rather than step-by-step instructions, then letting them iterate."1 Step-by-step is hand-assembling widgets: you've just made yourself the bottleneck again. Criteria let the line run.
Make it concrete. Take a content pipeline (a factory you may already run). The same task, two ways to instruct the agent:
✗ Step-by-step — you're the assembly worker:
1. Open the draft.
2. Cut the intro to two sentences.
3. Add three bullets.
4. Move the CTA to the end. ...you babysit every widget.✓ Success criteria — you're the line designer:
# spec
Output: <= 600 words, brand voice (see voice.md), exactly one CTA.
Gate: readability eval >= 0.8 AND voice-match eval >= 0.85.
→ agent drafts, scores itself, iterates until both pass.You stopped editing widgets and started designing the line that edits them. That move (from instructing steps to specifying outcomes) is the whole shift, and it's why the bottleneck moves from writing to specifying and verifying.
These are three zoom levels of one system, not three separate topics:
FACTORY the system you build (specs · agents · gates · loops · guardrails) ← Lesson 3
└ HARNESS the machine each agent runs inside (the central machine) ← Lesson 2
└ DIAL how far right that machine pushes a task (verification) ← Lesson 1The factory is just the agentic end of the dial, institutionalised: success criteria = the tests/evals contract; quality gates = the verification; guardrails = the harness's hooks. Nothing new to memorise: it's the same ideas, named at the level of the whole line.
Quality gates are a build-time V Validation seed: they verify the widget before it leaves the line. But the factory says nothing about the running agents it deploys: who owns them (I), whether you can stop them live (R), or whether their actions are logged for audit (E). Those live above the factory, at the org.
Ladder read: a factory with enforced gates + named owners for what it ships can reach L3 Controlled for its outputs. Scaling to many factories without a shared inventory is exactly how L1 Unseen shadow agents breed, which is why the org lens (next) treats the factory as a shared, governed asset, not a private workshop.
Pick one repetitive workflow and make it your first factory, not your next script: define the spec + gate, let the agent iterate to criteria. Building one end-to-end teaches more than reading about a hundred.
Own the factory together: shared specs, gates, and feedback loops in the repo, so anyone's agent output is judged by the same line. Quality stops depending on who ran the agent. Judge work by the line, not the demo.
The biggest gains go to teams that build the factory once and refine it many times: shared specs, gates, and feedback loops compound across projects far more than any single shipped feature.
Recall, don't re-read.
In the factory model, the developer's primary output is —
The system: specs, agents, gates, feedback loops, guardrails. You design the line and guarantee its output. You don't hand-assemble each widget.
You get more from agents on the line by giving them —
Criteria + the freedom to iterate against a gate. Step-by-step makes you the bottleneck again; more context alone doesn't define what "done" means.
A factory's quality gates verify the output. What do they NOT give you?
Gates are build-time V Validation of the widget. Stopping a deployed agent live is Runtime Control (R), a governance pillar that sits above the factory, not inside it.
Catch yourself hand-editing an agent's output. Each time, ask: "what success criterion should the line enforce so I never edit this by hand again?" Then put it in the gate. That is the factory growing itself.
Addy Osmani's "The Factory Model" is the original and best articulation, he co-authored Day 1 and the metaphor is his.
Up next → Lesson 4: Context Engineering & Skills. The factory's first input. Six types of context, the static-vs-dynamic trade-off, and Skills as the pattern that lets one agent carry dozens of specialisms cheaply. (This is the bridge to Day 3.)
Related: Glossary: factory model · ← Lesson 2: The Harness · The Governance Layer · Course home