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 protection against a mistake is a reviewer who understands the change well enough to catch it, and that protection is weaker when code arrives fast, in volume, and reads as competent whether or not it is correct. A flag adds a second protection: 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 how much a mistake that gets past review can break, and the review is still needed. 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 were deployed 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 deployed with it. That precision is the point: you undo only the one part that misbehaved, and everything else keeps running.

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 those old flags 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 deploys 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. It describes AI as strengthening the effect of 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 group 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 group should match how expensive a wrong guess would be, not a fixed company-wide default.

Who owns the decision to switch 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 releases 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 hidden 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 a second check after the review, and a feature flag is that check.

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 was deployed, everyone got the new behavior at once.

Joining the two gets riskier the more code you deploy, and the less time a person had to study any one piece of it. A feature flag separates them on purpose: the code reaches production, switched off, inside a check that decides who sees it. Nobody is exposed to a change until a person deliberately switches it on, and that person can be different from whoever wrote the code and different from whoever approved the pull request.

The idea is old. What changed is how much it costs you to skip 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 understand the whole change at once. 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 handle the extra volume. The report describes AI as making whatever discipline was already there stronger, while adding none of its own.

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 go 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 deploys 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 risk than it does for a team where the two are still joined. 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 deploy without increasing how much can go wrong in any one deploy.

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 were deployed 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 deployed with it changes. 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 harming unrelated work, is what makes catching the mistake late a small problem instead of a costly one.

A flag is also useful during rollout. Release the change to a small share of real traffic first, internal users or a low single-digit percentage of customers. Watch the numbers that matter for that specific change. Increase the share once they look normal, and reduce it to zero in seconds if they do not. The size of that first share should match how expensive a wrong guess would be, not a fixed rule you apply to everything the same way.

4. A flag cannot replace review, and treating it as a replacement creates a new failure

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 make pull request review less careful, 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 risk 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 old flags like these is exactly where an agent, working from the code in front of it rather than from what the team remembers, 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 keep track of, 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 placed 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.

The real risk was having deploy and release as one step. Separate the deploy from the release, and speed stops being a problem.

Sources

DORA, State of AI-assisted Software Development 2025: Higher AI adoption correlates with both higher delivery throughput and higher instability, and the report describes AI as increasing the effect of a team's existing controls rather than adding 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.

Why feature flags matter more with generated code