Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Dynamic Workflows in Claude Code

claude.com

Post reply on HN
Print view View original

51–60 of 160 posts

Re: Dynamic Workflows in Claude Code

#51

Post by aloknnikhil »

Jarred wrote: post #48
SkyPuncher wrote: post #12

I don't really get this. At this point, my limiting factor is not how quickly Claude can self-trudge through code. It's whether Claude is going to do the task correctly or not. 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.

Dynamic workflows, in my experience, make Claude more effective at complex long-running tasks. They help precisely with getting Claude to do the task correctly. It feels more like a bespoke build system for the specific task/project than prompting a freeform chat.

As long as agents are fuzzy (which they will continue to be with the Transformers architecture), the need to validate will continue to exist. I cannot imagine merging code without at least 1 human review.

Re: Dynamic Workflows in Claude Code

#52

Post by wilg »

bcherny wrote: post #49
wilg wrote: post #33

Earlier quoted context omitted.

I tried creating a workflow in Claude 1.9255.2 (1dc8f7) 2026-05-27T01:57:20.000Z 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

Looking

Still seeing it in new threads with Claude 1.9659.1 (193bcb) 2026-05-28T16:22:15.000Z

Re: Dynamic Workflows in Claude Code

#53

Post by mkw5053 »

bcherny wrote: post #19
thallavajhula wrote: post #13

Earlier quoted context omitted.

Hi Boris! Thanks for Claude Code. 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?

Hey, yep. A few things I personally used dynamic workflows for over the last few weeks: 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…

Very cool. What % of the CC team's engineering would you say goes into QoL (as opposed to new feature development)? Obviously some live in a grey area, while others are more clear like making CI faster.

Re: Dynamic Workflows in Claude Code

#55

Post by andrewmutz »

bcherny wrote: post #44
stvpwrs wrote: post #38

Earlier quoted context omitted.

Will workflows be reusable? I have a big use case of sharable and repeatable workflows for projects. Especially if this comes to Cowork.

Yes!

Any idea how soon dynamic workflows might be available in Cowork?

Re: Dynamic Workflows in Claude Code

#56

Post by MeetingsBrowser »

aloknnikhil wrote: post #51
Jarred wrote: post #48

Earlier quoted context omitted.

Dynamic workflows, in my experience, make Claude more effective at complex long-running tasks. They help precisely with getting Claude to do the task correctly. It feels more like a bespoke build system for the specific task/project than prompting a freeform chat.

As long as agents are fuzzy (which they will continue to be with the Transformers architecture), the need to validate will continue to exist. I cannot imagine merging code without at least 1 human review.

I've used agents quite a bit and I agree.

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

Re: Dynamic Workflows in Claude Code

#57

Post by wilg »

bcherny wrote: post #10

A few of us from the Claude Code team will be hanging around if anyone has questions! Very excited for this launch -- dynamic workflows have been a game changer for engineering here at Anthropic. Can't wait to hear what you think.

Can you please fix the issue where like 99.99999% of the time Claude tries to launch a subagent on its own accord it gets "Prompt is too long" and tries several more times, then gives up and does it without the subagent. Big waste of time and tokens and not getting almost any subagent advantages. Not kidding that this happens about 100 times a day.

Re: Dynamic Workflows in Claude Code

#60

Post by vadansky »

wrs wrote: post #28
SkyPuncher wrote: post #12

I don't really get this. At this point, my limiting factor is not how quickly Claude can self-trudge through code. It's whether Claude is going to do the task correctly or not. 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.

I think the theoretical answer here is this: "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-revie…

I don't know, maybe I'm doing it wrong but I feel LLMs add a slop debt, and each agent pass just exuberates it.

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.

Post reply on HN