Don't Waste Your Back Pressure
Moss names a pattern behind the projects that get real mileage out of coding agents: they build structure around the agent that gives it automated feedback on its own work. He calls this feedback “back pressure,” borrowing the term for a system throttling upstream flow based on what it can absorb. An agent that can run a build, read a type error, or compare a rendered page against an expectation corrects itself; an agent limited to editing files depends on a human to catch every missed import.
The argument is about where an engineer’s attention goes. Without back pressure, the engineer spends their own time on trivial corrections instead of the larger problem. With it, they can hand off progressively harder tasks and trust the loop to catch mistakes before the result reaches them.
Fichamento#
- Agents given only file-editing tools rely on a human for every piece of feedback, which limits delegation to simple, closely supervised tasks.
- Giving an agent a bash tool to run a build lets it read the failure and correct itself, freeing the engineer from checking syntactic correctness line by line.
- Expressive type systems act as a form of back pressure: they can make invalid states unrepresentable and surface edge cases, and languages with clear error messages (the author names Rust, Elm, and Python) feed that signal straight back to the model.
- MCP servers for Playwright or Chrome DevTools give an agent a way to compare a rendered UI against an expectation, removing the need for a human to describe layout problems manually; for non-UI work, MCP bridges to LSPs serve the same function through lints.
- Outside conventional engineering, the author cites proof assistants like Lean paired with AI (referencing the Erdős Problems work by Kevin Barreto and Liam Price, using Aristotle to formalize a GPT-5.2 Pro proof into Lean) and randomized fuzzing for CUDA kernel correctness as other domains where an automated correctness loop lets an agent keep iterating until the result is trustworthy.
- For spec-driven development, the suggested technique is generating documentation from an OpenAPI schema automatically, so the agent can compare what it produced against what it intended to build.
