Software Engineering Operating System
As an industry, we've been talking a lot about the dark factory pattern.
As I've been building out the foundations for Mirage's own dark factory, I've started to think factory describes one layer of what we're building. A factory describes an autonomous delivery system: inputs go in and some desired output comes out. Underneath that factory, though, is a platform that lets many different systems and processes run, interact, and evolve independently.
OpenAI's recent Defense Factory made that distinction a bit clearer for me. It's essentially the same idea as a software factory, but applied to security remediation.
The input is different. Instead of starting with a feature spec, it starts with a vulnerability. The acceptance criteria is different too: the vulnerability is no longer exploitable in our software system.
But both ultimately need to produce the same thing: a change.
And once that change exists, it enters the same lifecycle as any other change: test, verify, authorize, deploy, and observe. The systems have different bounded responsibilities and acceptance criteria, but they're both trying to safely move the software system from one state to another.
The factories are different, but much of the foundation powering them is the same. The factory describes the autonomous system organized around an outcome. I'm interested in the platform underneath it that lets its processes run, interact, and share those foundations.
You know what else is built around autonomous processes? Operating systems.
An operating system schedules processes, gives them access to resources, isolates them from one another, manages identities and permissions, provides mechanisms for communication, and manages their lifecycle when things fail. A process doesn't need to bring its own scheduler, memory manager, or process supervisor; those are provided by the operating system beneath it.
I think autonomous software engineering needs the same thing, but across distributed systems.
A vulnerability remediation system shouldn't need to invent its own execution infrastructure, authorization model, deployment machinery, or verification system. Neither should a feature-development agent, dependency updater, code reviewer, or pentesting system. They should be able to run independently while sharing a common platform for scheduling work, executing it with the right capabilities, exchanging results, and safely turning proposed changes into running software.
Bringing this down from theory to practice, I'm describing durable workflow orchestration. Once you have that platform, the rest starts to look like operating systems primitives: scheduling, execution, identity, isolation, communication, and failure recovery.
Of course autonomous workflows will be developed independently and in parallel, but they need a coherent platform underneath them. That's what I mean by a Software Engineering Operating System: a shared control plane for coordinating the processes that build, test, secure, deploy, and operate software.
With this lens, factories sit on top of the Software Engineering Operating System. A Defense Factory is one autonomous delivery system. A Software Factory is another. Dependency maintenance, code review, pentesting, and deployment can all participate in their own workflows while relying on the same underlying platform.
Maybe I've been working on platform-engineering-shaped problems for too long, but none of this feels fundamentally new. We've been building pipelines and automating pieces of the software delivery lifecycle for decades. What's changing is that more of the processes participating in that lifecycle can now operate autonomously.