Modernize legacy code
without changing what it does

Every engineering org has one. A file — a promise machine, a billing engine, a permissions layer — that is two thousand lines long, has no meaningful tests, and is maintained by nobody because the person who understood it left in 2021. It works. You are terrified of it. Every quarter someone proposes rewriting it, estimates the risk, and quietly backs away.

The reason a rewrite is terrifying isn't the writing. It's that you have no way to prove the new version behaves like the old one. The old behavior isn't written down anywhere except in the code itself — including the accidental behavior, the bug some downstream system now depends on, the edge case nobody remembers.

The original is the specification

So don't write the spec. Run it. The legacy module, exactly as it is, is a perfect and complete description of its own behavior — bugs, quirks, and all. rederive's brownfield mode keeps the original running as a live oracle: you propose a clean refactoring, and every candidate unit is checked against the retained original on generated inputs it never saw.

This is the inverse of a normal rewrite. A normal rewrite trusts that you understood the old code. This trusts nothing — it executes both and compares. Where they diverge is either a bug you're choosing to fix (documented) or a behavior you have to preserve (now captured). Either way you find out, mechanically, instead of finding out in production.

Yes — even the parts you think are unverifiable

"But my legacy code isn't a pure function. It has timers, callbacks, concurrency, network calls." Good — those are exactly where the fear lives, and they're handled:

• — Time — timers and the microtask queue run on virtual time: the scheduler is injected and driven by the harness, so a race between a timeout and an awaited reply becomes a deterministic, replayable function of the timeline. A dropped clearTimeout that leaks is caught even when the output looks identical.
• — Concurrency — genuinely concurrent code is verified by owning the message scheduler and checking the space of interleavings, scaled past brute force with partial-order reduction. A concurrency contract (interleaving-invariant output, a max-in-flight bound) is proven, not hoped.
• — I/O — the network boundary is injected and replayed; the unit is verified against the recorded protocol, not the live internet.

These aren't hypotheticals. The method is validated on real modules — a promise library, a redirect state machine proven across 256/256 generated-and-held-out scenarios, a concurrency-limiter proven across its whole interleaving space for small inputs. The hard cases are the point; anyone can verify a pure function.

Why this is the highest-leverage thing we do

Bug-finding (yesterday) is valuable. Verified dependencies are valuable. But "modernize the code you're afraid of, and mathematically prove you didn't break it" is the thing enterprises can't buy anywhere else. It turns a rewrite from a risk you avoid into a procedure you run. The clean code you've wanted for years, without the quarter-long held breath.

Tomorrow flips the question. Brownfield works because the original exists to run. But what about code with no original — something brand new, that has never existed before?