If nobody on your team can explain what your "software factory" shipped, you don't have a factory.
You have a slot machine.
The Throughput Pitch
"Software factory" is having a moment. Every second video in my feed is someone's agent pipeline shipping hundreds of pull requests a week.
I like the idea. I build these things myself. I've written about what Stripe's Minions teach us and I think the direction is right.
But here's what bugs me. The pitch is always throughput. PRs per week. Tickets closed. Hours saved.
Almost nobody talks about who owns what comes out the other end.
It's Yours at 2am
When something falls over at 2am, nobody cares that an agent wrote it. The customer doesn't care. Your on-call engineer doesn't care. Your boss definitely doesn't care.
It's yours.
That's not a new rule. It's the same rule that applied when a contractor wrote the code, or a junior, or a library you pulled in without reading. Shipping it means owning it. Agents don't change that. They just make it much easier to ship things you don't understand.
What a Pipeline Needs Before It Deserves the Name
A real factory has quality control. Here's what I'd want in place before I'd call an agent pipeline a factory:
- A written definition of correct, before the agent starts. Not a vague ticket. Something specific enough that you could check the output against it.
- Checks the agent can't talk its way past. Tests, type checks, and a fresh reviewer session that didn't write the code. Agents are very good at explaining why their work is fine. Make them pass something that doesn't listen to explanations.
- Reports a human can actually judge. Screenshots, diagrams, test output. Not 3,000 lines of diff that nobody reads and everybody approves.
- A named person who can explain and defend every change that ships. One name per change. If nobody can explain it, it doesn't ship.
The second point is where most pipelines are weakest. A model reviewing its own work mostly agrees with itself, which is why I always use a fresh session for review.
Discipline First, Then Automate
Automating a discipline is great. If your team already writes specs, tests properly and reviews carefully, agents can multiply that.
Automating instead of a discipline is a liability with a nice dashboard.
This is the same line I drew in agentic coding vs vibe coding. The tools are the same. The difference is whether someone is actually engineering.
Engineering leads, a straight question: who on your team owns the output of your agents? By name.
For the bigger picture, see what agentic software engineering looks like in practice. I also post about this most weeks on LinkedIn.