This post is part of an ongoing series on how LaunchDarkly engineers are closing the loop of the AI SDLC—and what we're learning along the way.
At LaunchDarkly, the concept of an AI software factory has become our shared obsession. We've been running our own for a while now, and building the tools that help customers do the same. Through this work, we've found ourselves returning again and again to the same tough questions: What exactly is a software factory? What does a healthy one look like in practice?
One of the things we've learned is that there's a world of difference between wiring up coding agents for a side project and building a software factory inside a codebase that ships to thousands of customers at scale.
The side project version is easy to picture: a simple frontend, a modest backend, a database, and no real scale. You can hold the whole thing in your head, apply everything you know about breaking down work and what makes software shippable, and let agents execute across all of it in parallel from Day 1. If that's where you are, I encourage exactly that. Think about all the pieces at once. Build the factory as you build the product.
The enterprise version is a different animal, and the gap between the two is what I'm eager to talk about. It isn't a gap in model capability or tooling. Some of the hardest workflows to automate are the human-driven ones that evolved over years as the codebase, the customer base, and the product all grew more complex. If you're still building the muscles to translate your own thinking from "I drive" to "Agents drive autonomously," this post is for you.
For new services, the factory is a production-readiness requirement
Net-new services are the easy case because they have well-bounded domains, aren't yet in anyone's critical path, and are still easy to control. It’s never been easier to start off on the right foot with agents. If you're building a new service today and not thinking about how to create a factory for it, you're doing a disservice to the business, your team, and yourself.
Factory readiness will eventually become part of production readiness—the checklist a service must pass before real customers can depend on it—right alongside monitoring and runbooks. I know that's controversial. But it’s now possible to build guardrails and automations, translate human judgment into context an agent can consume, and keep a pulse on the high-level patterns that make agents effective, even as those patterns shift week to week. Given all that, I can't find a reason not to treat this as a priority for anything new.
Implementation will differ from service to service, but the posture shouldn't.
Tooling will help here. Our agent platform team is already thinking about how net-new services can start life with a good factory outline and the tools to match. But tooling only carries you to the starting line. Beyond that point, the work demands creative, out-of-the-box thinking—which is what the rest of this post is about.
For legacy code, build systems for agents, not just tasks for agents
What about the codebase with hundreds of contributors over its lifetime and patterns lingering from eras nobody fully remembers? For us, that's our largest and oldest codebase. These legacy codebases are difficult to navigate for human developers, let alone agents. That’s not a knock against anyone. Ask any engineer working in a repo shared with hundreds of others whether their dev environment has room for improvement. You know the answer.
Agents inherit all of that friction, and they inherit it without the tribal knowledge humans use to route around it. So in these cases, the strategy flips. Don't just point agents at task specs. Ask which systems need to exist for agents to be effective in this codebase at all, and start automating things well beyond "Write the code for this ticket." In aggregate, those automations are what compose a factory.
In a codebase like ours, you won't recognize the factory as it emerges. There's no ribbon cutting, no before-and-after photo. Progress looks like dozens of small capabilities compounding, each one making agents a little more effective at thinking in the same direction. This means part of our job is surfacing it: making it visible every time something gets automated away, so people can see the factory taking shape.
Think in two layers of systems
If I had to anchor all of this on a single habit, it's systems thinking, which has two distinct layers.
The first layer encompasses the services, infrastructure, and paths users take through the product. When thinking about this first layer, picture your product as a black box. If you wanted to assemble a team capable of compounding the value inside that box, the box would need an interface those teammates can operate within. That was true for every human you ever onboarded, and it's just as true for agents.
The second layer is newer, and it’s made up of the systems that power the automation itself. This includes:
- The ability to surface the right context for the right agents at the right time.
- Interoperability between tools.
- The ability to pick up the sociotechnical signals that live in Slack threads (i.e., who decided what, why, and what the human team actually cares about).
- The cost, effectiveness, and observability of all of the above.
Agents don't just operate inside your product's system boundaries; they're bounded by the systems you build around them. The surrounding systems deserve the same engineering rigor as the ones they serve.
The good news is that we already know how to build systems like this, because it's the same discipline we apply to building products. You crawl, then walk, then run. This means constantly pruning scope to get to the MVP and iterating as often as you can. It also involves putting changes behind feature flags and using configs to test a variant in minutes. The methodologies transfer, but you have to aim them one layer up.
Here’s some food for thought, based on findings from DORA’s 2025 State of AI-assisted Software Development report: AI acts as an amplifier of an organization's existing strengths and weaknesses, and the greatest returns come from investing in the underlying organizational system rather than the tools.
Stop blaming the model
When an agent does something you don't agree with, the reflex is to call it a model failure. I'm asking you to treat it as a prompt, addressed to you: What are we doing to equip our agents as if they were our teammates?
The era when we could blame a model for getting something wrong is over. We're now entering the age when an agent doing something incorrectly is an ownership question, and we should respond the way we respond to incidents in traditional systems: Find the root cause, run mini postmortems, and anchor to "fixing forward." This is the mindset shift that makes it all work, and it’s true even—and especially—for the small stuff, because those are the issues that compound.
We’re no longer solely responsible for the business logic an agent produces. We're also responsible for how the agent came to its conclusion, how we validate it, and how much we trust it. This involves knowing our tolerances, saying them out loud, and then deliberately pushing them closer to the frontier.
When something an agent did bothers you, don't file it as a complaint about the model. Surface it as an issue with a solution attached—one that, if it existed, would let you comfortably get out of the way. Your frustration with an agent is a spec for a system you haven't built yet.
Try the thought experiment I keep coming back to: If you had unlimited resources and unlimited teammates, how would you set those teammates up for success? With agents, it's no longer a thought experiment. The question becomes how we create 10x engineers whose multiplier is enabling everyone else to 10x their agents.
Engineering is still a team sport
At LaunchDarkly, we believe that our job is to enable our codebase for many more engineers than we ever planned for, including a rapidly growing number of AI agents. That takes coordination, shared context, and a culture where a colleague's wild automation idea gets met with "Yes, and" instead of a raised eyebrow. Someone wants to experiment with automating themselves out of a piece of the SDLC? That conversation should start with “Yes.”
This mindset matters for talent, too. The people we want to attract already think this way. They're out there asking: What could I be doing better to enable my agent teammates? When I feel compelled to stop an agent from moving forward, what’s the reason? What needs to change for me to trust it next time?
When you pair that instinct with staying on the cutting edge of tooling, standards, and context engineering, the path gets a lot clearer. You start to feel empowered. Approaches that would have looked weird under the old constraints stop looking weird, because the constraints changed.
Where this goes next
None of this is a claim that we're ready today, or that we'll be ready by tomorrow. It's a claim that we need to start normalizing this way of thinking—and do so aggressively—so the value can start compounding now, in the space between bugs and PR feedback, with the tools already on our desks.
Stay tuned for more Stories from the Factory Floor, where we'll go into more detail about which large pieces of the SDLC to start automating away, which small pieces compound fastest, and how we're already doing some of this today at LaunchDarkly.
