| 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 which would slow down the rate of submissions of an agent and weed out some low-quality submissions before hitting "downstream". I'm missing the connection to the actual capacity (or will) that the human developers have to review the submissions. |
- 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.)