01 / Why rewrites fail
The code still works.
Nobody can say exactly what it does.
Documentation is stale and the authors have left. Decades of edge cases live only in the source, so a rewrite has to guess at them. The industry numbers show how that ends.
// business rule, no tests int calculate_payout( ClaimRecord *claim) { if (claim->claim_amount > claim->coverage_limit) return claim->coverage_limit - claim->deductible; return claim->claim_amount - claim->deductible; }
02 / Why rewrites fail
The failure mode is almost never the technology.
It comes down to the requirements. A rewrite tends to drop the undocumented business rules and nobody notices until users do.
of full rewrites miss their goals, overrun badly or are abandoned.
average cost overrun on large IT projects.
of IT budgets consumed just maintaining technical debt.
Any credible modernisation has to recover those rules first, and prove continuously that none were lost.
03 / The insight
The running system is the only truthful document.
Every rule that matters is already in its source and schema, and how people actually use it. So instead of writing the specification from scratch, we recover it from the evidence.
Code and data
Source code, stored procedures, triggers, database schema, and the shapes production data actually takes. The rules, including the ones nobody remembers writing.
Intent
User documentation, manuals, and training material. What the system was meant to do.
Real usage
Screen recordings of people working, plus tickets, logs, and interviews. How the system is actually used, including the workarounds.
All of it resolves into one executable specification, with validation criteria built in.
04 / The approach
Spec first. Build second. Verify against both.
ACDC, our Agent-Centric Development Cycle. Six gated steps. Senior engineers review at every gate, and every change is traceable.
From code, schema, docs, and real usage, with validation criteria included.
Your experts correct and approve the specification before any build starts.
Standards, security, integrations, and branding, all set before code.
Agents generate the application, plus tests drawn from the approved spec, then run them until green.
The new build is checked against the spec and the legacy code. Deviations get resolved.
UAT, a parallel run where warranted, and a staged switch. No big bang.
The tests are written from the approved spec, before the build.
05 / Triangulate
Three sources of truth, checked against each other.
Every behaviour in the new build is tested against what the specification says it should do and against what the legacy system actually does.
Clear defects against the spec are corrected by the agents and re-verified.
Ambiguous differences go to engineers and your experts, with evidence from all three sources.
Improvements signed off at step 2 are recorded as intentional, not as regressions.
Cutover is staged by module, site, or user group, and the legacy system stays warm until the evidence says it can retire. At every point there is a working system, a known state, and a way back.
06 / Where it sits
The same agentic engine, pointed at what you already run.
+ Supporting capabilities
Start with the spec.
Pick one system. We recover its specification and validation criteria, and you see in black and white what your legacy application actually does. Then you decide what to build, with evidence on the table.