What is the hype with Software Factories?

I have been hearing about software factories left and right with different opinions over the past few months. I have always given people the benefit of doubt and I like to think that I am able to keep an open enough mind to see how people are deriving value from doing things in this way.

The most useful Google search I came across was this well written article from Cloudflare: https://blog.cloudflare.com/astro-issue-triage/ in which they describe how they set up an entire workflow to close a huge backlog of their Github issues. So I gave it a shot.

What is a Software Factory anyway?

The way I understand it, at the core it is a piece of automation (more precisely involving coordination of coding agents like Pi) that is purposefully designed to solve one type of problem and at scale. Let me elaborate.

In the age of AI you will very often encounter situations where you might be overwhelmed by a set of tasks. In Cloudflare’s example that was Github issues (huge number of them at scale) and in my case, quite similarly, was fixing issues of kcap desktop https://github.com/kurrent-io/kcap-cli for Windows users.

So in short:

1. Huge set of standard tasks (input e.g. Github issues)
2. Goes into an automation/workflow involve coding agents
3. Outcome (issue closed for example)

And usually a factory is specialized at solving one type of problem. At the end of the day it’s just a programming paradigm.

The Simplest Software Factory

I use kcap desktop as my harness where I can orchestrate multiple different flavors of coding agents. The simplest factory that I could think about was to just create a workflow that runs in Claude Code and it goes like this:

1. Pick up Github issue
2. Plan
3. Implement
4. Build
5. Verify
6. Ship PR and Close Github Issue

This is what the control plane (inventing a term here) looks like for your factory and I think the flow is self explanatory. The build and verify go back and forth and the rest is obvious. This whole workflow runs with multiple sub-agents.

Is that it? Can I go have my margerita now? No, here are the not-so-obvious challenges! (or may be they are obvious?)

Compute Bottleneck

I quickly realised that I needed to limit the number of sub-agents working on the Github issues. How did I realise that? By the sound of laptop fan first actually and then by clicking to see what the workflow was doing. This one is easy you can just prompt to say use a maximum of 5 agents.

Get Lougarou’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

(Not so interesting the next bottleneck was actually running builds with multiple threads, every sub-agent wanted to do that, I had to make the builds single-threaded)

CI Bottleneck

If you have not yet experienced the CI bottleneck, running software factories is a shortcut to experience that. Imagine 100 github issues, 100 PRs, every push running on CI. It’s a disaster and you will end up waiting for every run. In our case, one run takes about 30 minutes and this is unacceptable.

So I modified the workflow to categorise by types of issues, then build and fix in the same branch. I thought this might cause at the verification step and it did. We use CodeRabbit for review but it was limited to 300 files max, thankfully we didn’t quite hit it but I imagine this could turn out bad.

It was worth it in the end, instead of a 100 PRs it was 5 PRs. CI is happy.

Observability Bottleneck

Ok the sub-agents are running, you see something like the picture below

It doesn’t say much right? what you need is a data plane, capturing everything happening including everything from sub-agents not only the main orchestrator agent.

This is where kcap.ai really shines, it is already capturing all the transcripts, tool calls, PR status and all other activity on my laptop and that of my colleagues.

The way I used to track the status of the run was to tell kcap to update a page with the status of every task. This is another feature in kcap btw and it looks like the following:

Not a full picture but this is what I was looking at and it was super helpful.

Durable Bottleneck

Not really a bottleneck but what the heck, it adds uniformity to the article. We were keeping track of the run in Plans, locally but also because we had a data plane available it was really easy for a failed/crashed sub-agent to just pick work back up. I know many of you run managed agents but so far I have only been using agents on my machine and they often fail. In my run it actually failed once because of disk space, it was not a big issue because I was using the team tier and my transcripts were in cloud.

Verdict

It actually turned out well. I never thought I would close so many issues so fast, I re-run the huge test bench that we had run to discover all those bugs and it turned out that we really did fix all these issues.

So I get it, using software factory pattern is a valid method of doing things. This is probably nothing new and is probably being used by companies for marketing purposes.

But it doesn’t matter, as the average software engineer we have to step back and see impartially if we can merit from it.