Two years ago, we were all working in an IDE, writing code, and quite happy doing it. About a year ago, Claude walked into the room and sat down next to us. We started pairing with it: guiding it, inspecting what it produced, iterating.
Then the next idea arrived. If an agent can write code while we watch, why do we need to watch? Why not let it run on its own?
That idea has a name now: the software factory. And I've been trying to build one for a while. Here is what I learned, mostly by getting it wrong.
Attempt one: duct tape
My first attempt, which I described as an agentic pipeline, was held together with duct tape. A small server ran headless Claude with one instruction: implement this GitHub issue and open a draft pull request.
It worked. If you give an LLM a job, it does the job. So it created pull requests. And more pull requests. And more.
The feedback from the team was immediate: do we really have to review all of this?
I had made one crucial mistake. I set it up under my own account. Every commit and every pull request carried my name, which made it look as if I was personally responsible for a flood of work that didn't match the team's standards, and that nobody had asked for. The engineers were frustrated, and fairly so. I was frustrated too, because I could see all this output just sitting there.
So I archived the experiment. Something that causes more frustration than it solves isn't worth much.
Big shocker: if a decision affects the team, you need the team.
Attempt two: same stone
A few weeks later, scheduled cloud agent sessions became available: a Claude session that runs on its own, with a set of instructions and connected tools, triggered on a schedule or by an API call. A good opportunity to revive the factory.
And the first thing I did was set it up under my own account. Again.
In Dutch we say a donkey doesn't hit the same stone twice. I did.
This time I fixed it properly. We created a shared service account for the agent sessions, with credentials in the team's password manager, and a separate bot account on GitHub. Pull requests now came from the bot, and everyone could see and change the setup.
But the underlying problem didn't go away. Same instructions, same pull requests, same frustration. The only difference was that everybody now had visibility.
The team takes over
Then something more interesting happened.
One engineer said he didn't like the output, and that the problem was the input. We needed a planning step that scoped the work properly before anything got built. He started building it.
Another, who had argued with me a lot about AI, said that if we really wanted this to work, we had to rethink our testing strategy. How else would we know that something works when it reaches production?
He was right. And that's when it clicked for me. The factory isn't something you install next to the team. It becomes an extension of the team. It encodes what the team believes: what good engineering means, what quality means, what we're not willing to ship.
What the factory looks like today
It's still not complicated. It starts with a GitHub issue, because I believe these systems only succeed if they live where people already work. Another tool or another inbox won't get adopted.
From there, three agent sessions run in sequence: implement, review and fix. The result is a pull request. GitHub Actions glue the steps together. All of it is infrastructure we already had.
The same goes for guardrails, everyone's favourite new word. We already had them: linting, static analysis and unit tests in the CI pipeline. Were they good enough? Not yet, as the testing debate made clear. But they were there, so we used them.
And because something is running on its own and making changes, you need to see what it does. Every time the bot picks up an issue, it starts a thread in Slack and posts its progress there. Combined with the issue and the pull request, you can always reconstruct what happened.
Some numbers so far: 59 pull requests created, and about half needed follow-up commits. That's far too many. I want that number much lower. An implementation run costs roughly $2.50, a review run around $0.50.
The most useful lesson came from showing generated pull requests to a room of engineers and asking for their gut reaction. The big ones, sixteen files with a wall of description, got a shrug at best. The small, focused one got a clear yes. You only find this out by running the thing, feeling the friction and iterating on the factory itself.
Where it goes next
Implement and review are the obvious steps. The more interesting ones come before and after.
Plan. Scope the work and stress-test the plan before an agent writes a line of code.
Test. Testing strategy becomes a team decision with real consequences. If your CI takes twenty minutes, every change waits twenty minutes. Which tests do you run, and where? Claude will happily aim for 100% coverage. Deciding what actually matters stays with the engineers.
Evals. When you switch models, you need a way to know whether your factory still produces good work. Gut feeling isn't a measurement.
Observe. Most teams treat their error tracker like the child in the room nobody talks to unless something breaks. I believe it becomes part of a maintenance loop: errors, logs and analytics flow into the planning step, and the factory picks them up. That makes it all the more important that your monitoring actually tells the truth.
On top of that sits a feedback loop for the factory itself. Merged and closed pull requests, review comments, failure traces and eval results all tell you how to improve it. And the more context the factory can draw on, the better it gets.
A dim factory, not a dark one
Some people talk about the dark software factory, borrowing from the dark factories in manufacturing, where robots run the plant and nobody bothers to turn on the lights.
I don't believe in that for software. What I see is a dim factory. It mostly runs on its own, but every now and then someone needs to turn on the lights to clean up, fix something or adjust the line.
It's also not a replacement for the team. We went from text editors to IDEs to pairing with an LLM. The software factory is the next tool in that line. We're expanding the toolkit, not replacing the team.
Engineering on two levels
That leaves engineers working on two levels.
Locally, you still pair with an agent on the hard things: the complex feature, the architectural decision with real impact. Meanwhile, the factory takes the stream of small changes. The button that should move three pixels. The document that should be landscape, no, portrait, no, with wider columns. You write a good issue, and you stop caring about it. If a column ends up slightly wider than intended, who cares? It's out.
Work moves between the two. You take a big feature, cut it into pieces, hand three of them to the factory and keep the fourth for yourself because it's where the real decision is.
And above both levels, the job moves towards the problem. If implementation is no longer the work, engineers need to be in the room where problems get understood. We have built whole roles to gatekeep that space. Engineering needs to take part of it back. It also means being ready for the product manager who walks in with a working prototype and wants to put it in production. Your factory should decide, safely, which experiments can run and which can't.
Every team will build a different factory. A team building a medical device will have far stricter guardrails than a team shipping a marketing site. The factory becomes the written-down definition of what your team believes good engineering is.
Start small, but start
Trust is the hard part. We already accept small factories today: bots that open pull requests to update dependencies or patch security issues. Once they proved valuable and reliable enough, nobody worried about them anymore. A software factory earns trust the same way: start with low-risk work, prove it, then hand it bigger tasks.
But somebody has to start. Waiting for a vendor to ship the complete system means losing the time you need to learn. The people who got good at searching the web were the ones who put up with terrible search engines early on. This is the same.
Building the factory is part of the job now. You can be unhappy about that. But if you don't do it, someone else will. Either they'll push it onto your team and you won't like the result, or a competitor will simply iterate faster than you.
So own the factory. Before someone else does.
