What is a software factory? From DevSecOps pipelines to agentic factories, and the discovery gap

A software factory is an organized system for producing software at scale. Today the phrase usually means a DevSecOps delivery pipeline, an outsourced delivery center, or an AI-agent pipeline that turns specs into tested, deployed code.

The agentic version speeds up the build, and it still depends on discovery, decisions and shared context upstream. A software factory can turn a good spec into shipped code quickly. It can't tell you whether the spec was worth writing.

Search "software factory" and you get three different answers depending on who is writing.

Three meanings of "software factory"

All three share the factory metaphor: specialize the steps, standardize the inputs, and raise throughput. They differ on what is automated and where the process starts.

A short history

The industrial metaphor dates back decades: software treated like a manufacturing line, with reusable components, shared standards, and a production system instead of one-off craft projects.

More recently the phrase reappeared in DevSecOps, including at the U.S. Department of Defense, whose DevSecOps guidance defines a software factory as "a collection of people, tools, and processes that enables teams to continuously deliver value by deploying software to meet the needs of a specific community of end users." A critical part of it is the CI/CD pipeline, which automates develop, build, test, release and deliver. That meaning is still in use, and it describes a delivery pipeline rather than an AI coding pipeline.

A third, commercial meaning treats a software factory as an outsourced or nearshore delivery center: a dedicated team that builds to a client's backlog. That usage shows up in agency and SI marketing and describes how a team is organized rather than a technology.

The newest meaning is the agentic software factory: agents plan, write, test and ship against a written input, inside guardrails. The rest of this post covers that meaning, because it is the one that reaches into product work.

The agentic (AI) software factory: spec in, code out

An AI software factory follows a common pattern. A well-formed input goes in. That input is usually a spec, a ticket with acceptance criteria, or a "signal" that has already been turned into intent. Agents then:

1. Plan against the input and house standards
2. Implement in the repo
3. Generate or run tests
4. Open a pull request or push through a deployment path
5. Loop on failures until checks pass or a human steps in

Humans set policy, approve risky changes and own the outcome. Agents do more of the execution. The factory executes and people steer, so its output is only as clear as the direction it gets.

Once intent is clear, the factory takes over the build half of the lifecycle. With good input, the pattern works for delivery. For product teams, the open question is what the factory assumes is already done.

What a factory needs as input

An agentic factory is only as good as what you feed it. In practice it needs:

• A decision. What are we building, and what are we explicitly not building?
• Evidence behind that decision. Customer signal, constraint, risk, or prior learning that justifies the bet.
• Constraints. Compliance, architecture boundaries, performance budgets, brand and accessibility rules.
• Acceptance checks. How will we know it worked, covering product intent as well as unit tests?
• Scoped context. Enough background for an agent to act without inventing the missing "why".

A ticket that says "add invoice export" leaves all of that out. The same work as a short decision brief (illustrative, made up):

The brief gives the factory the problem, the constraints and the definition of done before it starts. Spec-driven development is how that decision becomes executable; see our guide to spec-driven development for product teams.

The discovery gap

In the factory write-ups we've read, the process starts at the spec (or at a signal that is treated as already-understood intent). Factories assume someone has already:

• discovered the problem,
• negotiated the trade-offs across stakeholders,
• chosen a solution approach, and
• written that down so agents and other teams can use it.

In a small product team, a founder or lead can hold that in their head and type a good spec. In an enterprise, discovery and solutioning are spread across product, design, engineering, compliance, security and other teams. Teams negotiate the "business intent" a factory needs, often slowly, and often record it incompletely.

We call this the discovery gap, the distance between what the organization must decide before a build and what the factory receives. Cheaper builds leave the gap the same size and make it easier to see, because thin or contradictory intent now turns into thin or contradictory software faster.

Our pillar post explains why the AI SDLC is really a product lifecycle, with deciding what to build as the new bottleneck.

Enterprise view: many factories, many teams

At enterprise scale you rarely have one factory. You have several teams, several repos, several agent setups and several backlogs. Each can look productive in isolation, and they share one problem, context:

• Decisions live in meetings and slide decks
• Constraints live in chat threads and wikis
• Requirements live in tickets
• Standards live in rule files some agents never see

Each agent and each team sees a different slice, and faster factories ship on those mismatched slices faster. We cover that failure mode in the agentic SDLC and the enterprise context gap. For the task-level version of giving agents product context, see how to give AI coding agents product context.

Checklist: is your org ready to feed a software factory?

Use this as a readiness check.

1. Can you point to a recorded decision (problem, approach, non-goals) for the next feature an agent will build?
2. Can you trace that decision back to evidence as well as a stakeholder request?
3. Are constraints (compliance, architecture, accessibility) attached to the work, not buried in another tool?
4. Do acceptance checks cover product intent as well as technical correctness?
5. Is there a single place agents and humans read current context, with an owner and a freshness rule?
6. Do repo rule files encode standards agents must follow? (See AGENTS.md vs CLAUDE.md.)
7. When two teams touch the same feature, do they share the same decision brief, or two different tickets?

If most answers are no, a factory will raise throughput on unclear intent.

Failure modes

• Building the wrong thing faster. Throughput without discovery quality compounds waste.
• Spec drift. The written spec diverges from the latest decision, and agents faithfully implement yesterday's intent.
• Context locked in tools. The factory can read the repo and the ticket, but not the design comment, the legal email or the architecture decision record.
• Review bottleneck. Agents produce more than humans can verify against original intent.
• Local optima. Each team's factory optimizes its backlog while the cross-team product outcome gets worse.

Where SteerFlow fits

Picture the factory as a line: decisions enter on the left, code leaves on the right. Agents run the right-hand side. SteerFlow is designed for the left-hand side, the product context layer that feeds the line, so the people steering can hand agents a complete brief instead of a thin ticket. It is designed to capture discovery and decisions as first-class records, turn them into specs agents can act on, and keep that context attached as work moves across teams. If the discovery gap is the part of the factory you feel most, we'd be glad to hear from you. Get in touch.