I need more mechanisms for controlling long-running sessions and dynamically injecting my thoughts, correction, and nudges rather than faster ways to burn through my tokens without knowing if the results are going to be correct.
"Agents address the problem from independent angles, other agents try to refute what they found, and the run keeps iterating until the answers converge."
So you will be supplying the "ground truth" (test suite, detailed spec, whatever) and empower an agent to use it to guide the other agents. Currently a lot of people do this sequentially in the form of multiple code-review passes by fresh agent sessions looking at the work of previous sessions.
Adversarial models are a longstanding technique in ML so it makes sense they would try to go this way.
Like I had an LLM implement a spec and said it was done... Except it had a ton of `casts` everywhere. Okay, my bad, I should have been clear "NO CASTS", so I use the LLM to remove the casts, except it just kept making things more and more complicated and ugly.
It took me taking a break and having a shower thought to realize all the ugliness is because one type should have been broken up into 2, which would remove a ton of generics and code. But Claude never suggested that, it was always "we need at least one cast here, or we need 1000 LOC of generic factories". I tried multiple new sessions with various prompts too.
Maybe one day soon LLMs could pay off their own slop debt but at least right now I don't trust them to write code unseen.
Edit: Maybe the correct action should have been to delete everything and make it re-write everything from scratch with the clear "NO CASTS EVER" rule. But still the point is feels like having LLM clean up after an LLM doesn't work well enough to just have keep it in a loop and never look at what it does.
I don’t see them fixing this any time soon, and thus human in the loop is a requirement to use these tools effectively. That is unless you love your slot machine dopamine rush enough to ignore quality gates and respect for your peers time.
I've had to put a fair chunk of effort in to skills that will run deterministic mechanisms to unslop a codebase (cyclomatic complexity grading has been really helpful here) as invariably some amount of guidance around principles will be missed over time. I've found it does help, though. Certainly I'm getting overall better results from Flash and Sonnet over multiple runs for fairly modest token increases. GPT 5.5 less so, but that's because it scores better in a first pass. I won't really know until I gauge it at the end of my sub month which has been more cost efficient for me all things considered.
The pure LLM, no human intervention vibe-coded PRs on Bun since the vibe-rewrite to Rust contain the worst coding horrors I've seen in 20 years of programming.
Setting aside the quality of the change itself (I would have done it differently, for sure: it is pretty straightforward to build a safe abstraction out of this type), the utterly pointless "source-text consistency test" added here is easily the worst example of "test repeats implementation" I have seen in my career:
https://github.com/oven-sh/bun/pull/30728/files#diff-863477b...
Sure, ‘human in the loop’ and all that jazz, but I feel like my knowledge suffers even with this approach. I have to use llms w pinpoint focus to get decent results.
The original copilot completions behavior might be peak llm performance for coding, sans having an agent write boilerplate and such.
But each prompt will cost your company, 10 to 15 million dollars. An extra 20 million if you ask them to review the code and improve the comments.
It feels more like a bespoke build system for the specific task/project than prompting a freeform chat.
The current baseline workflow is something like agent output -> human review -> agent refinement -> human review -> agent refinement -> ...
But agents are capable of making meaningful improvements to their own output. I'm hoping dynamic workflows move towards something like:
agent output -> agent review -> agent refinement -> (cycle to fixed point) -> final human review
Rewriting Bun with dynamic workflows
An example of what dynamic workflows can unlock at scale is the recent rewrite of Bun. Jarred Sumner used dynamic workflows to port Bun from Zig to Rust with 99.8% of the existing test suite passing, roughly 750,000 lines of Rust, and eleven days from first commit to merge. One workflow mapped the right Rust lifetime for every struct field in the Zig codebase. The next wrote every .rs file as a behavior-identical port of its .zig counterpart, hundreds of agents working in parallel with two reviewers on each file. A fix loop then drove the build and test suite until both ran clean. After the port landed, an overnight workflow addressed unnecessary data copies and opened a PR for each for final review. While not yet in production, all of this was handled by dynamic workflows. Jarred will be writing about this more in the future.
Mechanical refactors are relatively straight forward for agents.
A rewrite of bun in Rust is unlikely to be a trivial mechanical refactor. And if you are not sharing what the complicated parts were, or how big it is, how do we assess that the task was similar?
Unless you are intimately familiar with the bun codebase and you've already made that assessment.
It's telling that they used "rewrite Bun in Rust" as the proof point here. It's cool! But the vast majority of software engineering doesn't start with tens of thousands of tests, where making them pass is the whole job.
In my experience, AI still drifts from what I meant it to do on anything bigger than building a widget. My time is spent suspiciously reviewing output for changes the agent snuck in, or invariants it broke. I talked with a friend recently where the agent broke the test harness badly enough that none of the tests mattered for 3 weeks. They did pass, though, so CI never complained.
There's something at the intersection of context engineering, managing that sloppy pile of markdown plans, and good old fashioning system understanding that's the real bottleneck.
Why'd you guys not want to allow the traceparent in hooks, but allowed the session.id? Any plans on changing that?
Maybe blasphemy, but will workflows be able to use non-Anthropic LLMs (e.g., delegating some steps to local models, but design and review by Claude)?
thx for all that amazing tec and save ai
Is there an example of how y'all use Dynamic Workflows internally that you could share with the rest of us here so that we can mimic something similar?
1. Autonomously landed 20+ optimizations to reduce Claude Code's token usage by ~15%
2. Ported tree-sitter, color-diff, yoga-layout, and a number of other WASM and Rust native modules to TypeScript, improving CPU and memory use by 2-10x in the process
3. Made our CI faster, and repeatedly found and fixed flaky tests (with /loop)
4. Migrated from regex-based bash static analysis to tree-sitter, reducing false positive permission prompts by 45%
5. Reduced Claude Agent SDK startup time by 61%, by repeatedly profiling and optimizing the startup path, putting up a number of PRs in the process
6. Shipped 69 code simplification PRs, deleting >10k lines of code
Curious to learn more on this (unless there’s a write-up in the works). I’m naive on this matter but:
1. is this because it’s higher cost when passing objects back and forth across the JS/native boundary? 2. Does this have anything more specific to do with use of Bun? 3. is the stance for claude code then to keep all the deps in raw TypeScript? 4. How do you folks keep these ported deps up-to-date?
and got
API Error: 400 messages.3.content.11: `thinking` or `redacted_thinking` blocks in the latest assistant message cannot be modified. These blocks must remain as they were in the original response.
Tried again in
Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z also but may need a new chat
Eg is Zed capable of using a Claude Code Subscription?
Its like you guys aren't even aware of the primary problem you are all facing: your token burns aren't paying off anyore against standard coding -- and looking net negative. I have to ask, are you this unaware of your core problem set here?
There are no any examples, proofs, or scenarios that show why there is improvement either in complexity or reliability of the solution or effeciency to the path of the solution. I'm baffled.
Like 90 agents ran to do a code review of a fairly small package I have.
They're really looking for us to increase token usage aren't they?
I feel like there are more efficient ways to tackle the issues given.
Is this a way to increase token burn?
I thought we covered this with Claude's C compiler. What changed?
IMO, this style of workflow/agentics is how all SWE'll look like long term. Automate everything into a big pipe-y thing. How it's gonna be modelled is up in the air though. lots of different approaches:
mine: https://github.com/portpowered/you-agent-factory
https://github.com/ComposioHQ/agent-orchestrator
You can achieve a similar result manually prompting to use subagents, yes. But the TUI for in flight dynamic workflows is really nice - great visibility into exactly what's happening.
Honesty, for anything larger than a 1 shot PR, it's worth firing off a workflow for better automatic context management alone (more work done in the first 20% sweet spot)