Reviewing every line was always a proxy. Now it is a bottleneck too.
Line-by-line review worked because writing code was slow enough that reading it kept up. That assumption is gone. Teams respond by reviewing faster, which means reviewing worse, or by queueing changes, which means the merge conflicts arrive later and larger.
The way out is to stop treating all changes as equal. Most changes cannot cause real damage. A few can. Sorting them is cheap; reviewing them as if they were the same is what costs.
Can lose money or data
Payment paths, permission checks, migrations, anything touching customer records. Human review stays mandatory, and the reviewer is named before the work starts rather than found afterwards.
Can degrade the product
Business logic, integrations, anything a customer would notice within a day. Automated property tests plus a human who reads the diff summary rather than every line.
Cannot do lasting harm
Copy, styling, internal tooling, tests. Gates run, humans do not. This is the majority of the volume, and taking it out of the queue is what gives the reviewers their time back.
Guardrails a team keeps using after we leave.
Classification at the pull request
Risk class assigned from the paths touched, not from what the author says the change does. Wrong classifications are visible and get corrected; unclassified changes do not merge.
Properties instead of examples
Property-based tests state what must always hold, so a generated implementation gets checked against the rule rather than against three cases someone happened to think of.
Provenance on every change
Whether a change was written, assisted or generated is recorded. Not to police anyone, but so that six months later you can answer an auditor, or find out whether a defect pattern clusters somewhere.
Observability as the review of last resort
Some things cannot be caught before deployment. Progressive delivery plus alerting on the properties that matter turns those into a five-minute rollback instead of a Monday incident.
The system nobody wants to touch is usually the one that earns the money.
Rip-and-replace fails in mid-market companies for a reason that has nothing to do with technology: the business rules that matter were never written down anywhere except the code, and the people who could reconstruct them have retired. A rewrite is not a port, it is an archaeology project with a deadline attached.
Read the rules out first
Before anything moves, we extract the business rules actually encoded in the system and put them somewhere a person can read. Characterisation tests pin the current behaviour, including the behaviour nobody intended, so that a change that alters it is visible rather than discovered by a customer.
Strangle, do not replace
New capability goes into new code behind a boundary; the old system keeps running and keeps shrinking. There is no cut-over weekend, no parallel-run budget, and no point at which the company has two systems of record and no idea which one is right.
Make the operating cost visible
Most modernisation business cases fail at the investment committee because nobody can say what the current system costs to keep alive. We put a figure on it first: licences, specialist availability, incident hours, the changes that were not made because they were too risky.
Know when not to
Some systems should be left alone and documented well enough to survive their last maintainer. That is a legitimate outcome of the assessment, and it is cheaper than the alternative when the system is stable and the domain is not moving.
Questions
Do you write the code or advise on it?
Both, and usually in that order. We work inside the team for the first weeks so the model gets built against your real constraints, then hand it over. Engagements that stay advisory produce documents nobody applies.
Our stack is COBOL on a mainframe. Is that in scope?
Yes. Rule extraction and characterisation testing apply the same way; the tooling differs. What matters more than the language is whether anyone left understands the domain, and how quickly that is changing.
How do you measure whether the review model worked?
Change lead time, change failure rate and the proportion of changes that need a human reviewer. The last one is the honest signal: if it does not fall, the classification is not doing anything and we have added process for nothing.
Will this satisfy an auditor?
The provenance and classification records are built to be shown. Whether they satisfy your particular auditor depends on your regime, and we would rather look at that with you early than assert it here.
Start with the diagnosis.
Thirty minutes on how your team currently reviews, where the queue sits, and what a risk-class model would change. No deck, no follow-up sequence.
Two weeks from bottleneck to a measured number.
Tell us the process that eats your time. We build on your real data, measure with the method agreed before the start, and if the numbers do not carry it, we say so.
Request the callRequest the callAnswers with the source attached.
Industrial knowledge, readable by the people who need it: in the hall, on the road, on the night shift.
See how it works