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

Backpressure is all you need

lucasfcosta.com

Post reply on HN
Print view View original

101–110 of 133 posts

Re: Backpressure is all you need

#101

Post by dbmikus »

pshirshov wrote: post #85
dbmikus wrote: post #81

Earlier quoted context omitted.

To stop agents from pausing for checkpointing, you can have a deterministic outer loop that re-runs until a stop condition is met. I think teams need to be able to write nested workflows that transition between code-led and agent-led, with either supporting human-in-the-loop checkpoints. Been iterating on what this should look like at our startup ( https://www.amika.dev/ ). Model labs are also improving capabilities…

It's hard to get that outer loop done, especially considering that Claude doesn't let you automate the harness anymore (it gets prohibitively expensive). Same for gemini. The only option is Codex. /goal is a dynamic workflow itself, from what I know. Dynamic workflows do not hold the initiative (and can't use any libraries or I/O). Dynamic workflows do not prevent checkpointing. I don't see the actual point of your s…

Claude Code's dynamic workflows are AI-generated JavaScript, so unlike `/goal` they can in theory import libraries and perform I/O (not sure that they can currently).

On checkpointing: I explained myself poorly. You're right that using higher level workflows doesn't turn off checkpointing. One can simply make harnesses non-interactive, but that can make models lose coherence over long tasks (because they can't ask for feedback). A higher level coordinator (/goal, CC dynamic workflows) is designed to provide this feedback without human intervention.

On price: older models keep getting cheaper, and most tasks don't need frontier capability. (I'm ignoring the part about subscription subsidies right now, and just talking about API price for tokens)

On my startup Amika: we run programmable cloud computers for agents, plus the workflow systems to guide them. We let people run any agent (Codex, Claude, etc.), prompt it from anywhere (Slack, web, CLI + SSH, API). It's like devboxes for humans + agents, with guardrails[1] to deterministically ensure things about the changes coding agents make (ie don't let agent modify module boundaries, require every DB query carry a multi-tenant org ID filter).

Maybe our website is bad at explaining it, in which case I appreciate any feedback!

[1]: https://docs.amika.dev/guides/code-annotations

Re: Backpressure is all you need

#102

Post by teleforce »

_zoltan_ wrote: post #9

"In this post, I’ll cover a third, not-so-obvious approach: building ways for the agent to validate more of its own work before a human has to step in. " this has been an obvious thing to do since at least January (since Geoffrey Huntley published "everything is a ralph loop"), and this is how I've been working: build enough orchestration tooling to be able to automate everything: development container bringup, build…

The rest of the paragraph explanations are more important.

"The goal to make longer unattended sessions safe enough to be useful without fully removing the human from the loop. It should also reduce the number of low-quality PRs your teammates have to review for details the agent should have caught itself."

>safe enough to be useful without fully removing the human from the loop

This is the fundamental concept for AI usage, assistance and adoption for every fields not only code generation.

Essentially AI including LLM, ML, DL, is just a tool, like any other automation tools operating based on the principle of expert-in-the-loop as safety and quality gatekeeper, for sensible and responsible decision making [1].

[1] Domain expertise has always been the real moat (brethorsting.com) (519 comments):

https://news.ycombinator.com/item?id=48340411

Re: Backpressure is all you need

#103

Post by visarga »

EMM_386 wrote: post #55

I always use a standard workflow and it has never been a problem. - Define the task and the goal, write a short spec document (markdown is fine) - Point the agent at it in plan mode and have it write the plan to disk with phases. Iterate on its plan if necessary here and now. - Have each agent tackle a phase and have it update it as a living document (switch models if some phases are more difficult than others) - Cle…

I think what you are doing is good, I also have a similar workflow, but the idea here is to automate some of your manual approval work with coded tests. Since they are easy to generate, have as many as possible, think hard about what to test for, and the agent will deviate less and be more autonomous.

Re: Backpressure is all you need

#104

Post by closeparen »

_zoltan_ wrote: post #9

"In this post, I’ll cover a third, not-so-obvious approach: building ways for the agent to validate more of its own work before a human has to step in. " this has been an obvious thing to do since at least January (since Geoffrey Huntley published "everything is a ralph loop"), and this is how I've been working: build enough orchestration tooling to be able to automate everything: development container bringup, build…

It is too bad that so many companies have built these huge microservices beasts where you cannot run much more than unit tests locally, and you pretty much have to guess at the impact of your change until you have merged it, deployed it, and turned on the feature flag for your own account / test account. This loop is slow, which is perhaps a cost they are willing to pay, but it is also not safe for agents, which will be a massive setback.

Re: Backpressure is all you need

#106

Post by kqr »

xg15 wrote: post #19

Isn't this a bit of an incorrect usage of the term "backpressure"? OP quoted the correct definition right at the start: > In systems engineering, backpressure is the mechanism by which a downstream component signals upstream that it can't accept more work (the "downstream component" being the human reviewer in this case) But the measures they propose don't actually do that. They are more like fixed throttle elements…

It is incorrect, and that annoys me probably more than it should. Lean people have talked about this for a long time:

- single-piece flow means not making large batches of things and then sending them all downstream at once, but instead working on one thing at a time so downstream has a chance to reject before too much of the wrong thing is produced.

- autonomation (or jidoka) means giving the machine the ability to detect when something is wrong and not continue at that point.

- poka-yoke is a process that forces results to be conformant by construction.

Any and all of these terms would be better than backpressure in this context.

(This made me realise that lean people have been spending decades dealing with the problems we encounter with the new robots that write code. Half of the lean philosophy is about setting up processes and structures that have positive optionality on people's creativity, without undue requirement on their level of responsibility. That's exactly what we want for robots that write code too. We want to capture the benefits of what they do well, without suffering from their innumerable mistakes. But we can't just chastise them for making mistakes, so we have to think the way lean people do.)

Re: Backpressure is all you need

#107

Post by lovich »

ip26 wrote: post #95
lovich wrote: post #90

Earlier quoted context omitted.

What’s the cost of all that though? I don’t doubt that productivity could be gained but when I see articles like the one on the Open Claw guy spending 1.3 million on tokens in a single month I am reminded of drag racing engines that can reach incredible speeds but also need to be completely rebuilt after a single race.

Depends on the quality of your validation loop. Can the agent find the bug in a five second unit test, or does it have to run the full deployment test? It also presents tradeoffs in compute budget. Cycles spent executing large arrays of tests could mean less tokens spent debugging.

> Depends on the quality of your validation loop. Can the agent find the bug in a five second unit test, or does it have to run the full deployment test?

I am not asking about time or completeness. I am asking if this person is spending 1 dollar to make more than a dollar, or if they are spending 1 dollar to make less than a dollar.

Any other criteria is not necessary to consider, if the activity is not profitable.

Re: Backpressure is all you need

#108

Post by leodavi »

ricksunny wrote: post #33
lucasfcosta wrote: post #29

Earlier quoted context omitted.

Author here. Well noted. I do think backpressure might not be the ideal analogy/term. It comes from previous posts I’ve come across, but I haven’t considered exactly what you mentioned. That’s on me.

lol your comment sounds like a Claude apology

Insincere apologies ought to be mocked to shit but this apology seemed well-meant. (I know you're not mocking them and the last sentence is actually something Claude would say.)

I post this angry comment because LLMs are colonizing the language we use for creating an earnest and genuine tone in online discussion and I sometimes wonder if the suspicion surrounding LLM-ish language is worse for the health of our online spaces than the LLM slop itself. Thinking about it, I don't think it is; and it would be impossible to measure anyway.

Re: Backpressure is all you need

#109

Post by oblio »

dirtbag__dad wrote: post #53
_zoltan_ wrote: post #9

"In this post, I’ll cover a third, not-so-obvious approach: building ways for the agent to validate more of its own work before a human has to step in. " this has been an obvious thing to do since at least January (since Geoffrey Huntley published "everything is a ralph loop"), and this is how I've been working: build enough orchestration tooling to be able to automate everything: development container bringup, build…

You can get really far with the 20x Claude Code and Codex plans. They are many orders of magnitude cheaper than api calls.

Enjoy that until the token economy comes crashing down on you.

Re: Backpressure is all you need

#110

Post by slow_typist »

Who is going to write tests? But I like the fact that this approach implicitly approves of the stochastic parrot model. I mean, given enough computing power and sufficiently well made tests, I could just generate random strings of increasing length until one compiles into a program that passes all tests, mission accomplished. Like one million apes typing on one million typewriters.
Post reply on HN