A Blueprint for an Ideal Software Factory
A practical blueprint for AI software factories: spec-first pipelines, durable artifacts, human-in-the-loop gates, and portable context for scalable AI-driven software development.
In my recent posts I laid out the framework for thinking about software factories and reviewed sixteen of them. I ended up with a question: what should an ideal software factory look like? And will it scale for the next 3-5 years?
My opinion is based on research and on my experience building a small internal software factory. That is where my conviction comes from, but it is likely also the source of some bias.
Please note that software factory is a newly emerging term for this product category. It’s not universally adopted across the industry, but I like it and I’ll use it instead of my previous orchestrator term.
The developer flow
I want to start with the developer experience that a software factory should enable.
It starts in the inner loop, where a developer shapes the requirements, spec, and architecture with a local agent. Once that is solid, the factory takes over: planning, implementation, audits, and the PR at the end. Then the work often returns to the inner loop for small fixes or final polish—typically on larger or UI-heavy tickets (small tickets can merge right in).
However, not every task starts locally. A bug may arrive from Slack, Jira/Linear, or an alert. Some factory tasks come from recurring jobs (eg, check observability for errors, look for dependencies to upgrade, etc).
Every ticket ends in one of two ways. If the factory clears its audits and gates, it opens a PR—or merges it when policy allows. If it is uncertain, needs missing input, or wants to change protected code, it pauses and contacts the developer through Slack, email, or the factory UI with the exact question or approval it needs. Once the developer responds, the run resumes from the same state.
Capabilities a factory must support
Here is a practical breakdown of the core capabilities.
Take work from anywhere. A local spec, a Slack thread, Jira/Linear, or a monitor firing from logs and traces. Whatever the source, the factory converts the raw input into the first formal requirements artifact before the pipeline proceeds.
Run recurring work. Security drift, performance regressions, user-feedback triage, etc are just some examples of workflows triggered by a schedule instead of a ticket.
Keep the full task context together. Requirements, plans, review findings, and human decisions should be readable in one place and loadable into the inner loop.
Make execution explicit and durable. Stages, state, gates, retries, and resumptions should be visible. The LLM work is non-deterministic, but the workflow around it should not be mysterious.
Escalate by risk and uncertainty. Protected code, low confidence, incomplete requirements, and custom policies can all justify human-in-the-loop (HITL) intervention.
Make disagreement cheap. When a developer rejects an LLM architecture choice or review finding, the fix should be an quick human-factory exchange followed by the factory resuming the ticket run.
Send work backward. If implementation exposes a requirements gap, the factory should return the task upstream with a reason, repair the artifact, and continue from that stage.
Learn from history. Dismissed findings, disputed decisions, and stalled runs should produce concrete suggestions for improving skills and repository instructions: “this review skill over-produces findings here,” or “the repository guidance no longer matches the architecture.”
Move cleanly between inner and outer loops. A developer should be able to hand work off and pull it back without rebuilding context.
Together, these requirements point toward a spec-first pipeline: durable artifacts crossing explicit boundaries, with configurable HITL between them. Here’s what that architecture looks like.
The architecture
Linear by default, limited DAG when justified
Mature factories are converging on explicit pipeline stages with LLM calls inside them. Not one agent wandering freely from intent to PR.
Most of these pipelines should be linear. Requirements feed architecture, architecture feeds a plan, and a plan feeds implementation. A general-purpose DAG adds authoring and debugging complexity that most teams will not use. Specialized software should be opinionated; exposing every topology primitive pushes complexity onto the adopter.
That said, a sophisticated campaign loop (running multi-week projects) can call for a limited DAG:
Fan-out and fan-in: test several root-cause hypotheses or architecture options, or apply the same migration pipeline across many files.
Work dependencies: sequence related workstreams inside a large project plan. This is typically more of a tree where tasks depend on each other.
The factory should support those cases without turning into Airflow.
Spec-first pipeline stages
The factory should map the team’s spec-first workflow directly into pipeline stages, with each spec stage becoming one pipeline stage.
Any sensible spec-first flow can work. I use this one and will use it as a reference for this post.
requirements → architecture → plan → implement → code review
Each stage produces a durable artifact for the next. Spec Kit uses four stages, Kiro three, Microsoft seven. The exact count matters less than the contract between them.
The spec guides the run. After merge, the code becomes canonical and the spec becomes a historical record of how the code got there.
Inside a stage: audit, fix, escalate
However, stages are a bit more sophisticated than they seem. Every stage can be configured to run a loop - run the skill (plan, implement, etc), audit the output, fix what the agent can resolve confidently, and escalate the rest.
Complex artifacts may deserve several reviewers or audit passes, just as a design document may go through several human reviews. The factory should make the number of passes, prompts, roles, and models configurable.
HITL should support four forms:
Uncertainty-driven: low confidence or incomplete requirements.
Fixed gate: a stage always pauses for review.
Hook-driven: adopter-written checks can block progress.
Declarative policy: paths or owners require approval.
Declarative protected-code rules are especially useful in structured repositories. They are similar to GitHub’s CODEOWNERS. They can be implemented through hooks, but I want to bring them to the forefront because they are a practical way to manage risk. For example, authentication, security, and database migrations may stay human-gated indefinitely while other paths are auto-merged.
Escalation can also send work backward across stages. If implementation finds a requirements gap, it returns the task to requirements with an explanation. The artifact is revised and the pipeline runs forward again through the same gates. That is better than improvising or failing the run, and because the transition is explicit, it is fully auditable.
Stage contract: formal artifacts only
So how do the stages communicate with each other? Only the completed artifact—whether a document, code change, branch, or PR—crosses a stage boundary. Not the full conversation, partial drafts, or failed audit attempts.
That keeps context bounded because intermittent state is discarded between stages. It also makes inner/outer-loop handoff portable, allows the pipeline to resume from the last completed stage, and gives humans something readable and diffable. A person can reject one artifact without replaying the entire conversation that produced it.
Spec Kit’s constitution.md → plan.md → tasks.md and Kiro’s requirements.md → design.md → tasks.md are file-level versions of the same contract.
Skills implement stages
A stage typically contains at least two skills: a main skill that creates the artifact and a review skill that audits it. In the plan stage, those might be create plan and review plan. In the implementation stage, they are implement and code review.
The artifact can be a document, code change, branch, or PR. The rule is the same: the main skill produces it, the review skill evaluates it, and the stage emits one completed artifact across the boundary.
Inside those skills, anything goes: parallel agents, adversarial verification, multi-model consensus, or deterministic post-processing. A code review skill, for example, might run parallel security, quality, and architecture reviewers, followed by an adversarial pass and synthesis. Nine agents inside, one findings artifact outside. Stage-internal complexity is normal; it just should not leak into the outer workflow unnecessarily.
This also means that a developer can run the same pipeline locally by invoking each skill manually.
The factory owns its ticket
Every task gets a factory ticket, regardless of where it came from. Requirements, plans, findings, audit entries, and HITL decisions attach to it.
Many valid tasks—the Slack bug, an alert, an ad-hoc cleanup—have no external ticket and should not be forced to create one. When an external Jira or Linear ticket does exist, the factory treats it as input and uses its context to produce stage artifacts on the factory ticket. This avoids mirroring every intermediate artifact back into the external system.
The factory should expose ticket context through MCP, an API, or its own CLI. The mechanism is secondary. The requirement is that a developer—or another agent—can load the complete task outside the factory.
The PR is the other important artifact. CI failures return the task to implementation, PR comments become new factory input, and merges remain human-controlled where required.
This design produces the audit trail almost automatically: every artifact, approval, dismissal, and timestamp is attached to the same ticket.
A proprietary harness is fine. A closed one isn’t.
I started this research convinced the factory had to run the same agent harness developers use locally (eg, claude code, codex, etc). I was wrong.
A proprietary harness may be better in the outer loop. The vendor can optimize context retrieval, model routing, retries, audit, and long-running execution as one system. The problem is not a proprietary harness. It is a closed one.
The minimum bar is portable skills and artifacts, and complete context accessible outside the product. A developer must be able to write a spec in the inner loop, hand it to the factory, then pull back the branch and every relevant decision. Using Claude Code or Codex is useful when available, but not mandatory.
Price changed my view too. I expected proprietary orchestration to carry a huge premium. From the public pricing I could find, a factory with BYOK lands near raw agent costs at team scale—not an order of magnitude above them.
Why this scales as models improve
This is the million dollar question. Will this scale as LLMs get better and better? Or will advanced LLMs make this scaffolding obsolete?
I believe that this will scale as models get better. Model-dependent pieces remain replaceable: models themselves, skills, and state. The pipeline does not encode or rely on any specific model behavior.
The pipeline encodes organizational thinking: trust boundaries, audit requirements, ownership, and acceptable blast radius. Better models do not change those.
However, better models will produce better output, handle larger tasks, and move through the same architecture with fewer audit failures, escalations, and send-backs.
Even a perfect implementation model does not remove the need to approve a high-stakes spec, retain an audit trail, or control who merges protected code. Those requirements come from an accountability framework, not model capability.
So with better LLM model, this will scale by being able to tackle larger tasks with higher quality.
I don’t expect every factory to look exactly like this, but I do think these are the factory aspects that teams should consider.
The software factory market is still nascent. Even the term itself is not universal, and the products on the market are quite different from one another. I hope this gives you a concrete way to evaluate them and choose the best fit for your needs.