Your Software Factory Needs an Operations Factory

For three years, almost every industry conversation about AI and software delivery has centered on the exact same half of the problem. We have, collectively, gotten very good at leveraging AI to create software. Nobody hand-crafts all of their code anymore. Most teams now write a specification (Spec), and AI generates the code, writes the tests, and runs those tests against it. While maturity varies across different engineering organizations, virtually everyone is using something—whether it is Claude Code, Cursor, Windsurf, or Devin. StackGen's growing number of enterprise customers such as Nielsen, AutoDesk, Bancolombia have all witnessed this firsthand where those tools quickly became standard across the board for developers. That is the norm now, not the exception.

And yet, looking honestly at the industry, we have been celebrating an incomplete victory.

The Thesis, Up Front

We have automated the making of software and left the running of it almost entirely alone. 

If you have built a software factory - and most enterprises now have one at some level of maturity - then you have a system that produces deployable artifacts faster than your organization can safely deploy, operate, and defend them. The bottleneck did not disappear. It simply moved downstream, shifting from the inner loop to the outer loop.

The outer loop, where software actually runs and delivers business value, is still being managed the way it was a decade ago: by humans, with a stack of disconnected tools, handling problems one ticket at a time.

To understand why this is unsustainable, we have to look at the problem from first principles.

The Inner Loop Is Solved. The Outer Loop Is Not.

Picture the DevOps infinity loop most of us have drawn on a whiteboard.

• The Left Side (The Inner Loop): This is the space the developer lives in - plan, code, build, test. This is the half AI has largely solved. Developers still tweak things by hand, but the center of gravity has moved from writing code to writing intent and letting models handle the mechanical work.
• The Right Side (The Outer Loop): This is where you deploy, operate, observe, secure, and remediate. This is where the software you just generated has to earn its keep in production. This is the half AI has not solved, yet.

The outer loop remains unsolved not because it is inherently harder, but because the industry has attacked it the wrong way. Over the last decade, we optimized this space with DevOps and SRE practices. Today, vendors are trying to make each step in that sequence "agentic" on its own isolated island. Some have genuinely rethought their products around agents; others have bolted a chat box onto a legacy dashboard.

Either way, the result is the same: a collection of very capable, highly siloed agents bound strictly to their core tools.

The Customer Became the Integration Layer

Every observability vendor now has an agent sitting on its stack. Cloud providers have infrastructure agents. There are excellent, standalone SRE agents doing auto-remediation. These are real companies building genuinely impressive products, and our critique is not of their individual capabilities.

The issue is that every single one of them is a silo. The enterprise that buys three or four of them inherits a job nobody asked for: acting as the integration layer between independent agents that have no awareness of one another, no shared context, and no common memory.

We spent the better part of a decade learning this lesson with traditional tools. A toolchain full of best-of-breed products that don’t talk to each other doesn’t give you the sum of their capabilities; it gives you the sum of their seams.

Now imagine that same problem, except the tools can actively execute changes:

• An observability agent notices a performance spike.
• An infrastructure agent, completely blind to the spike, simultaneously resizes a cluster.
• An SRE agent, blind to both, triggers a service rollback.

This creates three intelligent systems, each locally correct, collectively producing chaos while a human frantically tries to referee. Enterprise customers do not want to buy isolated intelligence and then supply the integration themselves. They want that intelligence integrated out of the box.

What the Customer Is Actually Asking For

Stripping the problem back to first principles makes the demand simple. The people who run these systems do not want another dashboard, and they certainly do not want a fleet of disjointed agents to babysit. 

They want to express an intent and have the machinery deliver the outcome.

The industry already knows how to express intent because we have spent years teaching it to do so:

• For operations: Intent is defined by Service Level Objectives (SLOs). Your uptime, throughput, resilience, and error rates.
• For delivery pipelines: Intent is tracked via DORA metrics. Namely, lead time, deployment frequency, and change failure rate.

These are outcomes an engineer can state in plain English. That is the real goal. We should not just be giving SREs smarter tools. The goal must be to let a human declare the operational outcome they want, and let the system take responsibility for continuously achieving it.

Everything between that intent and the final outcome - from triage and correlation to remediation and paperwork - is work organizations can no longer afford to do by hand. The upstream software factory is simply shipping changes faster than any human team can absorb.

The Answer Is an Autonomous Operations Factory

Companies like Devin and Factory AI proved that software development deserves an integrated factory system rather than a pile of point tools. The exact same argument applies to operations.

If you have a software factory, you need an operations factory to run what it produces.

This is precisely what we are building at StackGen. To be clear, this is not another point agent; it is a true factory system built on a continuous pipeline:

1. Intent-Driven Engineering: The pipeline starts with intent. An engineer expresses the desired operational outcome and its target metric in natural language. The factory converts that into a Spec its agents can consume.
2. The Swarm & Shared Context: At runtime, a swarm of agents is provisioned to execute slices of that specification. They avoid multi-vendor chaos because they are not strangers to one another. They operate on a common, shared context graph, our Aiden World Model, and a unified runtime harness called Aiden OS. Here, they share memory, a continuously learning knowledge base, and customizable workflows.

This shared context changes everything. It is what allows the SRE agent to know, instantly and without manual intervention, exactly which pull request the DevOps agent deployed twenty minutes before a latency alarm went off.

When something breaks, the system does not guess at loose hypotheses. If a code change caused the issue, it opens a pull request against the code; if the cluster was never resized to handle that change, it resizes the cluster instead. The difference between those two root causes is only knowable because the agents share a unified world model.

This world model rests firmly on what we call the Four Bodies of Truth:

• Observability Data: What is actually happening in the system right now.
• Deployment Information: What code, infrastructure, or configuration change was last shipped.
• Content: Runbooks, knowledge bases, and RCAs from past incidents, the institutional memory the system learns from.
• Service Architecture: What additional services, internal or third party, are running, what state they are in, and what SLOs they carry. You cannot defend an outcome you have no awareness of.

Deterministic Where It Must Be, Autonomous Where It Can Be

When engineering systems become agentic, there is a temptation to make everything probabilistic. We believe that is a potentially catastrophic mistake. Guardrails must remain deterministic.

A policy like "You cannot make an S3 bucket public-facing without proper encryption" is not a suggestion we want an agent free to reason its way around. To solve this, our policy engine compiles rules directly into Rego code. The guardrails hold every single time, regardless of what an AI model thinks.

Inside those strict guardrails, however, the agents can genuinely act. Within bounded blast radiuses, they can:

• Open and merge pull requests.
• Insert release gates into a pipeline or diagnose build failures.
• Remediate infrastructure drift using hardened Terraform.
• Defend an SLO by throttling or redirecting traffic, or executing rollbacks.

That boundary is where human judgment is encoded. A simple rollback of a single microservice? The factory handles it automatically. A cluster or storage resize within a modest threshold? Done. Anything with a blast radius above what the line the business draws? The system stops and dials home to a human.

Human-in-the-loop is not a fallback for when the AI fails; it is a designed protocol for novel, First-of-a-Kind (FOAK) exceptions and high-consequence judgment calls. Because it all sits on a shared world model, the factory's capabilities compound with each run, building its own corpus of knowledge to handle recurring incidents faster, more consistently, and more cost-effectively.

Intelligence for the Agents, Judgment for the Humans

The technology industry has begun drawing a line that we believe is exactly right: intelligence should be owned by agents, but judgment and authority must always belong to humans.

Humans own the goals, the risk appetite, the priorities, and the trade-offs. The factory owns everything that can safely be automated. To make this line visible and manageable for organizations, we are introducing two key metrics:

• The Autonomy Index: The percentage of factory decisions, weighted by risk and complexity, that you choose to hand over to agents. It should never be 100%. A highly sensitive environment, like a core bank payments gateway, will rationally run a low autonomy index to keep more humans in the loop, while lower-stakes environments can run it much higher. This is a business decision, not a technical one.
• Autonomy Coverage: How much of a given operational area is under autonomous management at all. You might achieve 90% coverage in infrastructure operations but far less in SRE, depending on the complexity of your environment.

We view these metrics as a natural extension of DORA’s logic, carried past the traditional software development lifecycle and directly into operations. Tying them together is a single north star: Cost per Action. This measures the total cost of operations, including token spend, human time, infrastructure, and the cost of the downtime being avoided. As autonomy goes up and the factory learns, your cost per action should come down while your SLOs hold flat.

Final Thoughts

We spent a decade convincing enterprises that DevOps and cloud migration were foundational organizational transformations, not simple tooling purchases. The companies that played the long game, that is building capability before scaling spend, were the ones that won.

The AI wave will reward the exact same discipline. Automating the inner loop was the easy, visible half. Running the outer loop with the same rigor, the same shared context, and the same honesty about human judgment is the harder half. It is also the half that decides whether software generated at AI-velocity becomes a business asset or a massive liability.

You have a software factory. The question is no longer whether it is fast enough; it is how effectively you can run everything it ships.

Introducing the StackGen Autonomous Operations Factory

We are officially pulling back the curtain on our Autonomous Operations Factory, entering preview on September 15th. To learn more and request early preview access, visit stackgen.com/factory.