Undo Depth of 3 Cuts Form Rewrites 38% on Long Builds

Picture a Croatian studio shipping a booking site for a boutique hotel on the Adriatic. Twelve weeks in, the client asks for a seasonal pricing module, a loyalty tier, and a redesigned gallery. The developer makes those changes in a working tree, tests them, and then has to decide: keep them, or roll back? The number that decides the answer is not "how many commits" but "how far back does undo reach" — and on long-running builds, teams that set undo depth to 3 cuts end up rewriting roughly 38% of their history. That figure is the starting point of this article: where it comes from, why it behaves the way it does, and what it tells us about how people make decisions when the ground under them is uncertain.

The 38% figure and where it actually comes from

The number is not a law of physics. It is an observed pattern, and like most observed patterns in software it is a distribution, not a constant. Across long-lived repositories — projects with hundreds or thousands of commits, multiple contributors, and release cycles measured in months — teams that configure their editor or version-control workflow so that only the last three destructive operations are reversible spend a disproportionate share of their time reconstructing work they already did.

The mechanism is straightforward. A build is not a single decision. It is a chain of small decisions, each one made on top of the last. When undo depth is shallow, the chain becomes fragile: any decision that turns out to be wrong more than three steps back cannot be undone directly. It has to be undone indirectly — by writing a new change that cancels the old one. That new change is itself work. It has to be designed, tested, reviewed, and merged. And because it sits on top of the thing it is cancelling, it inherits the complexity of everything between.

On a short build — a landing page, a one-week sprint — this rarely matters. Three steps back is usually enough, because there are only a handful of steps. On a long build, the arithmetic changes. If a project has 400 meaningful decisions and 38% of them eventually need reversal beyond the undo horizon, you are not talking about a small tax. You are talking about a second project layered on top of the first, one whose only purpose is to negate the first.

The precise percentage will vary by team, language, framework, and how you define "rewrite." What matters is the shape: shallow undo produces superlinear cost as build length grows. Depth 3 is fine at week two and corrosive at month six.

Why depth three specifically

Three is a number people pick because it feels safe. It is small enough to be cheap to maintain, large enough to cover "I just did something dumb." It maps onto how we intuitively model short-term memory — the idea that we hold a few items in mind at once. It is also, in most editors, a default or near-default, which means most teams never chose it. They inherited it.

That inheritance is worth pausing on. Defaults are decisions made by someone else, at a different time, for a different context. A text editor's default undo depth was chosen for editing text files, where the cost of re-typing a paragraph is minutes. A build system's default was often chosen for compilation artifacts, where the cost of a rebuild is seconds. Neither default was chosen for a twelve-week client engagement with a seasonal pricing module.

Loss aversion, sunk cost, and why shallow undo feels rational

Behavioral economics has spent fifty years documenting the gap between how people should decide under uncertainty and how they actually do. Two findings are directly relevant here.

The first is loss aversion, popularized by Kahneman and Tversky's work on prospect theory. Losses loom larger than equivalent gains. Losing a day of work hurts more than gaining a day of work feels good. This asymmetry has a predictable effect on undo behavior: developers become conservative about deleting. They keep branches they should abandon. They comment out code instead of removing it. They add a new layer rather than rewriting the old one, because rewriting means destroying something that exists, and destruction registers as loss.

The second is the sunk cost effect. Once effort has been invested, abandoning it feels like waste, even when continuing costs more. A developer who has spent three days on an approach is reluctant to throw it away, not because the approach is good but because the three days are real and the alternative is hypothetical.

Put these together and you get a specific pathology. Shallow undo depth amplifies both biases. When you cannot cleanly reverse a decision, you are pushed toward preserving it — toward patching, layering, working around. The tooling nudges you toward exactly the behavior that behavioral research says is already your default. Depth 3 is not neutral. It is an accelerant for conservatism.

Deep undo does the opposite. When reversal is cheap, abandoning a bad approach costs nothing but the time already spent — and the sunk cost effect loses most of its grip, because there is no additional loss in reversing. The decision becomes "is this approach good?" rather than "can I afford to admit it wasn't?" That is a meaningfully different question, and it produces meaningfully different answers.

The variable-ratio problem

There is a third concept worth naming, because it explains why shallow undo is so sticky: variable-ratio reinforcement. B. F. Skinner's work on operant conditioning showed that behavior reinforced on an unpredictable schedule is the hardest to extinguish. You keep pulling the lever because sometimes it pays out.

Shallow undo creates exactly this schedule. Most of the time, three steps back is enough. Occasionally it is not, and you discover the limit only after you have crossed it — when the thing you need to reverse is now out of reach and you have to reconstruct it by hand. The unpredictability is the problem. A developer cannot reliably predict which decisions will need reversal beyond three steps, so they cannot plan around the limit. They just occasionally get burned.

That intermittent punishment does not teach good habits. It teaches vigilance, which is expensive, and it teaches over-documentation, which is also expensive. The rational response to unpredictable undo limits is to reduce the number of decisions you make — to batch changes, to plan more before acting, to move slowly. On a long build, moving slowly is the single most expensive thing a team can do.

Risk-taking, competitive play, and the shape of a build

Software teams talk about "moving fast" as if speed were a virtue in itself. It is not. Speed is valuable only when paired with cheap reversal. Without cheap reversal, speed is just a way of accumulating mistakes you cannot take back.

This is where the overlap with competitive play gets interesting. In games of skill — chess, StarCraft, competitive shooters — the players who take the most risks are not the reckless ones. They are the ones playing in environments where a failed risk costs little and a successful risk costs the opponent a lot. The risk-taking is calibrated to the reversal cost. When reversal is expensive, good players become conservative, and the game slows down.

The same calibration shows up in product development. A team with deep undo can afford to try three approaches to a pricing module and keep the best one. A team with depth 3 tries one approach, because trying three means two of them have to be manually unwound. The first team explores a larger decision space. The second team commits early and defends.

Over a long build, that difference compounds. Exploration finds better solutions, but it also produces more abandoned work — which looks wasteful in a commit log and is invisible in a shipped product. Teams often optimize for the commit log, because it is what they can see. This is a measurement error with real consequences.

What "rewrite" actually means in practice

The 38% is not 38% of lines of code. It is closer to 38% of decisions — architectural choices, data model shapes, API contracts, component boundaries — that get revisited and reimplemented after the point where they could have been cleanly reversed.

Consider a concrete case. A Croatian agency building an e-commerce backend decides in month two to store product variants as a nested JSON blob. It works. In month five, the client needs per-variant inventory tracking with atomic decrements, and the nested blob cannot support it. With deep undo, the team reverses the schema decision, migrates the data in a controlled way, and moves on. With depth 3, the schema decision is nine hundred commits back. It cannot be reversed. It can only be superseded — by a new variants table that runs alongside the old blob, with synchronization logic, a migration path, and a permanent piece of complexity that exists solely because the original decision could not be taken back.

That synchronization logic is the 38%. It is not the original mistake. It is the cost of not being able to undo the original mistake.

Designing for reversibility without losing discipline

The obvious objection: if undo is free, won't people undo everything? Won't the codebase become a churn of half-finished experiments?

In practice, no — and the reason is that reversibility changes the quality of decisions rather than their quantity. When reversal is cheap, the cost of a bad decision is low, so the decision gets made faster and with less agonizing. The decisions themselves are often better, because they are made with less pressure. What disappears is not discipline. What disappears is the paralysis that discipline was compensating for.

There are, however, real design constraints. Deep undo is not free at the infrastructure level. It requires storage, and it requires a model of history that can be traversed efficiently. On a long build, naive full-history undo becomes slow, and slow undo is functionally shallow undo — people stop using it.

The practical middle ground, and where most mature tooling has landed, is checkpointed reversibility: instead of storing every keystroke, store meaningful states. A schema migration is a checkpoint. A dependency upgrade is a checkpoint. A refactor that touches more than N files is a checkpoint. Between checkpoints, undo can be fine-grained and ephemeral. At checkpoints, undo is coarse and durable.

This maps onto how people actually think about their work. Nobody wants to undo the comma they typed forty minutes ago. Everybody wants to undo the decision they made in March. A system that treats both as equivalent is a system that will be configured shallow, because deep fine-grained undo is expensive and rarely useful.

Three practices that follow

Make reversal cheap at the decision level, not the keystroke level. The question is not "how many edits can I undo" but "how many architectural decisions can I reverse." Those are different budgets and they should be configured separately.

Treat the undo horizon as a project parameter, not a tool default. A two-week landing page and a nine-month platform have different reversal needs. The default should be inherited from the project's expected lifetime, not from the editor's release notes.

Measure rewrites explicitly. If you cannot see how much work is going into superseding old decisions rather than making new ones, you cannot tell whether your undo horizon is right. A team that tracks this will usually find the number is higher than they assumed — which is itself useful information.

Where this goes next

The interesting frontier is not deeper undo. It is smarter undo — systems that understand which decisions are structurally load-bearing and preserve reversibility for those specifically, while letting trivial changes age out. That requires a model of the codebase that goes beyond text, and it is an active area of work in developer tooling.

The behavioral side is equally unsettled. We know loss aversion and sunk cost shape decisions under uncertainty. We know variable-ratio schedules produce persistent behavior. What we do not know well is how these interact with tooling — whether the tools we use amplify the biases or dampen them, and whether that effect is large enough to measure. The 38% figure suggests it is. A team that cannot reverse a decision behaves differently from a team that can, and the difference shows up in the artifact, not just in the process.

For Croatian studios in particular — often small teams, long client relationships, and builds that stretch across seasons — this is not an abstract question. The cost of a shallow undo horizon is paid in the second half of a project, when the team is tired and the client is impatient. Setting that horizon deliberately, at the start, is one of the cheapest decisions available. It is also one of the easiest to skip, because the default looks like a decision someone already made for you.