The frontier loves feature flags

Want to ship software like the frontier labs? Well, the secrets are out! Anthropic and OpenAI have both recently shared their engineering practices in public, especially how they’re doing (or not doing) code review and the layered trust architecture they’ve built to mitigate risk and scale agent autonomy. Two ideas stand out: using classification to drive automation, and treating feature flags as the last line of defense. Before we get to flags, let’s start with the problem they’re solving.

Fast or safe?

Everyone’s in a bit of a panic. Gotta ship more code, more faster, with more agents. And yet.

We don’t trust our agents (not even at Anthropic). Especially in big monorepos, they can hallucinate or suggest some pretty wild patterns. Or rogue PMs can ship a bunch of code they don’t understand. And yet.

It’s also not reasonable for humans to fill the gap. Not trusting agents doesn’t mean we should ask people to spend all day on code review. And yet.

We have to do something. We can’t just let agents ship directly to production without any human review, can we? And yet.

Historically, the options for de-risking delivery also add more friction and slow things down: mandatory approvals with code review, RFCs, go/no-go meetings, canaries, test coverage, required CI gates, adding feature flags, release windows, security reviews, and, egad, the dreaded change advisory boards. And yet.

We gotta ship more code, more faster. And, unfortunately, this isn’t exactly a slow is smooth and smooth is fast scenario. At the frontier, fast is fast. And slow is 3 months old, which is actually 2 years old. So, do we go fast or do we add more guardrails?

Yes.

The frontier asks “why not both?”

Recently, we’ve been playing “Would you rather…?” on family car trips. You say two things, and everyone has to pick their preference. e.g. “Would you rather talk to a baby or play hide-and-seek weirdly?” or “Would you rather wear a pumpkin on your head or roll down a grassy hill?” My four-year-old daughter’s answer is, frequently: “I choose both!”

The boring part of me wants to remind her that she’s breaking the rules. The whole point of the game is to pick one. But she’s right. Why not both?

The frontier is also a land of “why not both” or, more urgently: we must do both.

From Anthropic’s engineering blog:

And:

Flags exist at the frontier

In the expect failure category, let’s take a deeper look at feature flags as an example. Ten years ago, everyone was really excited to decouple deploys from releases. Runtime control over software is absolute magic. It changed how teams worked. Less long-lived feature branches, more trunk-based delivery; easy ways to experiment, test on production, run early access programs, etc.

A long, long time ago (last year), it was totally fine to use feature flags casually for these same classic use cases. Make them available for your company, have some loose process, leave it up to teams, maybe define best practices in a doc somewhere. Many teams have used feature flags primarily as an operational tool that provides power and flexibility for product delivery. But until now, most teams have not consistently used them as critical de-risking infrastructure.

You might be thinking: but we use flags as kill switches! Sure. How many of your PRs shipped behind one? Exactly. Flags de-risk big launches all the time. Most changes ship without one.

Last year, the typical software team was using feature flags like this:

• Manually target themselves/their team to test in production
• Sometimes target specific users (or accounts)
• Flag only the biggest features (maybe ~10% of changes)
• Once they’re ready, just turn them ON for everyone right away
• Don’t monitor any change directly, but rely on SLOs and application-wide dashboards
• Use feature flags as kill switches if something goes wrong
• The growth team runs some experiments every quarter

This year, everything changed. The practices above do not scale with agents, and they miss what flags do best. Flags are the final safeguard, built for last mile delivery. Almost all de-risking layers for delivery (review, tests, CI, staging) stop before production. You can write 1,000 tests and do 1,000 code reviews, but none of it matters until the change proves safe with real customer traffic.

Last year’s approach falls short for two reasons: most teams do bad releases by default, and it’s very manual. To use flags to expect and mitigate failure, you have to use them consistently. Like, use them for everything (well, 100% of the changes that should be flagged). Traditionally, that would be ridiculous. Why spend 1–2 hours spinning up a flag, handholding it through the release process, and cleaning it up just to control a minor update?

Well, agents are why. They’ve made flags both cheaper and more critical. Flags are the most direct way to measure and controls each change directly. Feature flags operate at the frontier, the first step into the wilds of production. Anthropic and OpenAI have both made it clear: flags as the final safeguard is now the norm for teams building with agents. Flags have always been essential, but this is their true moment in the sun.

The frontier of feature flags

Of course, “use feature flags” isn’t enough to become cool and ship like Anthropic. Most modern teams are already using feature flags, but if they were to apply yesterday’s casual practices to the level of darkness and volume that agents create, it would fall apart quickly. We have to approach feature flagging in a new way. This requires two dependent changes:

1. Adopt the new primary job of the feature flag as de-risking agent delivery (how we expect failure)
2. Adopt the new primary mode of feature flagging as automatic (so it optimizes for human attention)

De-risking agent delivery

For flags to be the final defensive layer for agents shipping to production, teams have to use them everywhere. For many teams, that means going from 10% of PRs flagged to 50% (we’re a bit unique, but we’ve seen this trend internally). It also means getting serious about great release practices.

If we’re serious about providing the controls that balance agent autonomy, we need to flag a lot more and release a lot fancier. By fanciness, I mean releases that look like this:

• Testing in production
• A pre-made release plan with ~5 or more audience tiers by risk (using context attributes like customer size, region, and health)
• Target across multiple dimensions at once like user, device, facility, or even file (whatever maps to your business language)
• Multiple % steps to limit blast radius within each audience with gradual ramp up
• Approvals (where appropriate)
• Guardrail metrics in an A/B release experiment that shows whether this change made things worse
• Automatic rollbacks
• Automatic root cause analysis
• Autofix suggestions with PRs

Flags give the agent babysitting the release three things:

• Ultra-precise context for each change
• Deterministic results as a complement to its otherwise less deterministic de-risking methods
• Runtime control infrastructure to deliver changes, globally, in <200ms

As we’ve seen this year, agents do the most when you pair their reasoning with powerful tools. Flags give them the tools to take action in production and correct their own mistakes.

Automatic feature flagging

With that much more volume, the flag lifecycle also has to become nearly free. The two changes have to land together. Today, most changes ship without a flag. Even fewer get a mature, multi-step release. This is partly due to factors like team maturity and criticality, but largely due to the fact that using feature flags adds friction.

Using feature flags to manage multi-step releases adds even more friction. I remember at my previous company we came up with this awesome release checklist to de-risk changes across different audience segments. It worked really well, but it was expensive. Mostly, it cost me and a coworker hours on a Zoom call, clicking (and clicking some more) through hundreds of steps across dozens of changes so we didn’t miss an environment.

If we’re being honest, the previous generation of feature flag tools just wasn’t built for this. So we’ve been building new flag primitives for both: automatically add flags, define release plans (as fancy as you like), monitor guardrail metrics, and even clean up flags. Automate as much or as little as you want.

For some changes, agents can add their own flags, classify their own risk, auto-approve low-risk changes, pick a release plan, ship straight to production, monitor the change, and remove the flag when it’s done. We’re building the safety layer for autonomous delivery.