C-DAD vs. A Full Rewrite

At some point, every team staring at an old, tangled system has the same conversation: what if we just rewrote it. New framework, new patterns, a clean slate free of the workarounds that accumulated over a decade of shipping under deadline. It's a tempting plan, and it's not an unreasonable one. Sometimes a system really is beyond salvaging and a rewrite is the honest answer.

The trap is more specific than "rewrites are bad," which isn't true. It's that a rewrite gets sold as a fix for the wrong problem. Teams reach for it once they notice a system has become unnavigable, expecting that cleaner code will also make the system legible. It usually doesn't. A rewrite consumes an organization's most senior engineers for months and produces better names, tidier services, a codebase a new hire can read without wincing. What it doesn't produce is a system that declares what it knows about itself. Point an agent at the freshly rewritten service, and it runs into the same wall it hit before the project started, because legibility comes from what's declared, not from how clean the code reads.

Extraction takes a narrower, slower-looking path that pays off faster in practice: pull one capability out, contract it properly, leave the rest of the legacy system alone until its turn comes.cdad check gives you a baseline score for where the legibility gaps actually are. cdad roadmap takes that report and ranks which capabilities are worth extracting first, based on how critical and how frequently touched they are.cdad init scaffolds the contract for whichever one comes up top. None of it requires freezing feature work for a quarter while the rewrite catches up to where the old system already was.

The honest tradeoff: a rewrite, if it succeeds, gives you a system that's uniformly clean. Extraction gives you a system that's unevenly legible for a while, some capabilities contracted and safe to hand to an agent, others still exactly as opaque as they were yesterday. But extraction produces value on the first capability you finish, not on the day the whole project ships, and it's the approach that actually targets the problem instead of hoping cleaner code solves it as a side effect.