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

51–60 of 133 posts

Re: Backpressure is all you need

#51

Post by coffeefirst »

Yokohiii wrote: post #44
wellpast wrote: post #4

I’m willing to be wrong but this industry-wide emphasis on AI creative/coding workflows seems way over-engineered. Ime successful creative execution looks like micro-iterations where each output informs the next creative move. I can build something incredibly fast from essentially caveman grunt instructions through an LLM harness, iterating as I go. Optimizing for feeding a huge plan to an agent sounds to me like a n…

LLMs are too flaky for high quality code. On tougher problems it's very common for an LLM to contradict itself and run in circles. It simply doesn't know what the right thing is, but on each turn it is super confident to do the right thing. Maybe I've chosen hardmode to learn C with LLM assistance, plus my pet project turned out to be a bit less trivial then anticipated. But I know that I have to think three times ab…

It’s not just you. My last dumb pilot program making a Pocket clone in Python also got stuck in a loop regularly, which should be its strong suit...

I suspect that the “right” way to use LMs in coding, including accounting for focus, control, and costs is not a settled debate. We probably haven’t even seen the best ideas yet. But I’m really dislike the maximalist approach.

Re: Backpressure is all you need

#52

Post by [deleted] »

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…

[deleted]

Re: Backpressure is all you need

#53

Post by dirtbag__dad »

_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.

Re: Backpressure is all you need

#54

Post by osigurdson »

kami23 wrote: post #41
_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…

This is where most of my productivity gains have come, I have a special harness I move from project to project now that does my testing orchestration, lots of my work day is setting up a prompt or two early and just letting them loop till they return evidence that the feature is working having gone through the big QA loop. I've slowly been optimizing for token use through the stack and Claude ends up making very tigh…

I can see how you could avoid regressions this way, but what do you add to your harness to prove that a new feature is working?

Re: Backpressure is all you need

#55

Post by EMM_386 »

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)

- Clear and repeat until done

I've never had to overcomplicate this and it's worked both on enterprise-scale projects and personal projects. I am not sure what I'm missing - if anything.

Re: Backpressure is all you need

#56

Post by kami23 »

osigurdson wrote: post #54
kami23 wrote: post #41

Earlier quoted context omitted.

This is where most of my productivity gains have come, I have a special harness I move from project to project now that does my testing orchestration, lots of my work day is setting up a prompt or two early and just letting them loop till they return evidence that the feature is working having gone through the big QA loop. I've slowly been optimizing for token use through the stack and Claude ends up making very tigh…

I can see how you could avoid regressions this way, but what do you add to your harness to prove that a new feature is working?

I have it record a series of gifs or videos that I look over. If something looks off I'll dig into it, but I break down work into very very small chunks that are usually easily verifiable or don't require multiple steps.

Another thing I have in the general sdlc process is having it add enough logging to verify features are turned on, configured as we expected, and that becomes enough feedback for most of my features.

I've been mostly focusing on being able to replicate this across stacks greater than 3 projects so far (with the eventual goal of having an agent be able to orchestrate our complete infra stack, and this being a large component of a DR plan to rebuild).

None of this is really new for us, I'm just the most knowledgeable in my group in how the different products across teams glue together so I've been creating these rube goldbergs as a prototype, and then having it iterate on codifying the parts that don't need a constant LLM. We were blessed to have an engineer a decade ago build out tooling for local container automation that matches 95% of the deployed infra stack. That last 5% sucks when you fall into it, but that's always been a truth. I've added and expanded the tool over the years with making it act more like the deployed environment networking wise, but a lot of things don't end up working well in docker containers on M series macs when most of our complicated virtualization in our private cloud can't run on them yet...

Re: Backpressure is all you need

#57

Post by pstorm »

kami23 wrote: post #56
osigurdson wrote: post #54

Earlier quoted context omitted.

I can see how you could avoid regressions this way, but what do you add to your harness to prove that a new feature is working?

I have it record a series of gifs or videos that I look over. If something looks off I'll dig into it, but I break down work into very very small chunks that are usually easily verifiable or don't require multiple steps. Another thing I have in the general sdlc process is having it add enough logging to verify features are turned on, configured as we expected, and that becomes enough feedback for most of my features.…

I’ve been building this out too, and your comment made me realize the missing piece for me. I’ve given the agents tools to validate its own work, but I haven’t improved the experience of humans verifying the agents’ work.

Re: Backpressure is all you need

#58

Post by dcrazy »

NamTaf wrote: post #28
0x696C6961 wrote: post #5

Earlier quoted context omitted.

Yeah it's wild watching so many people decide waterfall is great all of a sudden.

Never mind stumbling into proper engineering principles like having documented, testable requirements specifications.

I”ve been pretty happy with this side effect of the agentic coding bubble.

Re: Backpressure is all you need

#59

Post by 0x696C6961 »

bluGill wrote: post #47
0x696C6961 wrote: post #5

Earlier quoted context omitted.

Yeah it's wild watching so many people decide waterfall is great all of a sudden.

Every large project in the coming back to waterfall. While the problems are certainly known and it was ultimately developed as a straw man, everything else ends up working worse. That said, you shouldn't be thinking pure waterfall as it's drawn up as a strawman, but rather a waterfall variation with feedback loops. But in the end, in very, very many cases, you have to know an end date in order to get things done beca…

"waterfall variation with feedback loops" lol next we're going to have "agile where you plan everything up front"

Re: Backpressure is all you need

#60

Post by _zoltan_ »

osigurdson wrote: post #54
kami23 wrote: post #41

Earlier quoted context omitted.

This is where most of my productivity gains have come, I have a special harness I move from project to project now that does my testing orchestration, lots of my work day is setting up a prompt or two early and just letting them loop till they return evidence that the feature is working having gone through the big QA loop. I've slowly been optimizing for token use through the stack and Claude ends up making very tigh…

I can see how you could avoid regressions this way, but what do you add to your harness to prove that a new feature is working?

for us it's (usually) very easy as I work on performance optimization. a non-negligible part of this is correctness and verifiability, so we already have some of that.

to give you an example just recently I've coded a feature that for our shuffle operation can report which channel did the bytes flow through (as the PR giving us the plumbing underneath has landed upstream recently). what this basically means is that you run the shuffle, you know you've shuffled X bytes (because you have stats on both ends) and then you need to attribute them to different layers. on the first iteration, the count was off. the agent went, debugged, fixed, iterated, and then it was 1.5% off. again, it went, iterated, ... and now we're fine.

part of the task description was that the breakdown must match the known amount of bytes we're shuffling, so the agent took this upon as a self-verification point. so besides running our normal, boring unit tests, integration tests and end-to-end verification harnesses (which it not only has programmatic/cli/API access, but are documented in .md files for projects), it could use this criteria on top to verify.

looking at /usage, my API duration was 2h 43m, and on top of that:

      claude-haiku-4-5:  2.7k input, 115.3k output, 16.3m cache read, 867.9k cache write ($3.30)
       claude-opus-4-8:  46.9k input, 555.0k output, 166.6m cache read, 2.9m cache write ($115.77)
Post reply on HN