The Software Factory and the Inevitability of Recursively Self-Improving Software
Loading article…
Pull for previous story
I’ve been working this year towards building a software factory for InfluxDB, the time series database I’ve spent the last 13 years working on. I’ve referred to this software factory effort as building the machine that builds the machine. If you’re not familiar with the phrase software factory, what I’m referring to is a running software system that continuously builds improvements (bug fixes, features, performance enhancements) for the product we sell to customers, which is InfluxDB. So far, most of my focus has been on building elaborate test and verification infrastructure that agents can use to validate software changes. Which, I think, is not what most people think of when they think of software factories. However, a software factory can’t work without proper verification (but that’s a topic for a future post).
As I move into what I think is more traditional software factory building (i.e. creating workflows and agents running them), I had a realization that seems rather obvious in retrospect, but it struck me as pretty radical. Recursive self-improvement (or RSI) isn’t just for creating some super intelligence AI. Any software system that is produced by a software factory has the potential to become recursively self-improving. To see why, we’ll have to dig into the details of what a software factory might look like.
(Note: this entire post is written lovingly by hand by me personally with no AI, but the following visualization was created by Opus 5.5 at my direction)
At the top of the factory you have inputs (e.g. from humans, production monitoring, and agents) and on the bottom you have outputs like a software artifact, a cloud service, messages and outputs to third parties, reports, documents and work that feed back into the factory, and the systems of the factory itself. In the middle is just a workflow with steps on the path to creating those outputs. You can already see it’s recursive by the fact that its outputs can feed back into the factory or by updating the factory or the production system for the user facing software.
Let’s dig into each part of this.
Inputs can come from a variety of sources, but here’s a short list:
The inputs lead to what we’re calling missions, which is where the factory really takes over. A mission can be something like:
These would obviously have more detail, but you get the idea.
For inputs like Slack or support requests, agents pick them up and then create a reproducer, or do an investigation, and then either respond, raise to a human for attention, or create a mission for the larger factory to tackle.
Once the factory picks up a mission it will implement it, review, refine, and test. This is the workflow which can consist of agent driven steps, deterministic steps through execution of code, and decision points.
For doing real work, the best outcomes happen when you can verify the results and then let the agent iterate based on verifiable feedback. This happens at different scales across different dimensions like time, token spend, and infrastructure spend. Human attention span is also a cost factor. In increasing order:
There can be many fix, review, triage loops, each of which could run one or all of the verification steps above. With verification, you want to pick the least expensive way to get real empirical evidence that a change works and is what you want.
Having a human check anything is the slowest and most expensive thing you can do.
There are many more implementation details that I don’t have outlined in this flow. The whole internal bit of the factory (i.e. the workflows) is not really defined here and depends on a variety of tools and systems. I think those are mostly testing, verification, and database problems (not InfluxDB, but your factory database), but they’re not really important to dig into for the purposes of this post’s argument:
You can turn a software factory into an RSI system for your product.
It is the obvious end stage if you look at the parts of the diagram. At least I hope it’s obvious by now. It’s already recursive because you have inputs that include your customers, support, production systems and it can output back into itself. The improving part applies because two of the outputs are improvements to the factory itself and the software product(s).
How does it become self improving? Easy, you just replace the human nodes on the workflow and have agents take them. You can have rules or tolerances for when you want an agent to do the work or task it with a human to check. But if you’ve got a scheduler for kicking off an agent (which the above system has) and it can output missions into the factory, there’s no reason why that can’t include any number of things that lead to RSI.
I think that the more general you leave the root level prompt (i.e the more latitude you give the agent) the more powerful the RSI becomes as better models get used. If your factory can pull in new models as they are released, you’ve tied your software factory delivery improvement cycle to the RSI pace that the frontier AI companies are releasing to the public.
I’m not sure that a real, good software factory was possible a year ago. Maybe with Opus 4.5 and GPT 5.2 (both less than a year ago!), but really I think Fable and Astra (and now Opus 5.5) made it possible and real. My guess is that once we peasants have the models currently available to the internal teams at OpenAI and Anthropic, we’ll be able to turn any software factory into an RSI system for the software products we have it delivering.
The models of 6 months ago are not nearly as capable as the models of today. It’s very likely that the models of 6 months from now will similarly be more capable. In fact, the delta will probably be greater as the pace of improvement seems to be accelerating.
Building the tooling now to deliver software like this puts you in the position to take off as the models do. It’s an exciting time to be building.