Progressive-Delivery on Coffee or Blog

Release Discipline in the Age of AI-Accelerated Development

Mon, 17 Aug 2026 00:00:00 +0000

A maturity model for shipping fast without breaking customer trust.

I made an earlier argument that deploying code and releasing a feature are not the same event, and that treating them as one causes unnecessary risk. That argument still holds. But the environment it was written for has changed.

AI-assisted development has made writing and shipping code dramatically cheaper. A change that used to take a sprint now takes an afternoon. That’s a genuine gain, but it doesn’t automatically make the judgment around releasing that change any faster or better. When the cost of producing change drops and the discipline around exposing change doesn’t rise to match it, the result is exactly what customers are describing: things move, break, or reappear differently, without warning, more often than they can absorb.

Here’s the core claim: in 2026, the bottleneck in software delivery is not how fast we can write code. It’s how deliberately we control who sees a change, when, and with what warning. AI removes the first constraint. It makes the second one more important, not less.

This isn’t a call to slow engineering down. It’s a call to stop routing all of that new speed straight at the customer, unfiltered.

The symptom we’re solving for

Customers aren’t complaining that we ship too much. They’re complaining about three specific things, and it’s worth being precise because each has a different fix:

Rate of change — things they learned last month look or behave differently now, with no signal it was coming.
Forced change — a workflow they depend on changed or disappeared, and they had no way to stay on the old behavior while they adjusted.
Unpredictability — they can’t tell the difference between “this is a bug” and “this is intentional,” because both arrive the same way: silently.

None of these are solved by shipping less. All three are solved by separating four things we currently bundle into one event: code lands in production, a feature becomes visible, a customer is told about it, and an old behavior is retired. Each deserves its own timeline, its own owner, and its own decision.

The four-question test for every user-visible change

Before a change reaches a real customer, someone should be able to answer:

Question	Answer determines
Is it visible?	Whether it needs a flag at all
Is it disruptive?	Whether it needs staged rollout or can go straight to 100%
Is it reversible?	Whether we need a dual code path, or a simple toggle is enough
Does it remove something?	Whether it needs a deprecation notice and a minimum notice period

A change that’s invisible (backend refactor, performance work) skips all of this, deploy it and move on. Everything else routes through the toolkit below. The mistake teams make under AI-accelerated velocity is treating all changes like the first category because the code was cheap to produce.

Blast-radius classification

Use this before merge, not after a customer complains. It should take seconds, not a meeting.

Class	Example	Rollout pattern	Notice required
Invisible	Refactor, perf work, dependency bump	Deploy directly	None
Visible, additive	New optional feature, new button	Flag → rings → GA	Changelog entry
Visible, behavioral	Changed default, changed workflow	Flag → opt-in beta → staged % → GA	Advance in-app notice + changelog
Disruptive / breaking	Removed capability, forced migration	Dual path, minimum notice window, opt-out during transition	Direct communication, not just changelog

The AI-specific risk is that classes 2–4 get produced at the same velocity as class 1, and without this checkpoint they get shipped at that velocity too. The checkpoint is cheap. Skipping it is what customers are feeling.

The toolkit

1. Feature flags, but with a lifecycle, not just an on/off switch

Flags fail long-term not because teams don’t use them, but because nobody owns their end state. A flag that’s still in the codebase eighteen months after full rollout is a liability, not a safety net. Every flag needs a stated life stage:

Rollout flag (temporary, by default): exists to ramp a change safely. Has an owner and an expected removal date at creation time. Options at end of life:
- Graduate — feature is fully rolled out and stable → flag is deleted, new behavior becomes the only behavior.
- Revert — didn’t work → old path stays, new path is removed.
- Extend deliberately — a real reason exists to keep ramping slowly (enterprise contracts, regulatory cohorts) → re-approve with a new date, don’t let it drift by default.
Operational flag (long-lived, by design): kill switches, ops-only toggles. These are allowed to live indefinitely, but should be inventoried separately from rollout flags so the two don’t get confused in review.
Permission / entitlement flag: controls who gets a capability (plan tier, beta cohort, region). Long-lived by design, owned by product.

Ownership split that matters: engineering owns whether the flag exists and works; product/support own when it flips for whom. That split is still correct, it just now needs a flag registry with an expiry date on every rollout flag, reviewed monthly, or the flag count grows faster than the org’s ability to reason about it. AI-generated code makes it trivially easy to wrap a new flag around everything; that’s a reason to enforce the registry harder, not skip it.

2. Progressive rollout rings

Don’t choose between “ship to everyone” and “ship to no one.” Use rings, and pick the entry ring based on the blast-radius class above:

Internal — team, then company-wide dogfooding.
Design partners / opt-in beta — customers who explicitly asked to try new things early. This is where self-service enablement lives (see below).
Staged percentage — 5% → 25% → 100%, gated on real usage signals and support ticket volume, not a calendar date.
General availability — announced, documented, supported.

A change only needs to pass through every ring if it’s disruptive. Additive, low-risk changes can compress rings 3–4. The point isn’t ceremony, it’s that someone decided how much exposure this change gets before it got any, instead of exposure being a side effect of when the deploy happened to land.

3. Self-service enablement (beta opt-in)

Give customers a way to choose to be early, rather than discovering they’re early. Concretely: an in-product “early access” or “labs” area where customers can turn on features ahead of GA, with a visible way to turn them back off. This does two things at once:

It converts “why did this change on me” into “I opted into this.”
It gives you a self-selected, motivated feedback cohort before wide rollout, which is a better signal than support tickets after the fact.

The precondition for this to work: opted-in features must be genuinely reversible by the customer. If turning it off doesn’t actually turn it off, don’t offer it as opt-in, that’s a forced change wearing an opt-in costume, and customers notice the difference immediately.

4. Change communication, tiered to disruption level

Not every change deserves the same announcement weight. Matching the tier from the blast-radius table:

Additive: changelog / release notes. Low ceremony, always shipped.
Behavioral: in-app notice before the change reaches a user’s account, plus changelog. Should say what’s changing and, if relevant, how to preview it early via opt-in beta.
Disruptive / breaking: direct communication (email, CSM, in-app banner with acknowledgment) with a stated timeline, not just a mention in release notes. If there’s a deadline for an old behavior going away, that deadline should be visible to the customer well before it arrives, not just to us.

A useful gut check: if a customer would reasonably say “I wish someone had told me,” the tier was too low.

5. Deprecation without forced change

The single biggest driver of the “forced change” complaint is removing something before the data says it’s safe to. The pattern that avoids it:

New path ships behind a flag, old path stays live.
Both paths run in parallel long enough to gather real usage data, not a fixed arbitrary window, but until usage of the old path is actually low or zero.
A minimum notice period is announced before the old path is scheduled for removal, sized to the disruption class (days for a minor UI tweak, months for a workflow customers have built process around).
Only once notice has elapsed and usage has dropped does the old path get deleted, as its own change, separately reviewed from the feature that replaced it.

This costs engineering effort (two paths, temporarily) in exchange for the thing customers are actually asking for: predictability. That trade is almost always worth making for anything customer-facing.

What AI-accelerated development changes, specifically

The proposal rate goes up, the review/rollout rate doesn’t automatically follow. The gap between them is where uncontrolled change leaks out. Treat rollout classification as a required step in the definition of done, not an optional nicety, it’s the part of the pipeline that didn’t get faster, so it needs to be protected, not skipped under pressure to keep pace.
Flag sprawl accelerates. If it’s cheap to generate a flag-wrapped change, flags will be created faster than they’re retired unless the registry-and-expiry habit from the toolkit above is enforced, not just recommended.
“It’s just a small change” stops being a reliable signal. AI can produce a large, behaviorally significant change with the same apparent effort as a small one. Blast-radius classification should be based on what the change does, not how much manual effort it took to write, that correlation has broken.
Volume of change is a communications problem now, not just an engineering one. If ship velocity increases, either communication cadence scales with it, or customers experience the increase as noise. Product/support capacity to write good change notices becomes a real constraint on release pace, plan for it explicitly rather than discovering it during a rollout.

A maturity model to self-assess against

Level	Deploy vs release	Flags	Communication	Deprecation
0 — Coupled	Deploy = release, always	None, or ad hoc	Release notes after the fact, if at all	Rip and replace
1 — Flags exist	Some features flagged	Used inconsistently, no registry	Changelog exists	Removal decided by engineering alone
2 — Rings defined	Standard for risky changes	Registry exists, no expiry discipline	Tiered by change type	Notice periods exist but informal
3 — Customer-facing control	Default practice	Expiry dates enforced, monthly review	Self-serve beta / early access live	Data-gated removal, formal notice
4 — Governed change contract	Assumed, invisible as a decision	Flags treated as inventory with owners	Change comms scale with ship velocity by design	Deprecation SLA is a documented customer commitment

Most orgs feeling the pain described at the top of this post are sitting between Level 0 and 1, while their code output has jumped to what used to require a Level 3 org’s engineering throughput. That mismatch, velocity outrunning governance, is the actual root cause, not “we ship too much” or “AI is risky.” The fix is closing the governance gap, not throttling the code.

Getting started, in order

Adopt the four-question test and blast-radius table as a required checklist step before merge for anything customer-visible. This alone catches most of the “forced change” and “no warning” complaints.
Stand up a flag registry with expiry dates. Even a spreadsheet beats nothing. Review monthly.
Define your rings and who has authority to move a change from one ring to the next.
Ship a self-serve early-access surface, even a minimal one. It reframes the relationship from “this happened to me” to “I chose this.”
Write a deprecation SLA, minimum notice periods by disruption class, and hold to it publicly. This is the fastest way to rebuild trust with customers who’ve been burned by forced changes before.

The bottom line

AI didn’t create the need for release discipline, it just removed the natural speed limit that used to give teams cover for not having it. The teams that get faster and keep customer trust in 2026 aren’t the ones writing more code carefully. They’re the ones who separated “we built it” from “you see it” a long time ago, and are now deliberately re-tuning that separation for a world where the first half of that sentence happens ten times faster than it used to.

Deploy fearlessly. Release deliberately. That was true before AI. It’s the whole game now.

Decoupling Deployment from Release: An Architectural Imperative

Tue, 30 Sep 2025 00:00:00 +0000

Photo by Patrick Konior on Unsplash

We need to talk about how we ship software. Not because we’re doing it wrong, but because we can do it so much better, for our customers, for our colleagues, and for ourselves.

The Core Problem: Deployment Isn’t Release

Here’s the shift we need to make: deploying code and releasing features are not the same thing, and they shouldn’t happen at the same moment.

When we conflate deployment with release, we create unnecessary risk and friction. We deploy code to production, and suddenly a feature is live, ready or not. If something goes wrong, we scramble. We hotfix. We roll back entire deployments, potentially affecting unrelated changes. We make our product and support teams reactive instead of strategic.

There is a better way.

Why This Matters: Safety First

Our customers trust us with their business. Our colleagues across product, support, and operations depend on stable, predictable releases. When we tie deployment directly to feature availability, we put both at risk.

Safe software releases mean:

Our customers experience fewer disruptions
Our support team can prepare for changes before they go live
Our product team can control the narrative and timing of new features
Our engineers can deploy confidently, knowing they have safety nets in place
We can see the impact of our changes

This isn’t about adding bureaucracy. It’s about adding control.

The Mindset Shift for Engineers

I know what some of you are thinking: “This sounds like more process. More overhead. More barriers between my code and production.”

Let me reframe it: What if deployment was easier because it was safer? What if you could push code to production multiple times a day without the anxiety of “did we just break something for customers?”

This requires us to think differently:

Code goes to production dark, deployed but not activated
Features are controlled by flags, not by deployment timing
Your code can live in production for days or weeks before anyone uses it
When issues arise, you flip a switch instead of rolling back a deployment

This is actually more engineering control, not less. You own the technical deployment. Product and support teams own the feature release timing. Everyone wins.

Empowering Product and Support

Our product managers understand customer needs, market timing, and strategic rollout. Our support team knows when they’re ready to handle inquiries about new features. Our documentation should be created in production.

When we give them control over feature flags, we put release decisions in the hands of the people best positioned to make them. Engineering provides the capability; product and support control the activation.

This isn’t about taking power away from engineering, it’s about giving everyone the right kind of power.

Stop Removing What People Still Use

We’ve all been there: a feature is marked for deprecation, so we rip it out. Then we discover customers were still using it, or they needed more transition time.

With feature flags and dual code paths, we can:

Run old and new implementations side by side
Give customers time to migrate naturally
Gather actual usage data before removal
Roll back feature changes without rolling back deployments

We keep both paths alive until we know the old one isn’t needed. Data drives decisions, not assumptions.

Creating Dual Code Paths

The technical pattern is straightforward:

if (featureFlag.isEnabled('new-checkout-flow')) {
  // New implementation
  return enhancedCheckout();
} else {
  // Current implementation
  return traditionalCheckout();
}

This enables:

Rapid feature releases, toggle a flag, feature goes live
Instant rollbacks, toggle it back if issues arise
Gradual rollouts, enable for 10% of users, then 50%, then 100%
A/B testing, compare new vs. old with real data
Safe deprecation, maintain the old path until usage drops to zero

![[Excalidraw/Rollback Comparison.excalidraw]]

![[Excalidraw/Progressive Rollout.excalidraw]]

Yes, you maintain two paths temporarily. But the flexibility and safety are worth it.

We Already Test in Production, Let’s Do It Right

Here’s an uncomfortable truth: we all test in production. Even with the best staging environments, production has data patterns, load characteristics, and edge cases we can’t fully replicate.

Feature flags let us test in production safely:

Enable new features for internal users first
Roll out to beta customers who opt in
Gradually expand to broader audiences
Monitor in real time and react instantly

Instead of pretending we don’t test in production, let’s acknowledge it and build systems that make it safe and controlled.

Making Monitoring and Observability Easier

When features are flag-controlled, monitoring becomes clearer:

Dashboard metrics tagged by feature flag status
Alerts that distinguish between feature issues and infrastructure issues
A/B comparison of performance between flag states
Clear correlation between flag changes and system behaviour

![[Excalidraw/Observability Dashboard.excalidraw]]

You’ll spend less time debugging “what changed?” because you’ll know exactly what changed and when.

This Is About Your Value

Every engineer brings immense value. You solve complex problems. You build systems that serve customers. You keep the platform running.

This approach amplifies your impact:

Deploy more frequently without stress
Spend less time on hotfixes and emergency rollbacks
Focus on building new capabilities instead of managing release logistics
See your features succeed because they’re released at the right time, to the right users

Your technical expertise deserves better tools. Feature-flagged releases are those better tools.

Getting Started

We don’t need to transform everything overnight. Here’s how we can begin:

Start with your next major feature, wrap it in a feature flag
Integrate flags into your monitoring, make flag status visible in dashboards
Coordinate with product and support, let them control release timing
Gather data before deprecation, keep old code paths until usage proves they’re unnecessary
Share what works, as teams succeed with this approach, spread the practices

This is a journey, not a destination. Each team can adopt at their own pace.

The Bottom Line

Separating deployment from release isn’t just a technical practice, it is a philosophy of safety, control, and collaboration. It acknowledges that great software delivery involves engineering excellence and thoughtful release management.

We have the talent. We have the technical capability. Now let’s build the practices that let us ship with confidence.

Let’s deploy fearlessly and release deliberately. Our customers, our colleagues, and our code deserve nothing less.