Software factories are becoming a standard term in engineering.
Anthropic and OpenAI shared their playbooks for how it looks, and the idea itself is pretty simple.
Instead of manually writing code, managing incidents, or fixing vulnerabilities, we have agents running across the SDLC while humans are in the loop.
A factory where agents are the workers, and humans are the managers.
Many companies rush to implement it.
Building agentic workflows, connecting agents to systems to give them context, building skills, connecting Slack for easy operation.
I speak with many platform engineering teams who start building their software factory, but very soon hit a wall when they try to scale it.
This is why we see very few companies that run a software factory at scale (like Uber, Shopify), and there is a lot to learn from it.
In this post I’ll share what it takes to run a software factory at scale and what you should pay attention to as you design it and what architectural components you need to get it right.
Building a software factory is easy #
This article, written by Gergely Orosz (which I recommend following) shares how OpenAI’s software factory looks from the inside.
Building the software factory is fairly easy. At this point you most likely already have a proper CI/CD pipeline, GitOps is matured, gradual deployments, observability is in place, and of course the agents. All you have to do is wire these things together to build agentic workflows:
- Connecting the agents to the system’s MCP for context
- Building the non-coding agents (SRE, security, deployment, review agents…)
- Building workflows and automations to feed the factory with intakes and orchestrate the process
- Slowly putting all the pieces of the SDLC puzzle together.
That’s true when you develop it, but what happens when you scale it in your organization?
What happens when you process nearly 100% of your Jira issues through it and expect hundreds or thousands of engineers to operate it?
Just like any project, especially in engineering, you face scale issues. These scale issues are not new to AI; they’re the same issues you face with any project that moves from the “cool demo” to a production-ready system that can operate at full scale.
Scaling it is hard #
Engineering leaders I speak with want to let engineering run fast. But they now find themselves in a conflict.
They realize that AI-SDLC without control puts the company at risk (and specifically their jobs), but let’s face it, engineering doesn’t care about governance, security, or compliance.
And engineering isn’t waiting; they write their skills, build their agents, wire up their agents to sensitive systems, and build their little factories.
What does it mean for the organization?
- Lack of a dedicated agent owner or skill owner
- No standardization of one factory, teams are building their own and creating many versions of AI-SDLCs
- Skills duplication maintained in a bunch of repos
- No production-ready standards applied to agents and skills
- How do you ensure services are deployed to the right environment?
- No audit log for agent and human decisions
- PR jams causing the factory to deliver at the speed of humans, not AI
- Lack of visibility into the quality of AI decision-making
- No permissions model applied to agents, they use the dev’s permissions and access dangerous tools available through MCP
How to build your Software Factory to scale? #
What can we learn from companies who did it?
I’ve been reading a lot about the topic and interviewed many of our customers to answer this question.
It came down to a few repetitive patterns:
Build a context lake
Context lake (often called context layer) is a unified knowledge graph of your SDLC: services, deployments, environments, tickets, with logical relations between them. Why is it important when you scale?
First, you get one place to manage data access. Otherwise you manage access in each system, which is impossible. Also, you get a clear audit log of data access and tools utilization.
Second, agents reason less when the data is well organized and clean, which saves $$.
Third, agents reach the right conclusion when the data is well organized. When data is scattered and messy, sometimes agents reach the wrong conclusion (e.g., they try to figure out who owns a service, and this data can live in 3+ systems). This means better AI performance and trust.
Uber’s context lake - June 30th 2026
Marketplace of agents & skills
Agents and skills might (and will) be managed in many different places, especially in large companies: repos, docs, Bedrock, S3, etc.
This is okay, don’t try to fight it. But creating a unified marketplace that points to each one gives you and engineering a few wins:
You can assign an owner to each one, this way you create accountability. Don’t blame the agent.
You create an inner-source culture, different teams can reuse others’ assets and improve them over time. It means less sprawl and unified standards.
You can certify agents and skills, just like microservices, we have minimum requirements for software to be considered production-ready, secure, and compliant. For example, agents need to be at x version to be considered production-ready.
Make the software factory contributable
A software factory is a living project. You add more workflows, skills, agents, and context. Your role is to enable teams to build more while you stay in control.
This is a DevEx-first mindset when it comes to building a software factory.
If you try to enforce standards top-down, engineering will find their way to go around you (and probably laugh about it with pride). What I see working best is to become the platform provider where engineers can contribute to the factory.
In return, they all operate in one place, you gain control, and they can run as fast as technology allows.