Braden Wong

Rewrite Beside the Original

Why the best rewrites begin beside the original.

When I rewrite something, I don’t edit the existing version in place. Instead, I make a new version beside the old one and rewrite it there.

That changes the psychology of revision. The new version gives me a clean slate, while keeping the original means I don’t feel like I’m losing something great. That combination lets me go beyond the structural limits of the old version. I can let the new version become strange, ambitious, or even temporarily worse, because the thing I started with hasn’t been destroyed.

Keep the source; free the structure

The simplest version is a split screen. When I rewrite articles, I have the old article on the left and the new article on the right. The old one remains available as a source of details, turns of phrase, examples, and arguments, but it no longer dictates the shape of the rewrite.

  keep visible       rewrite freely
┌──────────────┐   ┌──────────────┐
│   ORIGINAL   │   │ NEW VERSION  │
│              │   │              │
│ details,     │ ↔ │ free         │
│ phrases,     │   │ structure,   │
│ examples,    │   │ a new shape  │
│ arguments    │   │              │
└──────────────┘   └──────────────┘
               compare

When several skills become one

I use the same pattern when combining several agent skills into one skill with supporting references. I create the new skill and its references first, while all of the older skills remain in the working directory. I can keep referring to them while I decide what belongs in the new version.

old skill A ─┐
old skill B ─┼─▶ unified skill
old skill C ─┘   + references
                      │
                      ▼
                    audit
                      │
                      ▼
              delete old skills

Once the new skill exists, I can ask an agent to audit the older skills still sitting beside it: did we carry every important instruction into the new skill or its references? Only after that check do I delete the older skills. The old files aren’t competing implementations anymore. They’re a checklist for completeness.

Why the old version stays until the end

There are two kinds of safety here. The first is practical: the original remains available for comparison, so omissions are easier to catch. The second is creative: because the original is safe, I don’t have to make every local edit defensible while I’m still discovering the new structure. A whole rewrite lets me stop negotiating with the old form.

preserve original
       │
       ▼
duplicate into a new copy
       │
       ▼
rewrite freely
       │
       ▼
compare against the original
       │
       ▼
replace: delete old, rename new

First, I preserve the original and make a working copy. I rewrite without protecting the old structure, then compare the finished version against its source. Only then do I delete the old copy and give the rewrite the original name.