Jarred Sumner ported Bun from Zig to Rust in eleven days. Roughly 750,000 lines of Rust. 99.8% of the existing test suite passing on day one after merge. The work was done using Claude Code dynamic workflows — a research-preview feature that lets a single Claude Code session spawn tens to hundreds of parallel subagents, have those agents verify their own output before anything surfaces to the developer, and hand back a result that would have taken a conventional team months to complete.
For Australian engineering teams sitting on legacy migration backlogs, this matters. COBOL services at the major banks, AngularJS frontends that predate modern JavaScript frameworks, WCF service layers still running on Windows Server 2012. The expensive phases of those programs are about to get cheaper.
What Dynamic Workflows Do
Standard Claude Code runs one agent at a time: it reads, reasons, and acts sequentially. Dynamic workflows let Claude write an orchestration script on the fly that runs many parallel subagents within the same session. Each subagent handles a defined portion of the problem. An independent review layer checks the combined output before anything reaches the developer.
Anthropic has designed this for three categories of engineering work:
Codebase-wide audits: bug hunts, profiler-guided performance reviews, and security scans across an entire service, not just files currently open in an editor
Large migrations and modernisation: framework swaps, API deprecations, language ports, and schema changes touching hundreds of files at once
Critical work needing adversarial review: independent subagents attempt to break the output before it reaches the developer's screen, surfacing failure modes that a single-pass review would miss
The Bun Port: What the Benchmark Actually Shows
Sumner's workflow for the Bun port started with a mapping pass: one group of subagents analysed Rust lifetime requirements for every Zig struct field across the project. A second group wrote .rs files as behaviour-identical ports, with two reviewer subagents checking each file. A fix loop drove the build and test cycle. An overnight workflow opened cleanup pull requests.
The result: 99.8% of the existing test suite passing after merge, in eleven days. A senior engineering lead at one of the early enterprise users described the experience as a session where the boundary between planning and building effectively disappeared. That is a qualitative observation, but the quantitative one is harder to dismiss: 750,000 lines of ported code, verified by tests, in under two weeks.
How to Trigger a Workflow
There are two entry points. The first is direct: ask Claude to create a dynamic workflow for a specific task. Claude assesses whether the problem is large enough to warrant one and, if so, writes the orchestration script automatically. The second is ultracode mode: a new Claude Code setting that raises effort to xhigh and lets Claude decide when to deploy a workflow without a prompt each time. For teams processing a consistent category of large tasks, ultracode is the more efficient default.
One honest constraint: dynamic workflows consume substantially more tokens than a standard Claude Code session. The additional cost buys parallelism and adversarial verification that a sequential pass cannot provide. On routine tickets, that trade is the wrong one. On a 400-file migration with a firm delivery date, it is usually the right call.
The Australian Migration Backlog
Australian enterprise engineering teams carry a significant category of legacy technical debt: mainframe workloads at the major banks, batch COBOL processing at superannuation funds, decade-old reporting stacks at ASX-listed companies that predate modern data warehousing. Each represents a migration that a conventional team would scope as a 12-to-18 month program.
A rough benchmark: a 15-person engineering team at a fully-loaded cost of $180,000 AUD per person per year runs at $2.7M per year in labour alone. A 12-month migration program at that team size costs $2.7M before vendor tooling, training, or project management overhead. Even a 30% compression in the boilerplate-heavy phases of that program (the porting, the variant-handling, the test scaffold generation) represents $810,000 in recoverable labour cost on a single engagement.
The AU migration scenarios where dynamic workflows apply most directly:
Mainframe to cloud: COBOL to Java or Python, with the existing batch logic as the specification
Legacy WCF service layers to REST or GraphQL, where the contract surface is well-defined and testable
AngularJS frontends to React or Vue, where the component structure is relatively flat and coverage is reasonable
Lotus Notes workflows to SharePoint or a modern intranet platform
Oracle PL/SQL batch processes to cloud-native data pipelines, where the business logic is well-documented
Starting with the Right Problem
The Bun port succeeded in part because the existing test suite was comprehensive enough to act as a reliable quality gate. Sumner could trust the 99.8% pass rate because the tests were worth trusting. Engineering leads evaluating dynamic workflows for a legacy migration should invest in test coverage for the target module before running the workflow, not after.
A practical starting point for Sydney and Melbourne engineering teams: identify a single internal service with stable API contracts, adequate test coverage, and a clear target language. Scope a dynamic workflow to port that service. Measure the output against a manual estimate of the same work. That calibration exercise gives you the data to build a credible investment case for a broader migration program.
One important boundary: dynamic workflows are not designed for the judgment-heavy phases of a migration. Architectural decisions about what to keep, what to redesign, and where system boundaries should sit still require experienced engineers making considered calls. The feature performs best on work that is well-specified enough to be verified automatically.
Availability
Dynamic workflows are in research preview and available today for Claude Max, Team, and Enterprise plans via the Claude Code CLI, desktop application, and VS Code extension. Team and Enterprise deployments require admin enablement. The feature is also available through the Claude API, Amazon Bedrock, Vertex AI, and Microsoft Foundry for teams building directly on the model.
Anthropic is collecting usage data during the research preview period and will develop the orchestration capabilities further as real-world results come in. The current capability is production-usable; expect the feature to mature further over the next six months as adoption data feeds back into the model's orchestration strategies.
If your engineering team is evaluating dynamic workflows for a migration program and you want help deciding whether your target problem is a good fit, book a session with us and we will work through the scoping with you.
