Cheap code generation changed one term in the replacement equation. Producing a candidate implementation is faster and cheaper than it was. Everything determining whether that implementation can safely take over is unchanged, and the mismatch is where programmes now get into trouble.
Four boundaries, four recovery questions
Reversibility is not one property. It decomposes, and the components fail independently.
Code and configuration. Can the prior version still operate against the present state? A rollback into a schema that moved is not a rollback.
Data and schema. Can writes made by the new system be restored or reconciled without unacceptable loss? Some migrations change data irreversibly.
External actions. What has already been sent, paid, notified, or changed? This is the boundary with no technical answer.
Responsibility. Who operates during recovery and through the unresolved transition? A recovery plan naming no operator is a description.
A rollback that restores old code after customer notifications were sent has recovered one boundary. Those messages are real, and the recovery record includes communication and reconciliation work performed by people.
Staging limits exposure, it does not prove isolation
Limited-exposure release with appropriate signals and attention to shared dependencies is the sound pattern, and the qualification is the operative part. Shared dependencies defeat apparent isolation: a canary consuming the same cache, quota, queue, or downstream service as production is not isolated from it.
So isolation is demonstrated for the actual system rather than inferred from the rollout shape. The strangler pattern carries the same caution — coexistence needs seams, transitional architecture, and a decision about which side holds the authoritative record, and none of that gets cheaper because the new component was generated.
A single cutover is not excluded. It requires evidence proportionate to its consequences, and the requirement scales with the count of effects that cannot be reversed.
What generation did not make cheaper
Three costs are untouched, and together they dominate a replacement.
Establishing legacy behaviour. The incumbent’s undocumented exceptions, the special cases handled by one branch nobody remembers writing, the workarounds encoded as data. Generation produces candidate implementations and produces no evidence about the system being replaced.
Verifying the candidate. A generated implementation and generated tests can share the same mistaken assumption, so a passing suite is weaker evidence than it looks. Verification against independently grounded requirements or a domain-owned reference is what separates them, and that work is human and slow.
Reconciling the cutover. Data migration, dual running, and the compensating actions for effects that cannot be reversed. All proportional to the business process rather than to the code.
The consequence is a widening gap: the build shrinks, the surrounding work does not, and a plan sized on build estimates is wrong by the ratio between them.
Build scope, release scope, commitment scope
Three scopes are separable and generation has decoupled them further.
Build scope is what gets constructed. Release scope is what reaches users. Commitment scope is what the organisation has undertaken to keep running.
Cheap generation lets build scope run ahead of the other two at little cost, which is genuinely useful — several candidate implementations can exist before anything is chosen. The failure is letting build scope drag commitment scope behind it, so that a system exists, is demonstrated, is relied upon, and acquires a commitment nobody made deliberately.
Keeping them distinct is what makes disposability real. A generated candidate that is never released costs its generation and nothing else. One that quietly acquires users costs whatever it takes to keep or remove it.
The rule
What stays fixed is that reversibility is assessed per boundary, with the external-action boundary having no technical remedy. What changes is the cost of producing the replacement, and that term is now small enough that planning around it produces the wrong plan.
The assessment lists the users, writes, external actions, and dependent systems affected by each step; defines success, pause, and recovery signals with a named actor; verifies backup, restoration, or reconciliation with the exercise scope recorded; and identifies which actions need compensating work rather than a technical rollback.
Not to be confused with
A prohibition on speed. Faster construction is a real gain, and taking it is correct. The error is assuming the gain propagates to the parts of the work it does not touch.
Reversibility as a property of the deployment. A reversible deployment mechanism and a reversible business effect are different claims. The second is the one the cutover decision needs.