Field Note: Small Slices Beat Big Rewrites

Field notes are the short version: one habit, one reason it earns its place. This one is about the urge I have to talk myself out of most often — the full rewrite — and why I keep choosing small, reversible slices instead, even when an AI agent is cheerfully volunteering to redo the whole thing for me.

There’s a companion piece on cutting new work into slices so an agent stays reviewable: Small Slices Beat Big Bang AI. This note is about the other direction — the temptation to throw out code that already works and rebuild it clean.

The rewrite always looks cheaper than it is

A messy system is annoying to read, so “just rewrite it” feels like relief. But the messy version has a hidden asset the blank page doesn’t: it survived contact with reality. Every weird branch in it is usually a bug someone hit, an edge case someone reported, a 2am fix that’s load-bearing now. A rewrite starts by deleting all of that hard-won knowledge and betting you’ll rediscover it before your users do.

That bet was already a bad one. AI tilts it further, because an agent will confidently produce a fresh, plausible version of the whole module in one shot — and plausible is exactly the failure mode. Now you’ve traded a system you understood and distrusted for one you don’t understand and haven’t earned the right to trust yet.

Strangle it, don’t replace it

The move I reach for instead is the boring one: wrap the old thing, route one piece at a time through the new thing, and delete the old piece only once its replacement has been proven in place. The system keeps running the entire time. There’s never a dramatic switchover day — just a slow shift where more and more of the work quietly flows through the new path.

It’s slower in the way that compounding is slower. Each slice is small enough to review honestly, ship on its own, and — the part I care about most — back out cleanly if it’s wrong.

A rewrite is a bet you’ll be right about everything at once. A slice is a bet you can undo.

Reversibility is the actual feature

The reason I trust slices isn’t that they’re tidy. It’s that each one has a way back. When a slice misbehaves on the day it matters, the question I want a fast answer to is “how do I get to where I was, and how long does that take?” With a slice, the answer is “revert one small change.” With a big-bang rewrite, the answer is too often “we’re committed now,” which is not an engineering plan — it’s a hope.

This is the same restraint behind every safe-automation habit I keep banging on about: keep the unit of change small, keep the undo obvious, and keep a human deciding at each checkpoint instead of rubber-stamping a giant leap. It’s also why this site is built in numbered slices — one scoped change, validated, committed, opened as a small PR that does exactly one thing.

The agent is genuinely good at the rewrite-shaped task — generating a lot of coherent code quickly. That’s precisely why the discipline has to come from me: let it do the fast part inside a small, reversible boundary, and keep the big-bang energy on a leash. If you’re trying to modernize something real without betting the whole system on one heroic diff, I’m happy to compare notes.