What is the difference between a deploy and a release?

A deploy is code reaching production servers. A release is that code being turned on for users. Most teams treat them as one event because for years they were the same button, but a feature flag lets you split them: the code can sit in production, inactive, for as long as you want before anyone switches it on.

Why do feature flags matter more with AI-generated code specifically?

Because the normal safety net for a mistake is a reviewer who understands the change well enough to catch it, and that net is thinner when code arrives fast, in volume, and reads as competent whether or not it is correct. A flag adds a second net: if the review missed something, the fix is a toggle, not a rollback, a redeploy, and a wait.

Does using feature flags mean you can skip code review?

No. A flag limits the blast radius of a mistake that gets through review, it does not replace the review itself. Skipping review because a flag exists just moves the discovery of a bug from a pull request to production, where it is more expensive to find and fix.

What should get a flag and what should not?

Anything written by an agent that touches money, permissions, customer data, or a path with no easy rollback is a strong candidate. A one-line copy fix or an internal script with no user impact usually is not worth the overhead. The test is: if this turns out wrong, how fast can you turn it off, and does that speed matter for this specific change.

How does a feature flag limit damage differently than a fast rollback?

A rollback reverts the whole deploy, including any unrelated changes that shipped in the same batch, and it takes minutes even when it goes well. A flag turns off one specific behavior in seconds, for some or all users, without touching anything else that shipped alongside it. That precision is the point: you are not undoing the deploy, you are undoing the one part that misbehaved.

Can a feature flag itself be a source of bugs?

Yes, mainly through flags that never get cleaned up. A codebase with old flags left in place accumulates branches nobody tests anymore, and an agent generating new code around that mess can misread which path is actually live. Flags need an owner and an expiry, the same as any other piece of infrastructure.

What does the 2025 DORA report say about deployment frequency?

It found that 16.2 percent of surveyed organizations deploy on demand, meaning multiple times a day, while 44.6 percent deploy at least once a week. The report also found that decoupling deployment from release, most often through feature flags, is central to how the higher-frequency group increases how often it ships without increasing risk.

What does the DORA report say about AI and delivery stability?

The 2025 report found that higher AI adoption is associated with higher software delivery throughput and, at the same time, with higher change failure rates and instability, unless a team already has strong automated testing and fast feedback loops in place. Its framing is that AI amplifies whatever controls already exist rather than adding new ones on its own.

How do you decide what percentage of users see a new flag first?

Start with a slice small enough that a mistake affects few people and is easy to notice: internal users, then a low single-digit percentage of real traffic, then a wider rollout once the metrics that matter for that change look normal. The size of the first slice should match how expensive a wrong guess would be, not a fixed company-wide default.

Who owns the decision to flip a flag from off to on?

The person or team accountable for the outcome the change is meant to produce, not whoever wrote the code. In the work we do, that separation is deliberate: the same person who ships fast because an agent wrote the change is not always the best judge of when it is safe to turn on for everyone.

Why feature flags matter more with generated code: Reveneau

A pull request used to be the last checkpoint before a change reached a user. Someone opened it, someone else read it end to end, and if it passed, it went out. That model assumed the two slow parts, writing the code and reading it, took roughly the same amount of time. They no longer do.

An agent can write a working-looking change to a checkout flow in minutes. A reviewer still needs the same care they always did to catch the one wrong assumption buried in it, because the code reads as fluent whether or not it is correct. That gap, speed of writing against speed of understanding, is where a bug gets through. The fix is not a faster reviewer. It is a second door after the first one, and a feature flag is that door.

1. Deploy and release stopped being the same event, for good reason

For most of software's history, pushing code to a server and turning it on for users were the same action. You merged, it shipped, everyone got the new behavior at once.

That coupling gets riskier the more code you move through it, and the less time a person had to sit with any one piece of it. A feature flag breaks the coupling on purpose: the code reaches production, inert, wrapped in a check that decides who sees it. Nobody is exposed to a change until a person deliberately flips it on, and that person can be different from whoever wrote the code and different from whoever approved the pull request.

This is not a new idea. What changed is how much it costs you not to do it. When a person wrote every line, the pull request was a real inspection: one author, one set of assumptions, a reviewer who could reasonably expect to hold the whole change in their head. When an agent writes the change, the volume of code moving through that same review step goes up. The number of hours a reviewer has to give it does not. DORA's 2025 State of AI-assisted Software Development report found that higher AI adoption is associated with higher delivery throughput, and, in the same data, with higher instability, unless a team already has the controls, strong automated testing, fast feedback loops, mature version control, to absorb the extra volume. The report's own framing is that AI does not add discipline on its own. It amplifies whatever discipline was already there.

A feature flag is one of the concrete forms that discipline takes. It does not stop a wrong assumption from reaching production. It stops a wrong assumption from reaching everyone at once, and it gives you a way to remove it that does not involve a rollback.

2. On-demand deploying and feature flags travel together, and the data shows it

If deploy and release are decoupled, deploying more often stops being risky in the way it used to be, because deploying no longer means exposing anyone to anything.

The same DORA 2025 research found that only 16.2 percent of surveyed organizations deploy on demand, meaning multiple times a day, while 44.6 percent deploy at least once a week. That on-demand group is not shipping more because it is braver. It is shipping more because it has separated the act of moving code into production from the act of turning a behavior on, so a deploy carries less weight than it does for a team where the two are still fused. Flagsmith's writeup of the same mechanism puts it plainly: with the right tooling, deployment and release happen independently, and that separation is central to how high-frequency teams increase how often they ship without increasing how much can go wrong in any one shipment.

For a team using an agent to write a meaningful share of its code, this is the practical answer to "how do we move fast without moving recklessly." You do not slow the writing down to match the old reading speed. You add a control that makes a fast, wrong deploy cheap to undo.

3. A flag turns a rollback into a toggle

A traditional rollback reverts a whole deploy. If three unrelated changes shipped in the same batch and one of them was wrong, you either live with the bug until a fix goes out, or you revert all three and lose the two that were fine. Either way, it takes minutes, and minutes matter when the change touches money or customer data.

A flag is narrower by design. It turns off one specific behavior, for some or all users, in the time it takes to update a value somewhere a person can reach quickly. Nothing else that shipped alongside it is touched. When the change came from an agent and the mistake is something a human reviewer plausibly missed, being able to turn off exactly that one thing, without a redeploy and without collateral damage to unrelated work, is what makes catching the mistake late survivable instead of costly.

A flag earns its keep during rollout too. Ship the change to a small slice of real traffic first, internal users or a low single-digit percentage of customers. Watch the numbers that matter for that specific change. Widen the slice once they look normal, and narrow it back to zero in seconds if they do not. The size of that first slice should match how expensive a wrong guess would be, not a fixed rule you apply to everything the same way.

4. A flag is not a substitute for review, and treating it as one creates a new failure mode

None of this is an argument for reading generated code less carefully. A flag limits what a missed bug can do. It does not lower the odds that a bug gets missed, and it is a mistake to let a flag's existence loosen how a pull request gets reviewed, because that just moves the discovery of the bug from a pull request, where it is cheap to fix, to production, where it is not.

Flags carry their own maintenance cost. An unmanaged flag becomes a hazard of its own: a codebase that has accumulated old flags nobody has cleaned up ends up with branches nobody tests anymore, some on, some off, some half-forgotten. Generating new code around that kind of mess is exactly where an agent, working from the code in front of it rather than from institutional memory, can misjudge which path is actually live. Every flag needs an owner and an expected removal date, the same as any other piece of infrastructure, or it becomes one more thing a reviewer has to hold in their head, which is the problem this whole approach was meant to reduce.

In the work we do, we treat the decision to flip a flag as separate from the decision to write the code, on purpose. The person accountable for what happens when a change goes live is not always the person best positioned to judge whether it is safe to turn on for everyone, especially when the code came from an agent working quickly on a narrow instruction. Splitting those two decisions is a small process change. It is also the difference between a bug that costs you a toggle and a bug that costs you an incident review.

Speed was never the risk. Coupling was. Decouple the deploy from the release, and the speed stops being the thing you have to apologize for.

Sources

DORA, State of AI-assisted Software Development 2025: Higher AI adoption correlates with both higher delivery throughput and higher instability, and the report frames AI as an amplifier of a team's existing controls rather than a source of new ones.
Axify, Deployment Frequency: 2025 DORA Report Data: 16.2 percent of organizations surveyed in the 2025 DORA report deploy on demand (multiple times a day); 44.6 percent deploy at least once a week.
Flagsmith, How to decouple deployment from release with feature flags: Explains the mechanism by which feature flags separate pushing code to production from exposing it to users, and why that separation underlies higher deployment frequency among high-performing teams.