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

111–120 of 160 posts

Re: Dynamic Workflows in Claude Code

#111

Post by sfourdrinier »

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.

Yes, that, accuracy, speed, and single computer-use.

I find those to be the limiting factors to speed.

I have extensive rules, I do extensive planning. Yet at implementation, the rules are not respected, errors are introduced, etc...

I spend more time fixing than writing code.

Then speed... Because of the fixes and bad code quality even with frontiers model speed makes a very big difference. I (agents) spend hours daily doing reviews and fixes. 5x speed boost would make me much more productive.

And when working super fast with agents, having only one computer is limiting. Even worktrees don't solve problems because I use things like convex, chrome use, etc... and it conflicts with each others all the time.

Still many problems to solve. It's already evolved so much in the last two years.

Re: Dynamic Workflows in Claude Code

#112

Post by fredoliveira »

unshavedyak wrote: post #88
bcherny wrote: post #23

Earlier quoted context omitted.

We generally build features into the Claude Agent SDK, which is shared by CLI, Desktop, VSCode, and cloud.

VSCode has an official client? Given IDE usage is being restricted from Claude Code via the CC SDK tokens going to the Claude API rather than your CC Subscription, i'm unclear which IDEs can actually use claude code now. Eg is Zed capable of using a Claude Code Subscription?

> is Zed capable of using a Claude Code Subscription?

Yes. Zed connects to Claude Code via ACP.

Re: Dynamic Workflows in Claude Code

#113

Post by hbarka »

tomjakubowski wrote: post #97
hbarka wrote: post #47

Earlier quoted context omitted.

Hi Boris. Love the velocity of features. Are you planning on adding a secrets manager? Enterprise workflows almost always require an encrypted parameter or calling a secret.

Why should secrets be built in? What's the issue with tool use and something like 1password's or Vault's CLI?

Another piece to pay for.

Re: Dynamic Workflows in Claude Code

#114

Post by zmj »

vadansky wrote: post #60
wrs wrote: post #28

Earlier quoted context omitted.

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 t…

If you want hard rules, use deterministic tools. Prompts are for fuzzy guidance.

Re: Dynamic Workflows in Claude Code

#115

Post by jeremyjh »

kian wrote: post #109
trjordan wrote: post #9

It feels like we're far past the point of where having AI do more faster is helpful. 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…

"In my experience, AI still drifts from what I meant it to do on anything bigger than building a widget." I've had code bases with tens of thousands of lines of code built from scratch that I hand-reviewed every line of and worked with the AI to improve, and haven't had this issue. I feel like a significant part of this is due to an involved /plan stage -- going back and forth on building out a plan for what you want…

There are certainly domains where AI is not so effective, but at this point I would agree that at least in terms of web development if you can't get effective results from agents at this point it is a skill issue. That skill can be learned, if you recognize that learning is part of the solution. I do think prior experience in product design, specifications & business analysis as well as engineering leadership are all extremely helpful. Its about putting the agent in a box so small that it really can't screw up; but its also about being able to review design and code rigorously - to see around corners and anticipate possible weaknesses etc. There is really nothing I have to do when working with an agent that I haven't already been doing for decades but it seems to me that a lot of developers have never found a single bug while reviewing someone else's code.

Re: Dynamic Workflows in Claude Code

#117

Post by dools »

The #1 goal for Anthropic and others is to take the longest running process possible and make it entirely opaque to the developer. It's the only way they can build a moat for a commodity. I would highly recommend building your own multi-stage orchestration flows because then you'll get a much better idea of where you need to be in the loop, and where you can save money. Once entire organisations are functioning only as extensions of Anthropic, they'll put the prices up and squeeze the shit out of the market.

Re: Dynamic Workflows in Claude Code

#119

Post by cush »

xcskier56 wrote: post #36

Are these “features” just hooks to get people to burn more tokens faster? I’m at the point where deciding what we should and should not do takes a lot more time than actually doing it. More agents just means running faster in potentially the wrong direction

They’re pure enterprise features - needed for massive legacy codebases with tens or hundreds of similar enough coding tasks - where there is a lived “cost” of not doing this type of work paid by every engineer working around it

Re: Dynamic Workflows in Claude Code

#120

Post by nebben64 »

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.

hey Boris, with multi-agent work, e.g. Agent Teams, following other agents is not possible because they work so fast. (my tmux panes are just matrix)

do you think something like a /speed config can be introduced to adjust agent working speed and let people adjust?

Post reply on HN