Nothing in your review loop opens the app
The shape is always the same. The agent says done. The review comes back clean. The linter is quiet. You merge, and the send button still 500s the first time someone clicks it.
Nobody did anything wrong, and that is the part worth sitting with.
Reading is not running
An AI reviewer reads the diff. A human reviewer reads the diff. Both are good at it now, better than a year ago, and both are doing the same thing: reading.
Reading tells you the code looks right. It can’t tell you the feature works, because the feature only exists when the app is running and something clicks it. A reviewer can be right about every line and the button can still fail, because the bug was in the thing nobody ran: the seed, the env var, the API that answers differently on the deployed build than it did on localhost.
So walk your own loop once, from “agent says done” to “merged”, and name the step where a real browser opens the build. Not the step where someone reads the PR. The step where someone clicks. In a lot of loops, mine included for a long time, that step isn’t there. Confidence stacked on confidence, and nothing in the stack ever opened the app.
How I ended up as QA again
When I wrote the feature myself, the loop didn’t need that step. I’d clicked the button fifty times before the PR existed. Review didn’t have to open the app because I already had.
Then I started building with agents, and that quietly stopped being true. The agent clicked nothing. It said “done, it works”, and sometimes it didn’t. So I’d check. Run localhost, click through, become QA all over again. The code got cheap and the checking didn’t move with it; it moved back onto me, after the fact, at the exact moment I thought I was finished.
That is the honest version of “agents make you faster”. They do. And some of the minutes you save come back as minutes spent proving the thing they made.
Who pays when nobody clicks
Somebody opens the app eventually. The only question is who, and when.
If you have QA, it’s QA, after merge, on staging. A broken button becomes a ticket and a day. If you don’t have QA, and a lot of people shipping with agents don’t, it’s nobody on your side. You find out from a customer, or from the client on the call where you meant to show it off.
A QA hire is a salary you decided not to pay. A customer finding the bug is a cost you didn’t decide anything about. It just arrived, with your name on it.
Then it clicked
Trust isn’t something you decide. It’s something you’re shown.
That sentence is how I now grade any step in a loop. Does it show me the feature working, or does it tell me the code looks right? A green check from something that only read the code is the second kind, however smart the reader. It’s a second opinion on the same text.
So the question for your loop stops being “is the reviewer good”. It becomes: at what point does a real browser open the deployed build and click the thing the PR says it ships, and what does that step leave behind? A screenshot in Slack is a step. A recording is a better one. “We’ll find out” is the gap.
The audit you can run today
You don’t need a tool for this part.
- Write the loop down, every step from “done” to merged.
- Mark each step R or C: reads the code, or clicks the app.
- If there is no C before merge, that’s where the next bug is already sitting. Decide who owns it. If the answer is “a customer”, say that out loud. It’s a choice, and a choice is cheaper made on purpose.
I built Tada to be the C step: when the preview deploy comes up, it opens the build in a real browser, walks the flow the PR says it ships, and a pass leaves footage on the PR. But the audit is the bigger half, and it works with a person in that slot too. Find the step that opens the app. If it’s there, protect it. If it’s not, now you know what your review loop has been quietly promising on your behalf.