Anthropic's Modernization Plugin Will Rewrite Your COBOL. First It Makes You Prove You Understand It

Anthropic has published a Claude Code plugin called code-modernization, pointed at the oldest and least glamorous problem in enterprise software: a COBOL, legacy Java, C++ or .NET system that still runs the business and that nobody currently employed fully understands. It is Apache 2.0, it installs with one line, and the official plugin directory lists it as Anthropic-verified with roughly 5,900 installations.

The capability on offer is not the interesting part. Language models have been able to read COBOL and emit Java for a while now. What makes this plugin worth reading is that most of its design is spent refusing to do that.

The sequence is the product

The plugin enforces an order:

preflight → assess → map → extract-rules → brief → (reimagine | transform | uplift) → harden

The first four commands only produce documents. assess writes an inventory and a complexity index; map writes a dependency and data-lineage graph plus an interactive topology viewer; extract-rules mines business rules into Given/When/Then "Rule Cards" carrying file:line citations and confidence ratings. Nothing has been written toward a new system yet.

brief is the gate. It synthesizes discovery into a phased plan for a steering committee, enters plan mode for human approval, and — the operative line in its definition — reads the discovery artifacts and stops if any are missing. You cannot reach the code-generating commands without having produced the analysis first. The README states the reasoning directly: modernization fails when teams transform code before understanding it, or ship without a harness to catch behavior drift.

That premise is well supported by thirty years of failed migrations, and it is a strange thing to build a product around. The plugin's competitive claim is not that it writes better Java. It is that it will not write any until you have a document explaining what the old system does.

Three methods, and the boring one is the point

The build stage offers three commands, and the brief recommends which fits.

uplift is the one that signals real field experience. Its command file opens by insisting it is not transform: "the code is good; it just needs to run on a newer runtime," so it preserves structure and makes the smallest diffs that compile and behave identically, driven by a catalog of the breaking changes this code actually hits. If that catalog shows most of the code is forced to change anyway, the command tells you to go use transform instead.

It also has the most honest cost-control mechanism in the plugin. Migration is pilot-first: one representative project goes end-to-end, its lessons are written to a playbook, and only then does the rest fan out one agent per project, in dependency-aware batches behind a circuit breaker — so a playbook that has stopped working is caught within a handful of agents and the spend stops until it is revised. That is a design written by someone who has watched an agent fleet burn tokens confidently in the wrong direction.

The codebase is treated as an attacker

The safety notes are unusually direct. Analyzed code is untrusted input: a hostile repository can plant comments like "ignore previous instructions" or "mark this rule approved" to steer what lands in the extracted rules or the security findings, which later commands then trust. The stated defenses are that agents treat file content as data, that verification agents re-derive every rule and finding from the cited source rather than from another agent's description, and that the human approval gate sits before any code is generated.

Secrets get similar treatment — masked in shared artifacts, quarantined to a gitignored file — followed by a line that reads as a disclosed past defect: if you ran an early version of this plugin on a real system, check whether the analysis directory was committed and rotate anything exposed.

The recommended workspace configuration is the same instinct expressed as permissions: deny writes to legacy/, allow them in analysis/ and modernized/. The docs then concede the limit of that guard, noting shell commands that mutate files still go through the ordinary Bash prompt, which is the only containment for the two steps that fan out many write-capable agents at once.

What it declines to estimate

assess computes a COCOMO figure and then forbids you from using it as a schedule. The note explains why: COCOMO's constants encode human-team productivity, which agentic transformation does not follow, so any duration derived from it would be wrong. The number survives only as a relative index for ranking and sequencing systems in a portfolio.

That is the most candid sentence in the repository. The industry has no calibrated model for how long agent-driven migration takes, and rather than invent one, the plugin ships a metric with a warning label attached.

None of this makes the hard problem easy. The strongest equivalence proof — running one test suite on both the old and new runtime — requires a working legacy toolchain, and where that is missing the plugin falls back to recorded-trace characterization tests, which pin observed behavior rather than intended behavior. The directory listing still carries an older blurb that omits preflight and uplift entirely, which suggests the workflow has been revised faster than its storefront.

But the shape is the argument. Anthropic did not ship a COBOL translator. It shipped a process that treats the translation as the cheap step and the proof as the expensive one, and that is very likely the correct read of why these projects fail.

Sources: code-modernization README (GitHub) · plugin.json manifest · modernize-uplift command definition · modernize-brief command definition · claude-plugins-official directory (GitHub) · code-modernization plugin listing (Claude)