Live data from Hacker News

Backpressure is all you need

lucasfcosta.com

81–90 of 133 posts

Re: Backpressure is all you need

#81

A very long post about a simple and very obvious idea with many different implementations. The three main problems are 1) API usage is deadly expensive 2) Claude is about to make all automation very expensive 3) all the flows where a model has the initiative are strictly biased towards unwarranted stops (checkpointing). Also, I won't call that "backpressure", there is no producer-consumer disbalance or something simi…

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 here, such as Codex's `/goal` and Claude Code's dynamic workflows[1]

The points about API usage cost still stand, but model intelligence is getting cheaper every month! No need to use the frontier model for every part of the work.

[1]: https://code.claude.com/docs/en/workflows

Re: Backpressure is all you need

#83
post #17

Earlier quoted context omitted.

Care to elaborate?

That quote shows an utter disregard for basic human decency. It is the responsibility of the person running the coding agent to make sure the resulting PRs are high quality. Putting that on your team mates, or worse, random open source project maintainers on the internet, is the definition of an extractive contribution.

It seems the OP agrees with you, and he's proposing a method for how to do so using agents.

Re: Backpressure is all you need

#84
post #13

Oh this is 101. Anyone not doing this? If not do it now!

Because your token use explodes?

Can be done on a claude pro. But if you are low on tokens then yeah probably stick to more of a non-thinking copilot type arrangement (which is fine!)

Re: Backpressure is all you need

#85
post #81

A very long post about a simple and very obvious idea with many different implementations. The three main problems are 1) API usage is deadly expensive 2) Claude is about to make all automation very expensive 3) all the flows where a model has the initiative are strictly biased towards unwarranted stops (checkpointing). Also, I won't call that "backpressure", there is no producer-consumer disbalance or something simi…

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 startup, it's a cheap idea - such as most LLM startups out there.

I don't see how models are getting cheaper - I clearly see the opposite trend.

Re: Backpressure is all you need

#86
post #17

Earlier quoted context omitted.

Care to elaborate?

That quote shows an utter disregard for basic human decency. It is the responsibility of the person running the coding agent to make sure the resulting PRs are high quality. Putting that on your team mates, or worse, random open source project maintainers on the internet, is the definition of an extractive contribution.

At work, there is a way to combat this behavior: approve everything without even reading the code.

Re: Backpressure is all you need

#87
I've been advocating for this approach for years. It's useful for any kind of data processing. You can't avoid race conditions without using some kind of queueing mechanism and you need backpressure to measure queue capacity. I built this into every aspect of https://socketcluster.io/ - From pub/sub channels, RPCs to event listeners.

Re: Backpressure is all you need

#88
Such a fantasy, it leads to two problems.

Increased complexity of your systems. Increased pipelines of your system.

You might reduce the likelihood of errors, but at an overproportinal cost of time it takes to complete (which some might argue is irrelevant, but has the cost of human context), and with an way higher time and focus needed for all bugs that the system doesnt work.

You’ll have to fix adapt and maintain all your verification layers, because just because you set them up they are not perfect.

Your testing pipeline becomes incredible slow and you need to maintain it as well.

It’s tremendously weaker than a hands-on approach.

I’ve written this exact same article in January and since then completely switched my position.

Good luck on everyone trying this. You shuffling your own grave and waste time.

Re: Backpressure is all you need

#89
post #79

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.

Maybe it's more like shift-left testing [1]? You're trying to move some checks to earlier in the process, if I understood you correctly, and get cheaper feedback loops. [1] https://en.wikipedia.org/wiki/Shift-left_testing

Test Driven Development. There's more than several /tdd skills that are popular.

Re: Backpressure is all you need

#90
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…

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.
Post reply on HN