For the past year, the story about AI and software has been about speed. Agents write code faster, clear backlogs, and turn a lunchtime idea into a working prototype. But the faster it gets to write code, the scarier it gets to ship. According to the LaunchDarkly Control Gap Report, 94% of surveyed engineering leaders said AI accelerated development, but 91% said they’ve become more cautious about shipping AI changes to production.
So how do you let AI do more while keeping your engineers in control of what reaches customers? That’s the question we unpacked on the latest episode of the Control Panel. We launched Release Autopilot with LaunchDarkly CPO Jonathan Nolen, Ramp Senior Staff Engineer Pranjal Vachaspati, and LaunchDarkly Director of Product Specialists Tom Totenberg showing the product live. Every chapter of the recorded event is included in this post, so you won’t miss a thing.
The new bottleneck comes after the code is written
AI is pushing far more change toward production than before, and even though engineers didn’t write most of it, they’re still accountable when it breaks. Leadership hands them a prototype built over lunch and says, “Just ship it.” The belt is moving faster than the humans standing next to it.
Reviewing each change by hand was never built for this volume, and many teams are turning to automated testing and code review to keep up. These tools help, but they can’t catch every issue before it reaches production. Release controls like feature flags manage that risk, but humans can’t apply them manually at agent speed. As a result, too many agent-written changes go live without safeguards, release work remains manual toil, and remediation is slow because problems surface only after users feel them.
Ramp is among the teams furthest along on the frontier of AI-assisted development, and Pranjal Vachaspati highlighted the benefit he sees for engineering teams as automation becomes further embedded throughout the SDLC. He borrowed a line from Sid Meier, the creator of the Civilization series: “A game is a series of interesting decisions.” He added, “If we do this right, we can make writing software a series of interesting decisions. We need to take the toil off the table. Agents are great at doing the toil.”
As Jonathan Nolen put it, the principle that falls out of this is simple: You can't force AI back down to human speed.
We cannot slow down AI speed to human speed. If we're going to get the value out of the things we're building, the entire process has to operate at that speed.
Watch Chapter 1: The new bottleneck
Automating releases while keeping humans in the loop
Everyone wants to go fast and do so safely, but the hard part is how. We already know what a safe release looks like: changes assessed for risk, feature flags applied where needed, success metrics defined up front, a rollout that matches the risk, and a way to reverse it in milliseconds. None of that is new. The problem is that doing it for every change takes real work, and many teams find it hard to keep shipping safely.
That's the gap Release Autopilot closes, and in the demo, Tom Totenberg ran a single agent-written change through the whole lifecycle:
- Safeguard each change. Auto-classify weighs signals like business intent, the services a change touches, and its criticality, including whether it involves financials. Then it recommends the right controls. For changes that need a flag, Auto-flag wraps the relevant code in a feature flag, giving teams control over when and to whom the change is released.
- Release without the manual work. After a change deploys, Auto-release executes the release plan, advancing the rollout through environments such as staging and production, each with its own audience, pace, and guardrails. The guarded release tracks the metrics that matter for that change, scoped to just the users exposed to it.
- Roll back what breaks. The guarded release observes the change for signals like errors, exceptions, and latency, along with business metrics like whether people can finish what they came to do. When metrics regress, it automatically rolls back the individual change to the last good state, or notifies you, based on the guardrails you set. And it does this live in production in milliseconds, with no redeploy required.
- Clean up after each release. Auto-cleanup tracks each flag’s status, like “ready for code removal” or “ready to archive,” and checks things like whether it’s a prerequisite for other flags, how old it is, and whether it’s serving a single variation. Agents then submit the PR that removes the dead code, on a daily or weekly schedule you set, and the flag is archived after it’s gone from code.
Throughout, humans stay in control. Your team decides where to review and approve Release Autopilot’s recommendations and where to let it act automatically, within the guardrails you set.
You also choose how and where it runs. Teams can run Release Autopilot as a plug-and-play GitHub app, bring their own key to run it on their own AI inference, or take the published skills into their own tooling. It can run at code generation, in review, or both. The engineers who want to do the right thing want the skill while they write the code, and platform teams want a safety net for anything that slips through.
We’ve thought about individual pieces of this, but to have the whole flow from LaunchDarkly is going to let us make sure we’re not spending time on toil, and that things aren’t falling through the cracks.
Watch Chapter 2: Automating the software factory
What control unlocks: A software factory you actually trust
When release safeguards are applied consistently, the question stops being, "Can we trust AI with this?" and becomes "How much more can we hand off?" At Ramp, that shift is already visible in the numbers: Flag counts have climbed from one or two thousand to nearly ten thousand as flagging stopped being a chore worth skipping.
LaunchDarkly has run the same play on itself as customer zero. With roughly the same headcount as a year ago, the team put nearly four times as many flags into production, and shipped about twice as many PRs. Customers see the difference, too. Despite the massive increase in the volume of change, our Major+Critical incident time has decreased by about 70%. Less friction means more of our time goes to what we actually want to build.
As Pranjal framed it, the win is in the kind of work that's left.
If we can take ten bets where before we could only take five, because we're automating away the uninteresting parts of the job, that means we're going to have twice as many winners.
That's the bigger idea. Every company's software factory will look different, and LaunchDarkly isn't the factory—it's the control layer underneath it, the thing that lets you safely increase how much AI autonomy you're willing to give. Release Autopilot makes that control automatic, so teams can build, release, and run at AI speed, with agents doing the work and humans setting the guardrails.
Watch Chapter 3: What’s next
See it in your own pipeline
Release Autopilot automates the release process for AI-generated code, while humans set the guardrails. If you want to see how it fits your stack—or if you're not using LaunchDarkly yet—request a personalized demo. We'll show you how to put a safety net around every change that needs one, so you can let AI take on more without giving up control. Select Release Autopilot features are available in beta.
