How to Build a Software Factory for One Product Repo
For AI startup founders · Based on Lou Bichard Software Factory Primitives Framework
// TL;DR
AI startup founders use the Software Factory Primitives Framework to build a real software factory for a single product repo — agents that take a spec, implement it, write tests, and reach a reviewable PR with minimal human involvement. The framework prescribes the Swarm pattern, decomposes the SDLC into gated micro-steps, and uses a CLI gateway so a local agent like Claude Code confirms each stage before proceeding. Context rot is the primary failure mode, and Harness Engineering is how founders keep agents flowing without babysitting every run.
What does a software factory look like for a single product repo?
For a startup, the dream is: hand an agent a spec, and it implements the feature, writes tests, and delivers a reviewable PR — with you on-the-loop, not driving each step. That's the Swarm pattern: one intent fans out to sub-agents, and results funnel back into a single PR.
But most founders confuse this with just running parallel agents while they orchestrate each one. That's NOT a software factory. A software factory is the commitment to incrementally moving yourself out of the loop, so work flows toward production autonomously. The framework's job is to get you there deliberately.
How do I decompose my SDLC so agents stop skipping steps?
The five-step SDLC (plan, build, test, review, deploy) is too coarse — agents don't respect the boxes and will skip straight to code. Decompose each stage into micro-steps:
- Plan: parse spec, identify components, write task list
- Build: scaffold, implement each component, integration
- Test: unit tests, integration tests, edge cases
Write these as an explicit sequence. This decomposition becomes the backbone of your coordination layer — the thing that keeps a lean agent honest without a lean team babysitting it.
How do I build coordination without hiring an infra team?
You don't need to reinvent orchestration. For a single repo, a CLI gateway is the leanest coordination form factor: a CLI tool your locally running agent (Claude Code, Cursor) invokes as a tool call to ask 'Have I completed this micro-step? May I proceed?' The gateway returns a pass/fail gate.
Make those gates machine-checkable — tests pass, lint clean, spec validated — not based on the agent's self-report. Agent sycophancy means agents will claim they wrote all the tests when they skipped some. As a founder shipping fast, false completion signals are the difference between a mergeable PR and silent tech debt.
Avoid reusing GitHub or Linear as your coordination layer — they'll bury your small team in noise.
Why will context rot be my biggest problem, and how do I beat it?
Context rot will be your primary failure mode. As the context window fills, the agent loses track of goals and skips steps — and it's the hardest part of building a software factory. The answer is Harness Engineering: run the agent, identify the exact micro-step where it drifts, and encode guardrails back into the repository via `agents.md`, skills, context files, and unit tests.
This compounds. Every time you fix a drift point in the repo, every future agent run benefits. For a startup with limited engineering hours, the repository doing the teaching is the highest-leverage investment you can make.
Start with the Runtime decision: threads or work trees are fine for simple stateless tasks early on, but move to a dev environment (VM) as tasks become real development work with security needs.
Next step: Pick your most repeatable feature type, decompose its SDLC into micro-steps, wire a CLI gateway with machine-checkable gates, and run five agent cycles — Harness Engineering each drift point back into the repo.
// FREQUENTLY ASKED QUESTIONS
Isn't running parallel Claude Code agents already a software factory?
No — if you're still orchestrating each agent, it's parallel-agent assistance, not a software factory. A software factory means incrementally removing yourself from the loop so work flows to a reviewable PR autonomously. The distinction matters because a real factory needs a coordination layer with gated micro-steps, not just more agents running at once with you driving each.
What's the leanest coordination layer for a single-repo startup?
A CLI gateway — a CLI tool your local agent invokes as a tool call to confirm it completed a micro-step and get permission to proceed. It's the lowest-overhead coordination form factor for a single repo, avoids the noise of reusing GitHub or Linear, and keeps gates machine-checkable so agent sycophancy doesn't produce false completion signals.
How do I handle context rot without a big engineering team?
Use Harness Engineering as a compounding loop: run the agent, find the exact micro-step where it drifts, and encode the fix back into the repo via agents.md, skills, context files, and unit tests. Each fix benefits every future run, so a small team gets outsized leverage — the repository itself does the work of keeping agents on track.