AI has made writing code free, or at least, “free minus the incredible token spend we're all experiencing right now.” But there’s a difference between writing code and producing software, and most engineering organizations are about to learn it the hard way.
All we've actually done with AI is move the bottleneck out of writing code and into the process of reviewing that code and deciding what the specs are. I heard a telling statistic at this year's OpenAI Frontiers conference: Leading teams report shipping roughly three times as many PRs as they shipped in December, and those who really get it are on track to go six times faster by the end of the year. That volume is the heart of the problem. The code shows up, but the question is whether your organization can absorb it without drowning.
So here’s the thing I keep telling other engineering leaders: You don't win this era by running your old process faster. You win by changing the game.
Change is no longer discrete
We operated for decades on a comfortable assumption that behavior changes when code changes. You review, you stage, you deploy, you monitor, you fix. Agile codified a version of this workflow by forcing teams to ship small, ship often, and keep each change tiny enough that when something breaks, you can find it fast in a sequential log of changes.
I’ve been following this model in some form since the extreme programming days of the late '90s, and I'll say it plainly: Agile is now obsolete. Small batches were how you localized a problem when humans were the rate limiter, but now that agents can do that work, small batches solve a problem we no longer have.
The real problem is drift. Every system depends on a model, and these underlying models are constantly and quietly changing. This challenge is compounded by always-changing prompts, context, and data infrastructure, and all of it is sitting on top of a probabilistic system. The old instinct to slow down, shrink the change, and add another review ritual doesn't reduce your risk. It increases it because, while you're deliberating, the ground is moving underneath you. What you need is a different set of tools and techniques to manage the drift.
Why we built a software factory
At LaunchDarkly, we have the same problem that many of our customers do: going faster and faster, but staying in control while we do it. That’s why we built our own software factory and turned it loose on the full software development lifecycle, with agents automatically handling PRs, reviews, feature flagging, guarded releases, and cleanup.
The headline result is that we’re shipping three times more code than we shipped just three months ago, and we’re doing it with a very small team. Each engineer has become an army of one, operating a team of agents that are all working toward a common goal. Everyone is thinking and operating more like a front-line manager than an IC, and my team of six or eight people is now doing the work of six or eight teams. And we didn’t prove this model on a greenfield, either. We pointed it at our oldest, most business-critical production systems: the ones that every mature org is terrified to touch.
Controlled automation beats autonomy every time
We’ve learned many lessons from building a software factory, and one of the most important is that full autonomy is a seductive trap. If you hand an agent a broad mandate, it doesn’t know what you actually meant. It’s like telling a robot to build you a house. It will build you a house, but it might be a birdhouse. If you then say you want “a house for humans,” it could come back with a dollhouse. To get what you want, you have to spell out the dimensions, the number of floors, and the number of bathrooms. Specification is the job now.
Specification means real validation, not theater. Code is often structurally correct but functionally incorrect. It compiles, the pixels land in the right place, and it's still wrong. Your eval loops have to go deeper than “Is the button rendered?” Instead, you have to ask: “Do the right menus appear when I click the button? When I navigate those menus, are the right APIs called with the right parameters?” You need both the white-box checks of structure and the black-box checks of behavior. You also need to ask performance questions, such as, “Does the running system show the same latency, availability, and throughput you know to be correct?” Connecting these requirements and rerunning the release-observe-iterate loop is what helps make automation safer.
There’s also a compounding danger people underestimate. When you connect multiple models and one of them drifts, the next one drifts off the first. The first model’s error is multiplied down the chain. The whole game becomes about making sure that when something goes even slightly off course, it gets back on the right path fast. One of the things I've always loved about software is that when you tell the computer to do something, it does it. We're no longer in that world. Strong guardrails and checkpoints are how you push a probabilistic system back toward the deterministic outcomes we all want and expect. The ability to do that has been game-changing for us.
The engineer’s job has gotten more important
There’s a misconception that AI does the thinking for you, but it’s not really a thinking tool. It’s a predictability engine, and it functions best when you put your own judgment, knowledge, and experience into the loop. It’s an amazing piece of math that’s built to serve you, and you have to treat it with the right level of control and instruction to get what you want out of it.
That’s why I think we need more people in software, not fewer. The toil, or the work that humans don’t actually learn from, is getting automated, but human attention must remain present. Understanding and implementing nonfunctional requirements has always been the interesting part of the job, and it’s the part that becomes more essential as you grow in your career. This requirement isn’t going anywhere. If anything, it matters more, and it matters earlier.
This principle extends to oversight itself. One of the most freeing things about running a software factory is using agentic judgment to decide where a human is actually needed. For instance, agents can make calls on whether something is high risk or whether a flag is needed at all. That’s because agents are excellent at judging other agents’ work if you give them criteria. Ask an agent, “Is this good?” and you won’t get anything useful because it has no idea what “good” means. But if you own the criteria and give it a series of binary checks, it will become a rigorous reviewer. This is how we can put people on the most important, cognitively demanding work, and keep them as far away as possible from the toil.
You build the factory. LaunchDarkly helps you run it safely.
Could you build a software factory without runtime control underneath it? There are many things you can do, but the question is whether you should.
Manufacturing offers a useful metaphor. Ford gave us the assembly line. Toyota gave us the Andon cord and the Kanban process to go with it, and reliability, quality, and affordability improved dramatically. Software is entering that same phase, but unlike most cars, software is dynamic, responsive to real-world events, and always mutating in production. You can't bolt that down and walk away.
If you're a leader staring at three or six times your previous change volume heading for your production environment, my advice is simple: Don't try to inspect your way through it at human speed, and don't YOLO it either. Build the factory. Build the loop where code is written, flagged, released, measured, corrected, and improved continuously, and wrap that loop in real control. The factory is the delivery mechanism, and control is the safety mechanism. Neither one reaches its full value without the other.
We’ve spent 12 years obsessing over how to do this reliably at scale, with global reach and the right number of nines. It’s our core business, and it isn’t anyone else’s, and runtime control of agents is the ultimate evolution of where we’ve been heading for a decade.
A factory has a lot of moving parts, but what LaunchDarkly provides is the control infrastructure that runs underneath it all. We’re vendor-neutral, so no matter what frameworks or platforms your factory runs on, we’ll snap right in. And we’re building our own software factory out in the open, because you can’t credibly help others build one if you’re not living in one yourself.
