"Backpressure" is testing, rebranded - and it matters more than ever

What’s “backpressure”? Underneath the new name, it’s just software testing and QA - a discipline that had basically disappeared from most teams, now rebranded and more important than it’s been in twenty years.

Where testing went

In my first job, we released onto Solaris mainframes exactly twice a year, and testing was a dedicated two months out of that six-month cycle. That made sense for its era. It didn’t survive contact with agile, scrum, DevOps and continuous delivery, and it changed fast: testing effectively became “everyone’s responsibility,” which is another way of saying it became no one’s responsibility in particular. Developers are, on the whole, bad at writing tests and don’t enjoy doing it. Test coverage as a single blanket percentage is close to useless as a quality signal.

So we built CI servers, did TDD when we remembered to, DevOps teams tested in production behind canary releases and feature flags, and leaned on a pile of bandaids instead of a heavyweight testing phase. That got code into production quickly, and monitoring told us when something broke. It worked because it relied on developers doing a reasonably good job of checking their own work met the goal before it shipped.

Why AI breaks that assumption

Coding agents make mistakes, the same way developers do. But they are meaningfully worse than developers at catching their own mistakes. A developer will click through a few happy paths in the browser, or tap through a handful of edge cases on a phone, before calling something done. That’s slow for an agent to do well - it’s relying on screenshots, it doesn’t read visual layouts reliably, and it has no real instinct for “this looks wrong.”

Without automated tests standing in for that instinct, the human operator ends up as the one finding the bugs. And being a manual tester for a machine that makes a lot of mistakes is deeply frustrating - worse, emotionally, because the agent gets the fun part (writing the code) and you get stuck with the tedious part (proving it’s actually right).

Backpressure, concretely

“Backpressure” is just automated testing that runs inside the loop, so the agent finds out it’s wrong and can try again without a human in that particular loop. It inherits the oldest tension in all automated testing: how do you balance speed against coverage and correctness?

Too heavy, and the agent churns for hours even on small changes, most of its time spent waiting on tests. Too light, and the agent thinks it’s done when it’s actually broken something - and you’re back to the exact frustration above, just with extra steps.

We’re all in the very early days of figuring out where that balance sits for agentic work specifically. One approach a team described to me recently, which they’re still validating but like the feel of:

• do TDD, but delete the unit tests before committing
• only run integration and end-to-end tests before commit, and tell the agent up front that they’re heavy, so it should prove correctness as much as it can before running them
• have the agent extend existing integration tests to also cover the new feature wherever possible
• only create new integration tests when it genuinely has to
• so the entire persisted test suite ends up being integration and e2e tests, not unit tests

It’s too early to know if that specific shape generalises. But the underlying point holds regardless of the exact recipe: testing isn’t optional infrastructure you can skip while “everyone’s responsible” quietly means no one is. With agents in the loop, it’s the mechanism that turns a fast, error-prone worker into a fast, self-correcting one - and right now, most teams don’t have nearly enough of it.