The participation gap
The software factory is just the latest incarnation of spec-driven development. The spec keeps getting smarter. The people who own the problem keep getting left out.
There’s a gap between operationalising the business and actually solving real problems. And lately we keep filling that gap with more practice, and calling it progress.
The latest bit of practice to fill it is the software factory. Specs go in one end, agents work the line, and pull requests come out the other. It’s a great pitch. It’s also not new.
The software factory is spec-driven development, again
Every few years we rediscover the same promise: if you can just write the spec precisely enough, the software will follow.
- 1970s →
Requirements documents
Write it all down up front, throw it over the wall, wait.
- Spec
- 1 out of 5
- Room
- 5 out of 5
- 2004
Model-driven development
Draw the models and generate the code. Microsoft literally called its version "Software Factories": see Jack Greenfield's The Case for Software Factories.
- Spec
- 2 out of 5
- Room
- 3 out of 5
- 2006
Behaviour-driven development
Write the spec in near-English so the business can read it, then make it executable.
- Spec
- 3 out of 5
- Room
- 4 out of 5
- 2025
Spec-driven development with AI
Write the spec, and let an agent turn it into a plan, tasks and code.
- Spec
- 4 out of 5
- Room
- 2 out of 5
- 2026You are here
The software factory
Spec-driven development with an assembly line of agents behind it.
- Spec
- 5 out of 5
- Room
- 1 out of 5
Each incarnation is genuinely better than the last. The specs are richer, the generation is smarter, and the feedback loop is faster. The software factory is the most capable version yet.
But look at what keeps happening to the spec. Each generation, it gets more precise, more technical, and more owned by engineering.
The spec drifts away from the people who own the problem
Spec-driven development is only as good as the spec, and the spec is only as good as the people who can take part in writing it.
Hand a modern spec to a product owner, someone in finance, or the person who actually owns the business outcome. Most of them can’t read it, can’t contribute to it, and so they quietly opt out. Not because they don’t care, but because the practice wasn’t built with them in mind.
So if the spec drifts away from the people who own the problem, who owns it now?
Engineering, mostly by default. Whoever can write the spec ends up deciding what the problem is. And more and more, it isn’t even the engineer. It’s the agent, filling the gaps the engineer left with whatever context it was given.
Nobody decided that. It happened one sensible tooling choice at a time.
That’s when the strange stuff starts:
- Engineers spec the problems they can see, which is how you end up with a dozen cost calculator agents.
- Committees form, because nobody outside engineering can follow what’s going on.
- Adoption becomes a number on a dashboard instead of a change in how the business runs.
Where the agentic platform fits
An agentic engineering platform solves a different problem. Context, tools, permissions, guardrails, evals and a human in the loop give non-deterministic workers a safe place to work. It solves trust.
Software factory
Solves throughput
- Specs in, pull requests out
- Agents working the line
- Faster feedback loops
Agentic platform
Solves trust
- Context, tools and permissions
- Guardrails and evals
- A human in the loop
That matters, and a factory without one is a liability. But notice that a platform doesn’t fix the spec either. A well-governed agent faithfully building the wrong thing is still building the wrong thing.
Participation is the real constraint
The bottleneck isn’t the tooling. It’s who can take part.
If product can’t write the intent, and the business can’t say what success looks like, no factory or platform is going to fix that for you. You’ll just get faster at building the wrong thing. AI doesn’t fix broken workflows; it accelerates the ones you’ve got.
So the question isn’t “platform or factory?” It’s “who needs to be in the room for this to solve a real problem, and can they actually take part?”
Where everyone else takes part
If engineering owns the factory and the platform, where does everyone else come in? Not in the spec syntax, the code or the pipeline. They come in at the moments where judgement about the business matters more than judgement about the build:
Framing the problem
Who: ProductBusiness owner
Say what problem is worth solving, for whom, and why now. That’s the intent.
Supplying the context
Who: OpsSupportFinanceDomain experts
Explain how the work really happens today: the edge cases, the workarounds, the data nobody wrote down. Agents are only as good as this part, and it lives almost entirely outside engineering.
Setting the constraints
Who: LegalSecurityRiskFinance
Set the boundaries: what can’t happen, what it can cost, what has to be auditable.
Defining success
Who: Business owner
Say what “done” looks like in their terms. That becomes the acceptance criteria, and eventually the evals the agents are measured against.
Reviewing the outcome
Who: Domain experts
Not code review. Outcome review: does this actually do the job? A domain expert at the right checkpoint catches more than any test suite.
Feeding back after it ships
Who: SupportOpsCustomers
Tell you what really happened, and that becomes the context for the next piece of work.
None of that needs anyone to learn what a harness is. It needs a place for each of those people to put their knowledge, in their own language, at the right moment.
Closing the gap
A few things that, in my experience, actually help:
- Start from the problem and the outcome, not the practice. Pick the business result first, then decide how much machinery it needs.
- Split the spec in two. Keep the part the business owns in plain language: the intent, context, constraints and success they bring above. That’s what a Work Pack is for. Let engineering and the agents own the executable detail underneath it.
- Keep the machinery below the line. Most participants should never need to know what a harness is. The factory and the platform are for engineering to run, not for everyone else to learn.
- Measure what the business recognises. Lead time on a real outcome beats prompts per week every time.
Above the line · owned by the business, in plain language
- Intent
- The problem, for whom, and why now.
- Context
- How the work really happens today.
- Constraints
- What can’t happen, and what it can cost.
- Success
- What done looks like, in their terms.
The line
Below the line · run by engineering and the agents
- Executable spec
- Plans, tasks and acceptance tests.
- The factory
- Agents working the line.
- The platform
- Permissions, guardrails and evals.
- The harness
- Nobody above the line needs the word.
Final thought
We’ve been building software factories for twenty years. Every time, the spec gets smarter and the room gets smaller. If the people who own the problem can’t take part in the spec, you haven’t operationalised the business. You’ve just automated engineering’s guess at it.