Skip to content

Burn the Boats — Commitment-Forcing Deprecation

Remove the old path entirely on a hard deadline — irreversible deprecation forces full commitment and stops the team anchoring to what you are replacing.

The problem with gradual migration

When teams support old and new workflows in parallel, neither wins. Users stick with what they know. The team splits engineering attention across both. The product attracts users whose main criterion is "doesn't change things." Gradual sunset timelines extend this split indefinitely.

The core issue is credibility — the credible-commitment problem that Schelling named. A soft deprecation signals that the old path might persist indefinitely, which is often true. This pattern comes from the nibzard/awesome-agentic-patterns catalog, which applies Thomas Schelling's credible-commitment theory from 'The Strategy of Conflict' (Harvard University Press, 1960): removing retreat options makes a commitment believable to both users and the team itself.

What this pattern looks like

A hard-deadline removal with three components:

  1. Irreversible commitment — you remove the old path, rather than hide it or flag it deprecated. No opt-out period that stretches.
  2. Migration path — you give users explicit alternatives and the reasons before removal, not just a notice that something is going away.
  3. Hard deadline — a specific date or milestone, announced publicly, after which the old feature stops working. AMP set roughly a 60-day window.
graph TD
    A[Decision: commit to new paradigm] --> B[Set hard removal deadline]
    B --> C[Publish migration path + rationale]
    C --> D[Remove old feature on deadline]
    D --> E{User response}
    E -->|Frontier users| F[Stay — aligned with direction]
    E -->|Conservative users| G[Churn — misaligned with direction]
    F --> H[Product focus unlocked]

Distinguishing this from ordinary deprecation

Regular deprecation is reversible in practice. User pushback often extends timelines, soft deadlines slip, and the old path survives indefinitely. This pattern is defined by deliberate irreversibility:

Ordinary deprecation Burn the boats
Soft deadline, often extended Hard deadline, publicly committed
Old path hidden or flagged Old path removed
Team still supports both Team commits fully to new path
Conservative users stay Conservative users churn

The distinction matters because the user-selection effect only works with genuine removal. Users who need to self-select out must believe the deadline is real.

The AMP case study

AMP (an AI coding tool company) shut down their VS Code extension on a roughly 60-day hard deadline, publicly stating "the sidebar is dead." Their stated rationale: "It's just a focus thing for us. We can't do that without taking our eye off the thing that you all think is 100 times more important" — referring to their headless/factory agent paradigm over interactive sidebar UX. AMP framed their product philosophy as needing to "totally re-earn all usage...every 3 months," explicitly rejecting anchoring to installed base. [Source: nibzard/awesome-agentic-patterns]

The timeline of the AMP deprecation (~60 days) is sourced from the nibzard catalog, not from a direct AMP announcement.

When to apply this pattern

This pattern fits teams adopting agentic-first workflows who need to stop supporting older interactive patterns. The conditions that justify it:

  • The old and new paradigms require fundamentally different infrastructure or mental models — not just UI variations
  • Split support is measurably slowing the new paradigm's development
  • Conservative users are actively slowing adoption by requesting old-path features
  • The team has a viable migration path to offer, not just removal

Not appropriate for: incremental feature improvements, situations where no migration path exists, or cases where removal would cause harm to users with no alternatives.

The trade-off

Gains: internal focus, engineering momentum on the new paradigm, user base self-selected for the direction you're building toward.

Accepts: short-term churn from users who depended on the old path. This churn is intentional and a feature of the pattern, not a side effect to minimize.

Safety boundary: not an agent design pattern

The nibzard catalog entry warns against applying irreversibility logic to AI agent systems themselves. Giving agents irreversible operations with broad permissions creates severe risk from prompt injection or context overflow — the case for blast-radius containment. This pattern applies to product strategy — what features a team maintains or removes — not to agent autonomy design. Design agents with reversible, bounded operations.

Key Takeaways

  • Hard deadlines create believable commitment — soft deadlines do not
  • Migration paths are required alongside removal; users need alternatives, not just notice
  • The user-selection effect is intentional: conservative users churn, frontier users stay
  • This is distinguishable from ordinary deprecation by irreversibility and intentionality
  • Apply to product feature decisions only — not to agent operation design, where irreversibility is a risk, not a tool
Adopted — practitioner-sourced, corroborated Last reviewed: 2026-06-12
Feedback