Reversibility Is the New Architectural Correctness

I used to spend a lot of time helping teams make permanent technical decisions. We'd evaluate, de-risk, build consensus. That rigor made sense when migrations cost 18 months. It's a different calculation when a well-directed set of agents can port a codebase in a week.

I recently read that a team rewrote both their iOS and Android apps in React Native using coding agents. Their reasoning wasn't the usual one — cross-platform consistency, fewer engineers, reduced surface area. It was simpler than that: if it turns out to be wrong, we can port back. Simon Willison flagged this in May 2026, alongside a note on a similar Bun rewrite, both pointing at the same shift. Mitchell Hashimoto put it plainly: "Programming languages used to be lock-in, and they're increasingly not so."

That's not just an observation about tooling. It's a change in the underlying economics of architectural risk.

The Cost Structure That Made "Correctness" Matter

For most of engineering history, the reason to agonize over architectural decisions was simple: rewrites were expensive. Not just in time, but in accumulated knowledge loss, coordination overhead, and organizational will. A migration that took 18 months didn't just cost engineering hours — it consumed a company's focus. You made the wrong call, you lived with it.

That cost structure shaped a whole philosophy of decision-making. Evaluate carefully. Run proofs of concept. Build consensus slowly. The point wasn't to find the objectively correct answer — there often wasn't one — it was to reduce the probability of making an expensive mistake.

The mental model was: decisions have permanence, so treat them accordingly.

What Changes When Porting Gets Cheap

Coding agents don't just accelerate development. They change which costs are variable and which are fixed. A lot of what made architectural migrations expensive — the mechanical work of translating patterns, updating boilerplate, refactoring interfaces — is now much closer to parallelizable and automatable. The residual cost is judgment: knowing what to preserve, what to rethink, what the new environment makes possible.

That shifts the calculus on risk. When the downside of a wrong architectural call drops from 18 months to a few weeks, the expected cost of experimentation drops with it. The right move isn't necessarily the one most likely to be correct forever. It might be the one that's most reversible if you're wrong.

I'd call this the Reversibility Criterion: prefer architectural decisions that leave the most options open, not the ones that feel most permanent.

This Isn't the Same as "Move Fast and Break Things"

There's a surface resemblance to the old move-fast startup mantra, but the logic is different. Moving fast and breaking things was about accepting quality debt in exchange for speed. The Reversibility Criterion is about accepting architectural uncertainty in exchange for optionality.

You're not lowering standards. You're changing what the standard is.

The old standard: get it right the first time, because you'll live with it for years.

The new standard: make decisions that you could undo if the world changes, or if you were wrong.

These lead to different choices. A team optimizing for traditional correctness might pick a language with the deepest ecosystem lock-in if it has the best performance profile for their use case. A team optimizing for reversibility might pick the one with the clearest contracts, the most portable data formats, the thinnest framework surface area — even if it's slightly slower today.

The Architectural Qualities That Now Matter More

Some decisions are structurally easier to reverse than others. In my experience, reversibility correlates with a few specific properties:

Thin integration surfaces. The more your system communicates through narrow, well-defined interfaces — APIs, schemas, message queues — the easier it is to swap what's behind them. The harder reversals are always in the places where things are deeply entangled.

Portable data. The hardest part of most migrations isn't the code. It's the data model, and specifically whatever assumptions are baked into it that don't translate cleanly. Decisions that keep data in standard formats and avoid proprietary storage primitives age better.

Explicit dependency graphs. If you can't easily enumerate what depends on what, you can't model the cost of changing it. Teams that invest in clear module boundaries don't just ship faster — they reverse cheaper.

None of these are new ideas. What's new is that they've moved from "nice to have for maintainability" to "directly tied to your risk exposure on architectural bets."

How the Risk Calculus Shifts for Every Technical Decision

The React Native example is visible because it's a full rewrite. But the same logic applies at smaller scales. Which database do you pick? Which message broker? Which ML framework? Which internal tooling stack?

For each of these, the old mental model was: this is a long bet, so optimize for the probability that the bet is right. The new mental model should be: this is a shorter bet than it used to be, so also optimize for what happens if it's wrong.

That means asking a different question at decision time. Not just "what's the best option?" but "what does it cost us if this turns out to be wrong in two years?" The answer to that second question should now carry real weight.

Teams that haven't updated their decision-making process are still running the old math. They're treating choices as permanent when the tools have made them increasingly temporary. They'll over-invest in evaluation and under-invest in escape hatches.

The Bigger Implication

There's a version of this that extends beyond individual architectural decisions. The same logic applies to vendor choices, to SaaS dependencies, to the AI model providers you build on top of. Portability isn't just a codebase property — it's a product strategy.

A year ago, I'd watch teams build deep integrations with a specific AI provider and shrug at the lock-in risk, because switching costs felt abstract. Now, when a competitor releases a meaningfully better model and your integration is tangled through five layers of prompt engineering and proprietary function calling, that lock-in has a real price. The teams who designed for swappability — thin wrappers, abstracted interfaces, model-agnostic evaluation pipelines — will pay a fraction of that cost.

The constraint has shifted. The question engineering teams should be asking themselves isn't "are we making the right permanent decision?" It's "are we making a decision we could change if we needed to?" The teams that internalize that shift first will have more options than the ones still optimizing for permanence in a world that's increasingly not.

Herbert Cuba Garcia is a Tech Director within AI, writing about engineering strategy, AI operating models, and how technology decisions play out at scale. More at cubagarcia.com.