On 23 September 2026 Anthropic published "How to prepare for AI-driven code modernization projects", part of its "Notes from the Field" series written by forward deployed engineers. The central claim is that agents can now do modernization work once scoped in years in months or even weeks. The slow part has moved to the organization. Review, approval and change-management processes assume a human wrote every change, and they become the bottleneck. The post sets out six steps: define the target (uplift, transform or reimagine), create a "certificate", set a promotion policy, put prerequisites in place, build and refine an agentic workflow, then pilot and scale.
The guide follows Anthropic's February 2026 COBOL push, which claimed teams could modernize "in quarters instead of years". Reuters reported that IBM shares fell 13.2% after that announcement. Builders should read the new post as a vendor playbook for the delivery problem that critics raised then. It is not a neutral benchmark.
What we checked
- What concrete evidence would resolve the remaining editorial uncertainty for this item? partly confirmed. Three things reduce the uncertainty. The blog is dated and attributed: Jonah Ezekiel and Lexie Tonelli, 23 Sep 2026. Its tooling, the code-modernization plugin, exists in Anthropic's official plugin repository with documented verification logic. An Anthropic customer story (LG CNS) provides concrete numbers. Independent verification of the results is still missing. [1][2][3]
- Is the 'code modernization plugin' referenced in the blog a real, publicly installable artifact with verifiable behavior? confirmed. Yes. It lives in anthropics/claude-plugins-official. It has assess, map, extract-rules, brief, uplift, transform, reimagine, verify and harden commands. A proof script returns PROVEN, PARTLY PROVEN or NOT PROVEN verdicts, and the plugin never edits the legacy source. [2]
- Are the 'months or weeks instead of years' speed and cost claims independently verified? unresolved. The only quantified evidence is Anthropic's own LG CNS case study: 7 months, about 50% of rebuild cost, and 2,888 of 2,913 APIs converted. Independent analysts and IBM argue that translation speed is not the same as program success. No third-party audit was found. [3][5][4]
What we found
- The blog defines a "certificate": automated conditions every agent-produced change must meet, such as passing tests, performance bounds, output parity, staging results and security scans. It says to write it with the reviewers who will promote changes. Changes are then tiered by blast radius and agent confidence under a promotion policy that leadership agrees in advance, so scarce subject-matter-expert time goes to the riskiest tiers. [1]
- The post's cost guidance is qualitative only. It gives no token counts or dollar figures and admits budgets are hard to estimate. It names the cost drivers: how much code is read versus changed, how strict the certificate is (verification is usually the larger share in regulated settings), how much test writing is needed, and how much reconciliation is needed when other teams merge mid-run. It recommends measuring token use in a pilot and extrapolating, using Sonnet for mechanical high-volume work and more capable models for hard transformations and adversarial review. [1]
- The official code-modernization plugin puts the proof idea into code. Its verify step re-runs everything in a fresh session. Specifically, it:
- does a clean test run, failing if there are zero or skipped tests
- compares old and new outputs byte by byte on the same inputs
- tries at least ten unseen edge-case inputs
- runs a canary, a deliberate one-line break that must turn tests red
- checks that every P0 business rule is covered by a test
If the legacy system cannot run locally, the best verdict available is PARTLY PROVEN. [2]
- The README documents caveats that matter in practice:
- Rule extraction is nondeterministic. One example showed 48 findings on one run and 52 on another.
- extract-rules can spawn 50 to 200 agents.
- Planted instructions in analyzed code are treated as data.
- Telemetry is on by default, sending whole-number counts only, and can be disabled.
The quoted run times (about 5 to 15 minutes per analysis step, 15 to 30 minutes per module build) apply to systems of tens of thousands of lines. For systems of millions of lines, the README says to work one module at a time. [2]
- The most concrete result comes from Anthropic's own LG CNS customer page. A 20-year-old construction project-management system was rebuilt between November 2025 and June 2026. 2,888 of 2,913 APIs (99.1%) were converted and 1,340 MiPlatform screens were moved to React, at roughly 50% of conventional rebuild cost. LG CNS used Claude Opus 4.6 on Amazon Bedrock with its own thin harness, which breaks work into YAML-scoped tasks and hands off between stages through files. These are vendor-published numbers. [3]
- Independent voices push back on equating speed with success. IBM's Rob Thomas argued that "translation captures almost none of the actual complexity" of mainframe systems. Futurum's analysis says AI substantially compresses discovery and transformation, but that behavioral equivalence, audit trails and regulated-industry compliance remain unsolved by both Claude Code and IBM's Project Bob. [4][5]
What it means
The useful part of this guidance is the shift of effort from generating code to producing evidence. Before you point agents at a legacy estate, agree three things with the people who will sign off production releases:
- The certificate: the parity, performance and security gates every change must pass.
- The promotion policy: which tiers of change need human review.
- The traceability chain: links from each pull request to its agent transcript and test evidence.
If you can't run the legacy system side by side with the new one, even Anthropic's own tooling caps you at "partly proven". Investing early in replay harnesses or prod-parallel environments is likely to pay off more than tuning prompts.
Treat the headline speedups as plausible but unproven for your context. The only hard numbers come from a vendor-published case and depend on a strong harness and a partner team. Run a pilot on a small partition, record token use and reviewer hours, and only then extrapolate a budget. Account for nondeterminism in rule extraction with human review steps. If you work in a regulated domain, assume the verification and compliance work, not the translation, will set your schedule.
Still open
- No independent, third-party audit of any Claude-driven modernization's cost, timeline or post-go-live defect rate was found.
- How does the certificate approach hold up for mainframe workloads that cannot run outside IBM Z, where the plugin can only reach PARTLY PROVEN?
- Real token and dollar costs for large estates are unpublished in the blog. The blog points to an Anthropic customer-migration piece that was not opened in this session.
- Do regulators and auditors accept agent transcripts and proof packs as change-management evidence?