We tested Claude Code's Dynamic Workflows on a real project. Here's what worked and what didn't

Hi! My name is Maksim Nikitin, I'm the founder of a small but proud development studio for complex and non-standard projects called ITSalt. At the beginning of 2025, we started transitioning to agent-based development and gradually built our own framework around it - NaCl. Right now it covers business analysis, system design, TDD, code review, QA and release - essentially the entire cycle from requirement to production.

You can check out NaCl in the public repository. Inside, there is a set of skills, a pipeline of roles, a Neo4j graph as the single source of truth for requirements and solutions, plus a set of rules that make agents work not "on inspiration" but according to a reproducible methodology.

When Claude Code released the Dynamic Workflows feature, I decided to test it not on a demo, but on a real project. Not for hype, and not to come to a conclusion of "good feature / bad feature". My question was purely practical:

• does Dynamic Workflows enhance our current tech stack;

• where it makes sense to use it within NaCl;

• where it could be useful for people who don't have their own framework;

• and where it's better not to spend limits, tokens and time on it.

We tested it on our real project Family Cinema - a service for generating family films. This is not a training sandbox or specially assembled demo code, but a production project with backend/frontend, pipelines for generating video and music via external services, and engineering context that has to be taken into account during reviews.

What Dynamic Workflows Is and What We Compared It To

Dynamic Workflows in Claude Code is not just "run a few agents". It's a script that Claude Code executes as an orchestrator: inside it, you can describe phases, launch agents, parallelize independent tasks, build pipelines, wait for all branches to complete, and compile the result.

In NaCl, the mechanism is different. Skills are instructions that guide Claude Code through a task sequentially: business analyst, systems analyst, team lead, reviewer, QA, and so on. A key part of the approach is human gates: the agent must not skip over fundamental decisions on its own.

So I didn't ask myself "whether to replace skills with workflows". I asked a different question: "do we have tasks where running multiple agents in parallel will deliver what a standard skill cannot".

For comparison, I broke down our tasks into four types.

Right away I realized one thing. Workflows are not a catch-all replacement. Mechanical tasks should be handed off to code, and dialogue with pauses should be handled by skills. Workflows are needed where you need multiple independent perspectives at the same time.

When workflows make sense at all

When I figured out where workflows fit and where they don't, a simple rule emerged. Workflows only make sense for tasks that require judgment — not "run 50 requests", but "check if there are any security holes here". At the same time, agents should not be queued up one after another, otherwise it's simpler to run a single agent. And most importantly, different perspectives must actually yield different findings. A security reviewer sees one thing, a correctness reviewer sees another. If that's not the case, you're just burning tokens for a pretty report.

Speaking of tokens, since we're on the topic. Even with a subscription, costs don't disappear. Large runs burn through limits and time. The question is always the same: is the result worth the spent limit?

What NaCl tasks we considered

I reviewed existing NaCl skills and selected candidates where the workflow could theoretically be applied.

I selected code review for the experiment.

The reason is simple: we do it on a regular basis, we already have a well-established skill for it, and we can directly compare three things:

• how a regular skill / single agent performs;

• what a multi-agent workflow provides;

• whether the result is worth the exponentially higher cost.

How the multi-agent workflow for review was structured

I built a workflow that replicates the output contract of our standard NaCl review skill, but internally distributes work across multiple independent agents.

Experiment artifacts:

• workflow: nacl-review-panel.js;

• README with launch instructions;

• test fixture: bench/fixtures/review-panel.

I did not assign the mechanics to LLM agents. Linters, type checks, tests, and graph checks are not work that requires judgment. They should be handled by a script or a cheap, fast model.

For LLM review, I only left items that require semantic evaluation: security, correctness, API contracts, data handling, requirements, frontend/backend specifics. Each area was handled by a separate agent. For serious findings, a skeptic agent was triggered, which tried to refute them.

Run 1. Artificial example

First, I made a small NestJS backend with pre-marked ground truth. I chose NestJS because Family Cinema is built on it; one bug and one trap are the minimum set to check both accuracy and resistance to false positives.

The first raw run looked like this:

Here is what we got:

The most interesting thing here is the unplanned bug. The workflow found a class of issues where "the code exists, but is unreachable from the outside". This is exactly the case where independent analysis angles can bring value: one agent looks at the method, another at routing, and the third at the contract.

But 26 findings for a small piece of code is overkill. I expected noise, but not this much: two thirds of the findings were nitpicks that no one would actually discuss in a real code review. So I made three adjustments:

• narrowed the reviewers' focus;

• added a recheck for a broader set of findings;

• added duplicate removal at the synthesis stage.

After the adjustments:

We managed to cut the noise roughly in half. At this stage, it seemed like this was a promising direction.

Snag №1. Run settings did not make it to the workflow

The first technical surprise was not related to review quality, but to the run process.

When I ran the workflow with custom parameters — which files to review, which checklist to use — these parameters were silently lost. The workflow ran with default settings and checked something other than what I passed to it.

This was consistently reproducible on the latest version of Claude Code. The workaround was simple: instead of passing parameters, I generated a separate version of the script with the values hardcoded, and ran that instead.

If the workflow runs on the wrong input, even a beautiful report is useless.

Attempt 2. Real task and false approval

Next, I took a real task from Family Cinema: the backend for the admin pipelines dashboard — list, details, real-time progress updates, repository, validation schemas. The change was no longer trivial: 1484 lines, 7 files.

I compared two approaches:

• the multi-agent workflow after adjustments;

• our regular review skill running on the Opus model, with a specification and checklist.

But this comparison had an important asymmetry that I initially underestimated:

• the workflow only looked at changed files;

• a single agent could read the entire repository.

Result:

This was the main negative result of this run: the expensive multi-agent workflow allowed publishing code with a real bug, while the single agent found the problem and sent the task back for revision.

22 agents, a million tokens, ten minutes of runtime - and in the end, this entire armada allows shipping code with a real bug to production. [TODO: clarify your reaction - what did you feel at that moment]

And then it got even more frustrating. The workflow didn't just "miss" the bug. One of its agents saw it. Raised it. And it was shut down.

The bug was like this. We have real-time pipeline progress updates. The new code we were reviewing subscribed the client to running and completed statuses. But in another part of the system - in files that no one touched in this task - the statuses were called processing and ready. The frontend was listening to one set of terms, the backend was using another. The progress on screen just froze.

One of the reviewers inside the workflow caught this and raised it as a blocking error. But the verifying agent - the one whose job is to double-check other people's findings - went looking for confirmation in the modified files. Didn't find it, because the proof was in a file that no one had changed. And following the instruction "if you can't confirm it - reject it", it threw out the finding.

The single agent just read the entire project. Found the file with the real statuses. Saw that the tests masked the bug using the same vocabulary. And sent the task back for revision.

I spent a million tokens on 22 agents. The one winner was the agent that could read the adjacent file.

What had to be fixed

After that, I changed four things in the workflow.

Re-verification had the biggest impact on the result. We essentially flipped its logic: the auditing agent no longer discards a finding if it cannot confirm it. It is required to prove that the finding is false. If it cannot do so, the finding remains. This is critically important when the agent only sees a small part of the project.

Run 3. Honest comparison: both see the full project

The third run deals with a larger task: the backend part of video processing, orchestration, retries, integration with external services. This time, both methods got access to the same slice of the project.

Result:

The fixes worked: there are no more false approvals. The workflow read adjacent files and caught issues at module boundaries.

One example. Model settings for video and music existed in the config, but the service client ignored them and always sent the same model every time. Part of the declared functionality was dead. In the previous run, the workflow would have discarded this finding – there would not have been enough context. Now it made it into the report.

But the most important thing is the comparison of findings.

There is no simple answer here of "the workflow is better" or "the single agent is better".

The workflow found a data race that the single agent missed. It uncovered an attack risk via external links. It pulled out a non-compliance with requirements. But the single agent caught two real bugs that the workflow did not. And for this breadth, the workflow consumes 15 times more tokens and 4-5 times more time.

Key takeaways

1. Configuration solves everything

On run 2, 22 agents confidently approved code with a bug. Not because the workflow is bad. But because we configured the context, review logic and verdict rules incorrectly. We fixed it – and on run 3, the workflow already found what the single agent had missed.

2. Context is more important than parallelism

One agent who had visibility into the entire project caught a bug that 22 agents with limited visibility missed. I later applied this principle to our regular skill reviews: now agents are required to check dependencies, not just modified files. They also have to justify every finding with concrete evidence. Review quality improved without any workflow changes.

3. For daily reviews, the workflow is too expensive

In our test runs, the multi-agent workflow consumed 12-15 times more tokens and took 4-5 times longer. It still missed bugs that a single agent caught.

For regular task or pull request reviews, one strong agent with access to the project is sufficient for us.

4. What we took from the workflow back into our skills

The main practical result of the experiment for NaCl is not the workflow itself, but the things we extracted from it and integrated into our regular skills: inverted review logic (reject a finding only if you can prove it is false), separate requirement tracing, stricter verdict logic, deduplication of issues based on root causes rather than symptoms.

We didn't roll out the entire workflow into our daily process - it's too costly. But the practices we identified in it are already working in our regular skills. The next article will most likely cover this.

When a 15x cost is justified

A multi-agent workflow makes sense if the cost of an error is higher than the cost of tokens.

In our experience, the clearest use cases are onboarding to an unfamiliar project without proper documentation, and incident post-mortems. Independent reviews of different layers make up for the documentation that someone was supposed to write but didn't. We saw this on the third attempt: each reviewer found their own category of issues, and none of them caught everything.

Another likely candidate is a pre-release audit of a large, high-risk change. We haven't tested this yet, but the logic is clear: it's better to spend 2 million tokens on an audit than to roll back production at 3 in the morning.