Last week I was reviewing code an agent had written. Same error, three iterations in a row. Different context window, same wrong pattern. I fixed it. Again.
That's the moment you realize you've become the CI pipeline.
The article "Don't Waste Your Backpressure" by Moss puts a name to something I've been bumping into for months: engineers are burning their attention on feedback the machine could generate itself. If you've read my guide for new AI agent developers, this lands as the natural next step: we're the bottleneck, and backpressure is how you fix that.
The concept's borrowed from systems design. Backpressure is the signal that slows a producer when a consumer can't keep up. Here it means something slightly different: automated signals that tell an agent "no, that's wrong, try again."
When those signals exist, agents iterate on their own. When they don't, you do it for them.
What good backpressure looks like
A compiler is the obvious one. Let the agent run its code, read the error, fix it. Most teams already do this.
The less obvious ones are where it pays off.
Type systems. Rust and Elm make invalid states unrepresentable. The agent doesn't need you to say "that won't compile" because the type checker says it first, faster, every time.
Visual rendering. Playwright MCP or Chrome DevTools lets an agent screenshot its own UI output. It can see what it built. If a button's off-center or a layout breaks on mobile, the agent catches it before you open the browser.
Domain verification. For something like CUDA kernels, fuzzing gives the agent a signal it couldn't reason itself toward. Lean proof assistants do the same for correctness proofs.
Another underrated source: other agents. I've written about multi-agent review setups where agents argue over each other's output. That's backpressure too. Automated and parallel, and it doesn't cost your attention.
The pattern's the same everywhere: give the agent a source of truth it can query without you in the loop.
Why most teams skip this
Because it's infrastructure work. It doesn't feel like "building the feature." Running Playwright in an agent loop, wiring up a type-checked language, setting up a build harness the agent can invoke, all of that is work that comes before visible progress.
So it gets skipped. And then engineers spend their days doing error correction.
The math is simple. An hour building automated feedback saves a hundred hours of manual review. The hard part is that the hundred hours comes gradually, in five-minute chunks, disguised as "just checking the output."
Every production pattern that actually works shares the same foundation: the agent knows when it's wrong before you do.
What I'm taking from this
I've started treating "what feedback can the agent get without me?" as a first-class design question for any agent feature I build.
Not "how do I prompt it better?" That's the trap. Prompts fix one failure mode. Feedback loops fix all of them, including ones you haven't hit yet.
Build the loop. Step out of it.