Stop calling it a “software factory”. AI did not turn software development into mass production. It gave skilled people better tools, and that makes it a workshop.
The term “software factory” is old. It came up decades ago, when people hoped to build software like cars on an assembly line. Now it is back. Every week I see a new “AI software factory”: agents in a pipeline, requirements go in, code comes out. It sounds modern and efficient. But it is the wrong picture, and the wrong picture leads to wrong decisions.
Factories copy. We design.
A factory is built to make the same product again and again. The design is finished before production starts. The goal is to remove variation, and the workers follow a fixed process. You can replace them without changing the result.
Software is the opposite. We never build the same system twice. If we need the same system again, we copy it, and copying software costs nothing. Every project has a different domain, different users and different rules. Most of the work is understanding the problem and designing a solution.
I never liked the factory picture in DevOps either. For years, people have called the CI/CD pipeline a “software factory”. But a pipeline does not design anything. It is automation, a very useful machine in the workshop, built and maintained by skilled people. And AI does not change this. What AI changes is writing the code, and that was never factory work.
A workshop, not a factory
A workshop is a better picture. In a workshop you find skilled people, good tools and custom work. Each piece is made for a specific customer and a specific need.
With AI, the roles are clear:
- The agent is the tool. A very powerful tool that works autonomously, but still a tool. It does not know what to build, and it does not care if the result is right.
- The spec is the plan. The domain experts write it. It describes what the business needs, in enough detail that the tool can do its job.
- The software engineer is the craftsman. The craftsman designs the architecture, works with the domain experts until the spec is clear, builds the harness the agents work in, checks the work and takes responsibility for the result.
A better tool makes a good craftsman faster. It does not make the craftsman unnecessary. A carpenter with a power saw still needs to know where to cut.
Santa’s workshop
If you want one picture for AI development, take Santa’s workshop. It is a workshop that has to deliver a lot of custom work on a hard deadline, and it works with many helpers. Thanks to James Ward for crafting this analogy.
| Santa’s workshop | AI development |
|---|---|
| Children | Domain experts |
| Wish list | Spec |
| Santa | Orchestrator |
| Elves | Agents |
| Checking the list twice | Review and tests |
Santa does not build every toy himself. He plans, splits the work, gives each elf a clear task and checks the result. The elves are fast, and there are many of them. They work in parallel and on their own, without Santa looking over their shoulder.
That last point is the important one. Santa does not write the wish list. The children do, because only they know what they want. The elves do not know the children. They only know the wish list. Everything they build comes from it.
Socks instead of a bike
A vague wish list gives you socks instead of a bike.
If the list says “something warm, maybe blue?”, the elves will build something. It will be warm, and maybe blue. It will not be what the child wanted. If the list says “red bicycle, 20 inch wheels, front and rear brakes, for a 10 year old”, the elves can build exactly that.
Agents work the same way. Give an agent a one-line prompt and it fills the gaps with guesses. The guesses look good, the code compiles, and the demo works. But the business rules are wrong, the edge cases are missing, and nobody notices until it is in production.
A good spec answers the questions the agent would otherwise guess:
- Who uses the feature, and what is their goal?
- What is the main flow, step by step?
- What are the alternative flows and the errors?
- Which business rules apply?
- What does the data look like?
- How do we know it works?
This is not new. It is classic requirements engineering. In the AI Unified Process, the wish list consists of use cases and an entity model. The use cases describe the flows and the business rules. The entity model describes the data. What is new is that the spec is no longer a document that nobody reads. The agent reads it, every time. A better spec gives you better code. Write better specs.
The craftsman is responsible for the harness
The spec alone is not enough. Around the agent you need a harness: the environment the agent works in, with the rules it must follow and the checks its work must pass. And the craftsman is responsible for it, not the tool.
The harness includes:
- The spec, written by the domain experts, with use cases, business rules and the data model. The software engineer makes sure it is complete enough for the agents
- The architecture and conventions, so every agent builds the same way
- The context, so the agent knows the project, the stack and the decisions already made
- Automated tests, derived from the spec, that fail when the agent is wrong
- Review, by a human who understands the domain
- Traceability, from requirement to use case to code to test
In a factory, quality comes from the process. Nobody on the line is responsible for the whole product. In a workshop, the craftsman signs the work. If the agent builds the wrong thing, it is not the agent’s fault. The plan was unclear, or nobody checked.
This is what I mean by Spec-Driven Development, and it is the idea behind the AI Unified Process. The spec is the source of truth, the agent does the implementation, and the software engineer owns the harness that keeps both aligned.
Conclusion
Words shape how we think. If we call it a factory, we look for a process that removes people. If we call it a workshop, we invest in people, their skills and their tools.
AI makes the tools much more powerful. That is good news for every software engineer who knows what to build and how to check it. So stop building factories. Build a good workshop, help the domain experts write a clear wish list, and own the harness.
Even Santa checks the list twice.
