Skip to content
The brass gear train of an old tower clock, a pair of calipers resting across it.

Legacy Modernisation

Change old code, keep what works

An agent changes legacy code quickly. Characterisation tests written first tell you what it broke.

Book a readiness reviewAI Test Automation
  • Tests that record what it does today, correct or not
  • Written before the first edit
  • Run on each change after that
  • The step most teams skip, and we do first

Example record

Recorded before the first edit

What it does today, kept as tests. Then you judge each behaviour.

A diff in recorded output stops the change.

characterisation · billing moduleSample log

  • Rounding on invoice totals

    a downstream report depends on it

    Intended

  • Timeout returns an empty list

    someone treats it as a feature

    Unknown

  • Date format in the partner export

    a partner parses it

    Intended

  • Agent change altered recorded output

    diff on 2 recorded cases

    Blocked

What breaks when legacy is changed first

Old systems carry behaviour nobody wrote down. Some of it is relied on.

  • Each behaviour recorded as a test before anyone touches the code

  • Each one labelled intended, accidental or unknown, with an owner

  • An agent’s change that alters a recorded output is blocked

  • Unknown behaviours go to the person who knows the domain, not to the agent

Answers from the code that runs

Documentation drifts. So we index the code, and your answers match what runs today.

  • How the code relates is indexed once, then queried

  • An architectural question in ~400 tokens, against ~10,000 before

  • 25x less context for the same question

The figures are from our own case, One architectural question, priced 2 ways, on an internal workspace of 700 nodes and 1,000 edges.

Capabilities

How the characterisation is built

So the first change lands on a system you have on record.

01Golden master testsInputs captured from production traffic, outputs recorded as they are today.
02Behaviour named, then judgedEach recorded behaviour labelled intended, accidental or unknown, with an owner.
03A safety net for the agentThe agent changes code inside the net, and a diff in recorded output stops the change.
04Coverage where change is plannedCharacterisation goes first where your roadmap goes first.

Model

What we fix, and what you decide

What we fix

  1. F1Characterisation before the first change
  2. F2Recorded behaviour reviewed by someone who knows the domain
  3. F3A diff in recorded output blocks the change

What you decide

  1. C1Which parts of the system go first
  2. C2Who decides which behaviour is intended
  3. C3Stack and test framework

Related

Where to go next

Next step

Send us the module nobody wants to touch.

We scope what characterising it takes. Then you schedule the change with its behaviour on record.

Book a readiness review →