When working with AI agents, a common bottleneck is the human review loop. If you ask an agent to "refactor this class" and it introduces a syntax error, you have to spot it and tell the agent to fix it. This manual feedback loop is slow, unscalable, and wastes your time.
"Back pressure" refers to the automated feedback provided by your environment (compilers, linters, test runners, type systems) that constrains the agent's output. By exposing these signals to the agent, you allow it to self-correct and learn from its mistakes without your intervention, allowing agents to run for longer, with higher quality final output.
Without back pressure, an AI agent relies entirely on you to validate its work. You become the validator. This limits the complexity of tasks you can delegate because the cost of verifying the work increases linearly with the task size.
User: "Refactor the UserProfile component to use the new API."
Agent: Generates code "Here you go."
User: Pastes into IDE → ❌ Error: 'UserAvatar' is not defined.
User: "You missed the import for UserAvatar."
Agent: "Apologies." Fixes it
❌ Figure: Bad example - The human wastes time acting as the validator
With back pressure, the agent operates in a closed loop:
The most immediate form of back pressure comes from the build system.
This is already built into most coding agents.
User: "Refactor the UserProfile component to use the new API."
Agent: Generates code
Agent: Runs npm run lint → ❌ Error: 'UserAvatar' is not defined.
Agent: Reads error → "I need to import UserAvatar."
Agent: Fixes code → Runs lint → ✅ Success.
Agent: "I have refactored the component and verified it passes linting."
✅ Figure: Good example - The agent uses the linter to self-correct before bothering the user
You can ask agents to write and run tests to verify logic, not just syntax.
User: "Write a function to validate email addresses."
Agent: Writes regex "Here it is."
User: "This accepts 'user@domain' without a TLD."
Agent: "Let me fix that."
❌ Figure: Bad example - Logic errors are caught manually by the human
User: "Write a function to validate email addresses. Create a test suite to verify it."
Agent: Writes function & tests
Agent: Runs tests → ❌ Failure: 'user@domain' should be invalid.
Agent: Adjusts regex → Runs tests → ✅ Pass.
Agent: "Function created and verified against 10 test cases."
✅ Figure: Good example - The agent uses tests as back pressure to ensure correctness
Tip: When asking an agent to write its own tests, be careful it doesn't write "lazy" tests that always pass. You might need to review the tests themselves or ask it to generate tests before the implementation.
Strongly typed languages (TypeScript, C#, Rust) provide excellent back pressure. The type checker creates a "guard rail" that prevents the agent from making invalid assumptions about data structures.
This is already built into coding agents, so you don't need to worry about it.
Advanced agents can use Model Context Protocol (MCP) servers to interact with real runtime environments. This allows them to "spin things up" and verify they actually work.
Playwright: The agent can write a web app, start a local server, and run Playwright tests against it to verify the UI works as expected, it can even take screenshots of the UI and compare them to the expected state.
.NET Aspire MCP: The agent can use Aspire to orchestrate a distributed application and verify service-to-service communication, by reading console logs etc.
You can structure your workflow so that one agent generates code and a second "Reviewer" agent critiques it. The Reviewer acts as a proof assistant, rejecting code that doesn't meet specific guidelines or security standards, providing back pressure before the human ever sees it.
If all else fails, you are the final layer of back pressure. 🫵
You should only be rejecting work based on high-level architecture, business logic, or user experience issues.
If you are rejecting work because of syntax errors or failing tests, you are "wasting" your back pressure on things machines can solve.
The goal is to stop treating agents as "text generators" and start treating them as "developers" that must prove their work compiles and runs before you see it.