A bank's core platform team scopes a modernisation at three years. With Claude Code doing most of the mechanical rewriting, the same work can now land in months, sometimes weeks. That sounds like the end of the problem. In practice it moves the problem somewhere less visible: into the change advisory board, the reviewer queue and the approval chain that were sized for a handful of human pull requests a week.
In September 2026 Anthropic's forward-deployed engineers published field notes on preparing for AI-driven code modernisation, drawn from real customer deployments. Their central point is plain: the controls built for human-authored, human-reviewed change do not scale on their own to agent-accelerated change volume. Writing the code stops being the slow part. Everything around it becomes the slow part.
What should a regulated team change before starting a Claude Code modernisation?
Before a regulated Australian organisation starts a Claude Code modernisation, it should redesign how change is reviewed, approved and released, because those processes become the constraint once code is produced in hours rather than weeks. That means tiering changes by risk, defining what evidence each tier needs, agreeing who signs off, and testing the release pipeline at the higher volume before the first large batch of agent-written pull requests arrives.
Most teams skip this step because the pilot looked fine. A pilot produces ten or twenty changes, and the existing process absorbs them. A full modernisation produces hundreds, and a process built around one senior reviewer reading every diff line by line simply queues them. We covered the review habit itself in how to stop reviewing Claude Code output line by line; the governance question sits one level above it.
Where the bottleneck moves
Think about a modernisation as a pipeline with four stages: plan, change, verify, release. Before agents, the change stage dominated the calendar. With Claude Code, it shrinks sharply, and the other three stages are suddenly exposed.
Planning: agents need clear target architecture and conventions written down, or they produce consistent code in an inconsistent direction.
Verification: test coverage on the legacy system is often thin, so there is nothing reliable to prove equivalence against.
Review: reviewers built for a few pull requests a day face dozens, and either rubber-stamp them or become the blocker.
Release: change windows, CAB meetings and manual approvals were designed around monthly or quarterly cadence.
| Stage | Human-led share of effort | Agent-assisted share of effort |
|---|---|---|
| Planning and conventions | 10% | 20% |
| Writing the change | 60% | 15% |
| Verification and testing | 15% | 35% |
| Review and approval | 10% | 20% |
| Release and change control | 5% | 10% |
The percentages are illustrative, not measured, but the shape matches what the source describes: the total shrinks, and the share spent on assurance grows. If your governance budget and headcount stay fixed while change volume rises tenfold, assurance is where the project stalls.
Right-sizing change management for agent-written pull requests
The answer is not to drop review. For APRA-regulated entities, CPS 230 operational risk obligations and CPS 234 information security expectations still apply to every change that touches a critical operation. The answer is to make review proportionate, and to shift effort from reading diffs to checking evidence.
Tier changes by risk, not by author
A mechanical refactor that renames symbols and passes an equivalence test suite is low risk regardless of who wrote it. A change to interest calculation logic is high risk regardless of who wrote it. Define three or four tiers, document the evidence each tier needs, and let low-tier changes flow through automated gates with sampling review rather than full human review.
Make the agent produce the evidence
Claude Code can write characterisation tests against the legacy behaviour before it touches the code, then show those tests passing after the change. That turns review from 'does this look right' into 'does the evidence hold'. Reviewers spend their time on test design and edge cases, which is where their judgement adds the most.
Batch for approval, not for merge
A change advisory board cannot meet for every pull request. Group related low-risk changes into a single approved release with one evidence pack, and keep individual high-risk changes on their own path. Record the grouping rule so an auditor can see why a batch was approved as one item.
What a staged rollout looks like
A staged rollout lets the organisation prove its new controls on low-stakes code before relying on them for anything that matters. A typical sequence for an Australian financial services or government-adjacent client runs like this.
| Stage | Scope | Exit test |
|---|---|---|
| 1. Readiness | Conventions, risk tiers, evidence rules | Tiers signed off by risk and engineering |
| 2. Low-risk slice | Internal tooling or reporting module | No escaped defects over four weeks |
| 3. Volume test | Several hundred mechanical changes | Review queue under two days |
| 4. Core logic | Customer-facing or regulated paths | Equivalence tests pass, CAB approves |
| 5. Steady state | Remaining codebase | Metrics reviewed monthly |
Each stage tests the process, not only the code. Stage three exists purely to find out whether your reviewers, pipeline and change board cope with agent-scale volume before the stakes rise. For more on the speed side of the story, see how Claude Code migrated a million lines in two weeks, and for an in-place approach on older stacks, Claude Code and legacy .NET modernisation.
An illustrative cost picture
Take an illustrative mid-sized Australian lender planning a $1.2 million, two-year modernisation of a loan servicing platform. If Claude Code compresses the coding effort by two thirds, the obvious saving looks like $500,000 or more. But if review and change control are left untouched, the project still runs at the pace of the approval queue, and most of that saving turns into idle engineering time waiting on sign-off.
Spending $60K to $90K up front on risk tiering, test harnesses and a redesigned release process is usually what turns the theoretical saving into a real one. Our ROI calculator is a quick way to test those assumptions against your own numbers.
What not to conclude
Faster code generation does not mean regulators expect less assurance. It also does not mean every legacy system is a good candidate. Systems with no tests, unclear ownership or undocumented business rules need discovery work first, and Claude Code can help with that discovery, but it cannot invent the business intent nobody wrote down. Treat the first slice as a learning exercise for the controls, not a race to finish.
If you are weighing up a Claude Code modernisation and want a second view on readiness, book a conversation with our team. We run modernisation readiness assessments for Australian regulated teams, covering risk tiers, evidence design and rollout staging, before the first agent-written pull request lands. You can also see our wider services.
