A decade ago, plenty of software teams released once a quarter and saw no reason to go faster. Today, automated software delivery is pushing some organizations into tens of thousands of changes a day, a pace that breaks any process built around a human approving each release. The question is no longer whether teams can ship faster. It is what keeps that speed safe, and where the real constraint now sits.

Edith Harbaugh, co-founder and CEO of LaunchDarkly, has spent more than ten years building the release layer that sits between code being written and code reaching users. In a conversation with Guy Podjarny on the AI Native Dev podcast, she explored what feature flags, rollback and runtime controls look like once agents are writing much of the code.

Automated rollback and the 2 a.m. test

The starting point is rollback. Harbaugh was clear that feature flags are a technique, not a product: "Everything I'm talking about you can do on your own." What changes at agentic pace is who makes the call to roll back. Teams shipping ten or a hundred changes a day need a way to detect quickly whether something is going right or wrong, and to reverse it when it is not.

That decision, she argued, is exactly where AI fits well. Error rates, operational metrics and even a fuzzy signal like an uptick in support tickets can trigger a rollback without anyone sitting at a dashboard. Internally, LaunchDarkly frames it as a question: if a deploy goes wrong at 2 a.m. and is rolled back within a second, did it really go wrong?

In practice, this suggests the value of automated rollback compounds with volume, since a failsafe matters more across a thousand changes than across one.

What makes a good feature flag

Guy pushed on a harder question: what separates a good feature flag from one that causes damage? Harbaugh's answer was simple. "A good one is always one that you understand." The trouble starts with stale flags whose purpose has been forgotten. She described one company where a single load-shedding flag, when toggled, silently stopped new file uploads, and nobody knew what it did.

On scale, she resisted magic numbers. A small startup with ten to forty well-understood flags may not need a vendor at all. The need for a framework appears with multiple, distributed teams and dependent flags that move several subsystems together. Cleanup is the part teams skip, the equivalent of doing the dishes. LaunchDarkly admits it did not always practice what it preached either, and now runs a long-lived agent that examines every flag, checks whether it is still in use, and safely deletes the ones that are not.

Why one-shot agents fail: defining success for agentic coding

One of the most practical threads concerned what happens when you hand work to coding agents. Roughly a year ago, Harbaugh noted, one-shot prompting was at its peak, and LaunchDarkly tried it internally by asking an agent to refactor part of its code base. To a team of humans, "refactor the code base" is a clear instruction. To an agent, it is not. "They just have no idea what that means. Refactor for what?"

The fix was decomposition: breaking work into smaller and smaller atomic units until each agent had a specific task, such as checking for bloat or making sure code is understandable. She observed that agents do not hold concepts like "good" or "bad," so those words have to be turned into explicit standards, for example a performance threshold or a load time.

This is where the conversation connected back to release management. The success criteria written upfront for the agent become the metrics a feature flag monitors in production. The goal is to check that everything specified about how the code should behave still holds in the real world. Guy framed this as the common through line in delegating to agents: you have to do the hard part of describing what success, failure and the guardrails look like, rather than relying on knowing it when you see it.

Feature flags in the software factory

It can be helpful to plot the delivery pipeline as a series of stations, which is roughly how Harbaugh described the software factory metaphor. She likes it because it implies gates, steps and repeatability, and she noted that some engineers worry it makes their work rote. Her view is the opposite: dependable infrastructure frees engineers to be more creative.

LaunchDarkly positions itself at the final station. Code generation and code review sit upstream. What follows is the last step: releasing to the world with guardrails, phasing a rollout from London to Scotland to everyone else, rolling back when something is suboptimal, and potentially feeding strong positive signals back to a coding agent to keep iterating.

Inside LaunchDarkly, some of this is already real. Harbaugh described an R&D team that built a fleet of more than twenty agents to work on part of the code base, leaving the engineer to review the resulting pull requests, a role she likened to the classic architect. Another pointed an agent at a long-neglected bug backlog and began releasing fixes with guardrails.

The bottleneck moves to the last mile

Asked to look five years ahead, Harbaugh offered a pattern rather than a prediction: fix a bottleneck in one place and it moves somewhere else. For most of her career, the constraint was code itself, meaning how many engineers a company could hire and how quickly they ramped up. "And now code is incredibly cheap." The bottleneck moved to code review, where a wave of tools has emerged. What remains is the last mile: whether reviewed code actually has a productive impact on the person, or system, at the other end.

Smaller, more frequent changes make that impact measurable in a way packaged releases never could. The risk she flagged is over-optimizing narrow features until a company has backed itself into a corner, serving a passionate niche while the broader market stays ambivalent. Guy's summary was that feature flags do not replace judgment; they let teams apply it more wisely.

Runtime controls for AI agents

The same release logic now applies to agents in production. LaunchDarkly's Agent Control lets teams switch models or prompts at runtime without a redeploy, dial an agent back when customer complaints spike, or change models when token spend climbs. She suggested the industry is still working out the difference between ephemeral agents built for one project and long-running ones that need ongoing guardrails.

Closing on leadership, she described encouraging her team to take some dumb bets as well as smart ones, because AI makes it faster to build a feature than to debate whether it is worth building.

The full conversation is worth a listen for anyone thinking about where release management sits as automated software delivery speeds up. Where does your team's bottleneck sit today?