Skip to content

Software Factory

Metaphor — borrowed from physical manufacturing — for a codebase + infrastructure + agent-fleet setup where software production runs semi-autonomously. Zakariasson's framing at AI Engineer 2026.

The image

"Look at real-life factories producing hardware. There's a lot of assembly lines. There's a lot of people that goes into this, a lot of managing, observability and all that. There's a lot of concepts we can borrow from that world and put into the software world."

The factory produces code the way a real factory produces cars: assembly lines (pipelines), guardrails, verification stations, supervisors, and eventually a "dark factory" (Dan Shapiro's term) where the floor runs largely unattended.

Four components

  1. Primitives & patterns — modular codebase, colocated code, consistent startup/test/auth conventions. Agent-friendly = onboarding-friendly. package.json start scripts are "so in-distribution" that agents self-orient immediately.
  2. Guardrails — hooks blocking sensitive paths (auth, encryption), emergent-cursor-rules that form as you observe failure, tests the agent can self-verify against.
  3. Enablers — skills/MCPs that expand agent capability (e.g. an "add feature flag" skill so agents ship gated PRs autonomously), external context (Linear, Notion, Datadog, Slack), ability to spawn full dev environment.
  4. Verifiable systems — the underappreciated one. Agents need to check their own work — unit tests, integration tests, UI tests clicking around the DOM. Backend easy (clear contracts), UI hard (requires computer-use verification).

Why build one

  • Throughput — agents run 24/7, don't sleep.
  • Consistent output — assembly lines produce predictable artifacts if wired right. Without guardrails, agents feel probabilistic and drift.
  • Taste leverage — human creative input gets amplified rather than bottlenecked by typing speed.

Running vs building

Once built, the job is manager, not worker: look less at code, aggregate agent outputs, catch off-rails behavior, feed the deviations back into rules/skills (the flywheel).

Scaling means nested management — "you still have a small team, then add more people because you need throughput, then need a manager, then a manager of the manager. Same with agents — you just keep going up levels of abstraction."

Cross-references