Build AI quality gates that reject bad code on purpose
Most AI coding pipelines are optimized for how long an agent can run unattended. Developer Josh Owens went the opposite direction: he built a pipeline optimized for how much work he can prove is right.
The result is the A(i)-Team plugin for Claude Code, started January 15, 2026. Eight named agents. Half of them exist for one reason: to find something wrong with what the other half built.
️ Why Rejection Agents Exist
The software industry already has a proven answer to “how do you keep quality high when work moves fast.” It’s called definition of done, maker/verifier team structures, and code review before ship. A developer writes. A different developer reviews. An SDET or QA engineer checks before it goes live. Tests protect intent after the code is written.
The A(i)-Team plugin mirrors that structure with agents. One agent builds. A different agent tries to break it.
The numbers back up why this matters. CodeRabbit analyzed 470 real GitHub pull requests (320 AI co-authored, 150 human-only) and found AI-generated PRs carried roughly 1.7x more issues overall: 10.83 issues per PR versus 6.45 for human-only work, and 75% more logic errors specifically. Owens ran his own audit on his own repo: 178 test files, 44% solid, 30% needing rework, and 26% deleted outright.
The Eight Agents and What Each One Does
Each agent is named after a character from The A-Team. The planning loop runs first:
- Face decomposes the PRD into work items in a first pass.
- Sosa reviews that breakdown before a single line of code exists, challenges it, and asks the human clarifying questions. Face takes a second pass applying Sosa’s feedback. Items only move to
readyafter Sosa has argued with the plan.
Once an item is ready, execution runs in this order:
- Murdock writes the tests first, defining what “done” means before anyone builds toward it.
- B.A. writes the code to pass those tests. If the test itself is broken (not just failing), B.A. can self-reject the item straight back to Murdock without a human or orchestrator in the loop.
- Lynch reviews the tests and the code implementation together, because a passing test and a correct test are not the same thing.
- Amy runs what the plugin calls the Raptor Protocol: systematic probing for weaknesses beyond what the tests cover, starting with wiring and browser verification. The project’s own operating rules mark this step mandatory, not optional.
- Stockwell runs a Final Mission Review after all work items reach done: one pass scoped to the whole PRD and the whole diff, looking for what per-item review misses when it’s only examining one item at a time. Stockwell was added in commit 18, two months after launch.
- Hannibal is the orchestrator, coordinating the flow between agents.
The Rework Cap: Why Every Rival Needs a Limit
A rejection loop without a limit never converges. Owens built caps at two levels.
Per item: Rejections from Lynch, Amy, or B.A.’s self-reject all increment the same counter. The default is 4 rejections across all stages before an item moves to blocked for a human to resolve. That number is configurable. Owens notes that one line in his own operating doc still reads 2, left over from before the default changed and the docs were never updated.
Per mission: Stockwell gets a tighter budget: 2 rejection cycles before escalating to a human instead of attempting a third pass. When Stockwell rejects, he doesn’t flag the whole branch. He names the specific items that need another pass, and Hannibal sends only those back to ready.
The Gate That Approved and Still Missed Three Bugs
One mission in the plugin’s own history, M-20260702-001, is worth sitting with. Stockwell approved the work. Final gate, whole PRD, whole diff, signed off. A manual post-mission review still found three real bugs.
A gate approving something is not proof it’s correct. That’s exactly why the caps and human escalation exist rather than trusting any single pass all the way down. That mission later motivated a dedicated sweep command: a post-mission review and autofix step for catching what the last rival pass missed.
The Pattern Beyond Code
The A(i)-Team plugin is scoped to code. The structure underneath it isn’t. Owens is running a newer, more general version of the same pattern on non-code work. He operates a 3D print farm and a Shopify store, and uses the same maker/rival/bounded-rework loop to speed up product listings: a raw photo and an edited photo come in as reference, the system generates a few versions, and an LLM judge picks the best one.
Same loop shape. Different output domain. The quality gate transfers wherever you can define intent for the output.
The Verdict
If your AI coding workflow is a single agent writing and shipping, you’re skipping the verification layer that human engineering teams figured out decades ago. The A(i)-Team plugin makes that layer explicit, bounded, and configurable. The four-rejection-per-item cap is the part most solo operators would overlook and regret. It’s what keeps a quality loop from becoming an infinite loop.
The plugin is public on GitHub.
I’m founder of BizStack at Cagri Sarigoz LLC and a passionate advocate for entrepreneurs.
With over 14 years in tech, marketing, and AI, including my role as Head of SEO at CitizenShipper and co-founder of TaleBot at Intale AI, I’m dedicated to sharing genuine, useful product insights and tips.
At BizStack, I aim to cut through the digital noise to provide clear, actionable advice.
And more than all else, I’m a father to a (always) little girl and a husband.
Contact me at [email protected] for assistance.
