QA the stack, not every pull request
Decide up front which work gets an independent QA agent, then hand it the whole stack of commits on one branch. It fixes the mechanical bugs before a person reads the work.
Having agents write the code has not made QA go away. The QA role still exists, and engineers still have to do QA. What has changed is who does the first pass: in a factory we build, that is an agent.
Most teams have not caught up with this. An engineer directs an agent through a feature, opens a pull request, and the first independent look at the work comes from a person on the QA team. That person then finds inputs nobody validated and states the code handles wrong. Those are real bugs, but an agent could have found them. An afternoon a person spends on them is an afternoon not spent on the questions only a person can answer.
We fix this in two steps. Decide at the start of the work whether it gets an independent QA review agent. Then, instead of reviewing every pull request, hand that agent a whole stack of commits on one branch and let it fix what it finds there, in one pass.
Decide before you build
When you scope a change you already know roughly how big it is: the size of the estimate, how much of the system it touches, how complex the feature is. That is when to decide whether it gets an independent QA review, before the work starts and not after something slips through.
Independent means a brand new context. The agent that wrote the code made every assumption in it, and it reads its own work through those assumptions. A QA agent started fresh gets the change and what the change is meant to do, and reads the code cold, the way a reviewer would. In Birgitta Böckeler’s terms for a harness, it is an inferential sensor, one that observes what an agent did after it acts and helps it self-correct.
Not every change needs one. A copy fix does not. A feature with a new form, a few new states and an endpoint behind them does. Making the call up front puts the review in the plan. The QA agent then starts at the end of the task because the plan says so, not because someone remembered.
What your QA people should be reviewing
If you skip that decision, your QA team becomes the first independent review, which is a disservice to them. Their job has already moved. They do more human review now, of the functionality, the design and the implementation: is this the right thing, and was it built in a way we can live with. “Does this work correctly?” is the question an agent can answer.
Without a QA agent, a person finds the unvalidated input, writes it up, sends it back and waits for the fix, and then does it again for the state that is wrong. None of those round trips needed a person’s judgment, and every one of them is time a QA agent would have saved.
When a QA agent runs at the end of the task, it fixes those bugs before a person opens the work, and the human review starts where it should. Böckeler puts the goal of a harness the same way: not to remove human input, but “to direct it to where our input is most important.”
Stack the work, then review the stack
You do not need QA on every pull request. What pays off is stacking the work: build a larger change set as a series of commits, one change per commit, each with a message that says what it does. When the stack is done, give the whole thing to the QA review agent.
The commits and their messages are the agent’s map. It walks the stack in order, sees what each step was meant to do, and checks the step against that. It pulls a single branch, works in that branch, fixes whatever it finds there, and hands the branch back in one go.
If you run QA per pull request across the same stack, the agent does all of that once per branch: check out, install, build, test, review, then switch to the next branch and do it again. A fix made low in the stack has to be carried up through every branch above it, and each push starts another CI run.
Where the time and money go
CI and CD systems are already busy. In our experience, agents push more changes than most pipelines were sized for. A CI run for every QA fix on every pull request adds to a queue everyone is waiting in. One branch with one round of fixes is one run.
Tokens cost money too. Switching branches, reinstalling, recompiling and carrying fixes up a stack all burn an agent’s tokens, and none of it is work that needs an agent. One branch removes most of it.
The most expensive line is people’s time. A QA engineer who is not chasing unvalidated inputs is reviewing the design and the behavior, which is the review you hired them for.
The workflow
- When you scope the work, decide whether it gets an independent QA review, from the size of the estimate and how complex the feature is.
- Build it as a stack of commits on one branch, each with a message that says what it does.
- At the end of the task, start a QA review agent with a fresh context on that branch. It walks the stack commit by commit and fixes what it finds on the same branch.
- Your people review the result for design, behavior and implementation, and the gate merges it.
So this gets QA into the work early and saves your QA team’s time. It saves the company money, large or small, and gets more out of the agents you are already paying for.
If you want a QA agent at the end of your stacks, talk to us.