Coding agents in someone else's codebase

Modernisation projects fail on behaviour nobody wrote down: a rounding rule, a patch applied in production and never merged back, an edge case a downstream report depends on. A coding agent doesn't change that; it makes it easier to produce a lot of plausible code that has the same blind spots, faster. So the order of work matters more, not less.

First, read the repository the way its owners do: what runs, in what order, reading and writing what, owned by whom, tested how. Second, characterise: capture real inputs and outputs from the running system and write tests that replay them against your new code, record by record. Third, migrate in slices: one program or one rule at a time, run in parallel with the old system until the outputs match for long enough, then cut over and switch the old piece off. The agent works inside that structure: in a sandbox, on a branch, through pull requests the customer's engineers review, with the characterisation run as a gate it can't skip. Measure it on merged changes and defects found later, not on lines written.

• Characterise before you change. The recorded output is the specification, including its bugs.
• The source isn't always what runs. Compare the library with production behaviour before trusting either.
• Small slices, parallel runs. Each slice is proven against the old system before anything depends on it.
• The agent proposes, the owners merge. Branch, pull request, required checks, a human reviewer.
• Know your sandbox. Every product draws its boundary differently; read what it covers.