How Jarred Sumner Rewrote Bun with Claude Code Workflows
When Anthropic announced Dynamic Workflows in Claude Code, most of the attention went to the obvious part: Claude can now run many agents in parallel. That is interesting, but it is not the real story.
The real story is what Jarred Sumner did with it.
In Anthropic’s launch post, Jarred is described as using Dynamic Workflows to help port Bun from Zig to Rust: roughly 750,000 lines of Rust, 99.8% of the existing test suite passing, and eleven days from first commit to merge.
That is the part worth paying attention to. Not because “AI rewrote Bun” is a cute headline, but because it shows a new operating pattern for serious agentic coding. This is not just chat. It is not just a single subagent. It is not “please refactor this folder” and hoping the model somehow keeps the entire project in its head.
It is a workflow: a project-shaped execution plan.
What are Dynamic Workflows?
Dynamic Workflows are Claude Code’s new way to orchestrate many subagents around a larger task. Instead of asking one agent to hold the whole project in its context window, Claude writes a JavaScript workflow script for the task. That script becomes the coordinator.
The workflow can break the work into phases, fan out subagents, track intermediate results, and bring the final result back into the main session. In other words, the plan is no longer only inside the conversation. The plan lives in code.
That difference matters. In a normal Claude Code session, Claude is both the worker and the orchestrator. It decides what to do next turn by turn. With subagents, Claude can delegate specific tasks to isolated workers, but the parent conversation still coordinates the overall direction. With workflows, the orchestration itself becomes explicit.
The workflow runtime runs in the background. Each agent gets a focused prompt and its own context. Intermediate results can live in script variables instead of flooding the main chat. You can monitor workflow runs through /workflows, and workflows can be saved as reusable commands.
That is why workflows feel less like “a smarter chat” and more like a small build system for agentic work.
Term box: Subagent
A subagent is a specialized Claude worker running in its own context window. It is useful when you want to isolate research, review, debugging, or implementation from the main conversation.Term box: Workflow
A workflow is not just another agent. It is a script-driven orchestration layer. Claude writes the script, and the runtime executes it by spawning agents across phases.Term box: Why this is different from Skills
A Skill gives Claude reusable instructions, assets, or procedures. A workflow gives Claude a repeatable execution structure. Skills improve how Claude approaches a task. Workflows change how the task is coordinated.
The Jarred pattern: split the project until agents can win
Jarred’s own description of Dynamic Workflows is the most useful framing I have seen so far. In his words, Dynamic Workflows are, in his personal opinion, the current state of the art for reliably using agents to complete medium-to-large projects.
For extra-large projects, he especially likes using workflows together with /loop.
That makes sense, because large engineering projects usually fail with agents for a boring reason: the task is too wide. Not necessarily too hard, but too wide. Too many files, too many constraints, too many partial decisions, and too many ways to accidentally break something that looked unrelated.
The solution is not always “use a better model.” Sometimes the better solution is to stop giving the model a project-sized blob and start giving it unit-sized work.
Jarred describes a pattern that works well:
1. Do the work.
2. Run adversarial review.
3. Apply the changes.
That sounds simple, but the structure is important. Most people use agents by asking something like, “Please migrate the codebase.” Then they watch the agent sprint into a wall.
The workflow version is different. You split the project into isolated units. Each unit gets worked on separately. Then other agents review the result adversarially. Only after that do you apply the changes, run the build, pass tests, commit, and open a PR.
This is much closer to distributed engineering than chatting with an assistant.
Term box: Adversarial review
Adversarial review means asking separate agents to actively refute the solution. Their job is not to approve the work. Their job is to find flaws, edge cases, bad assumptions, and hidden regressions.
What the Bun rewrite shows
The Bun port is a strong example because it exposes the shape of the work. Anthropic describes multiple workflow phases: one workflow mapped Rust lifetimes for struct fields in the Zig codebase; another wrote .rs files as behavior-identical ports of the .zig files; hundreds of agents worked in parallel; reviewers checked the work; and then a fix loop drove the build and tests until they passed.
After the port landed, another workflow ran overnight to find unnecessary data copies and opened PRs for final review.
That last part is important. The workflow did not just “generate code.” It performed a sequence: map constraints, port files, review them, fix compilation, run tests, optimize afterwards, and open reviewable PRs.
That is not autocomplete. That is an agentic pipeline.
The prompt pattern
Jarred shared an example prompt that captures the style very well. The task starts with a report, such as ./REPORT.md. Claude is asked to split that report into individual files, one per bug or finding, and pass those files into the workflow.
For each finding, the workflow has a first step: fix the bug. But the worker is explicitly told not to use git or build commands. Slow commands are banned. The reason is practical: there may be another Claude running in the same branch, and you do not want agents stepping on each other.
The second step is adversarial review. Two review agents are asked to refute the bugfix and uncover every flaw. They are also told not to use git or build commands.
Only after all individual units are complete does the workflow move to the global step: apply all bugfixes, run the build, get the relevant tests passing, commit, and make a PR.
Get Alon Wolenitz’s stories in your inbox
Join Medium for free to get updates from this writer.
This is the pattern that matters. The build does not run inside every tiny worker. Git does not get touched by every agent. The expensive, global, stateful commands happen at the end.
That is how you avoid chaos. You let parallel agents work on isolated units, and then you serialize the dangerous part.
Term box: Why ban git and slow commands?
In a parallel workflow, many agents may be working against the same branch or filesystem. If every agent runs git, cargo, build commands, or test suites whenever it wants, they can interfere with each other. The safer pattern is to keep individual agents focused and cheap, then run global verification later.
Why workflows are more deterministic than “just use subagents”
This is the technical heart of the feature. A subagent is useful when Claude needs help with a specific task. A workflow is useful when the task itself needs an execution plan.
With subagents, Claude still decides what to delegate next during the conversation. The control flow is mostly implicit. With workflows, the control flow is explicit. Loop over these files. Spawn two reviewers for each implementation. Collect the results. Apply patches. Run tests. Retry failures.
That is why Jarred says workflows split up work more deterministically than subagents. They are not merely “more agents.” They are structured parallelism.
The comparison to a build system is accurate. A build system does not just say “compile the project.” It knows the graph. It knows what can run in parallel. It knows what depends on what. It knows where the final artifact should come from.
Dynamic Workflows bring that kind of structure to agentic coding. Not perfectly, and not magically, but much closer than a single long-running chat.
The real reason this works: context isolation
When you split work this way, each agent gets a smaller job and a cleaner context. That may be the most important part of the whole story.
Instead of one agent seeing a giant migration, each agent sees something like: port this file, review this fix, check this lifetime mapping, or find flaws in this patch. The task is smaller, the prompt is sharper, and the context is less polluted by unrelated details.
Jarred’s point is empirical: when Claude focuses only on the task it needs to do, it becomes more effective.
This matches how many advanced Claude Code users already work manually. They open multiple terminals, split tasks by folder, use separate agents for review, isolate context, and avoid letting one conversation become a swamp. Dynamic Workflows productize that pattern.
Term box: Forked context
In this context, “fork” means each workflow step can run with a separate context window. The worker does not need to carry the entire parent conversation. It gets the prompt, the arguments, and the files it needs.
The uncomfortable part: workflows cost tokens
Workflows can consume a lot of tokens. That is not a footnote. It is part of the design.
A workflow works because it spends tokens on decomposition, parallel attempts, independent review, verification, and sometimes retries. That is more expensive than one chat message, but it is also why the output can be better.
Two adversarial reviewers per fix cost more than zero reviewers. A workflow with hundreds of workers costs more than one heroic agent. A migration with isolated context windows costs more than one conversation trying to remember everything.
The tradeoff is clear: more tokens, more structure, more parallelism, and more verification.
For routine work, this is probably overkill. For medium-to-large projects, it starts to make sense. For extra-large work, Jarred’s note about combining workflows with /loop becomes especially interesting.
Term box: /loop
/loop is useful when you want Claude Code to keep iterating on a goal across repeated cycles. Paired with workflows, it can turn a large project into repeated batches of structured agent work.
Jarred also notes that you can ask Claude to use a rough token budget: spend more tokens on harder tasks, and save tokens on easier ones. That is another sign that workflow design is becoming its own engineering discipline. You are not only prompting the model. You are shaping the compute plan.
What this means for engineering teams
The immediate mistake will be treating Dynamic Workflows as a party trick: “Cool, Claude can spawn 100 agents.”
That is not the lesson.
The lesson is that agentic coding is becoming less about prompting and more about orchestration. The winning pattern is not asking the best model to do the whole thing. The winning pattern is designing the work so many agents can do small pieces, review each other, and only then touch the shared state.
That has implications for how teams write reports, tickets, migration plans, test plans, and internal docs. A good workflow needs good inputs. A vague issue will produce a vague workflow. A messy report will produce messy units of work. A migration without clear porting rules will create inconsistent results.
Jarred’s Bun example had structure: ./PORTING, ./LIFETIMES.tsv, ./REPORT.md, file-by-file units, review phases, build phases, and PR output.
That is the real future skill. Not just prompt engineering, but work decomposition.
The new mental model
Dynamic Workflows are not just another Claude Code feature. They are a shift in how we should think about agents.
For small tasks, use chat. For focused delegation, use subagents. For reusable knowledge or procedures, use Skills. For large, repeatable, review-heavy work, use workflows.
They shine when the project has a natural shape: every file, every endpoint, every finding, every migration unit, every test failure, every security pattern, every performance hotspot.
That is where workflows are powerful, because they turn one impossible instruction into many smaller, reviewable, parallel tasks.
The Bun rewrite is the headline. But the deeper story is this: Claude Code is moving from “agent as assistant” to “agent as runtime.”
Dynamic Workflows are the first feature that really makes that visible.
