My AI Coding Pipeline Has a Team of Rivals. It Rejects Code on Purpose.

Lincoln didn’t build a cabinet of people who agreed with him. He put his three biggest rivals for the 1860 nomination in the room: Seward at State, Chase at Treasury, Bates as Attorney General. People who wanted his job got the job of checking his decisions instead.

I built quality gates out of agents that want to reject my code.

The quality gates are part of a Claude Code plugin I’ve been building since January. Half the agents in it exist for one reason: to find something wrong with what the other half built.

Most of the industry is optimizing for how long an agent can run unattended. This pipeline optimizes for the opposite: how much work I can prove is right.

The SDLC Already Knew This

Software already solved “how do you keep quality high when work moves fast.” We just don’t usually call it that. We call it definition of ready, definition of done, a maker (dev) / verifier (QA) team structure. Product managers write PRDs, developers break the PRD into stories, stories get worked, then handed to a different developer for code review, then it lands with an SDET or QA engineer before it ships. Unit and integration tests exist to protect the intent behind the code after it’s written. Intent is the thread I kept pulling on when I started writing the A(i)-Team plugin for Claude Code.

I made most of this case back in a February post, for the planning half of the loop. Every ceremony is structured context transfer: a PRD is what and why, a story is scoped execution, standing docs are how we work here. This post is the other half of the process. Checking the work, not just planning it.

And checking matters more than people assume right now. CodeRabbit ran the numbers across 470 real GitHub pull requests: 320 AI co-authored, 150 human-only, scored against their own issue taxonomy. AI-generated PRs came back with roughly 1.7x more issues overall — 10.83 issues per PR against 6.45 for human-only — and 75% more logic errors specifically¹. That’s not my data, it’s CodeRabbit’s, but it matches exactly what I found when I ran my own audit on my own repo: 178 test files, and 44% of them were solid. The rest split between rework (30%) and outright deletion (26%). I wrote about that one in March, and the punchline still holds: the agent that writes the code is never the last agent to look at it.

The Idea

Here’s what that principle looks like as an actual pipeline. The A(i)-Team plugin is public — I started it January 15, 2026. Eight named agents (I named them after the A-team 😆), each with one job, and half of them are only there to say no.

Planning starts with a loop, not a straight line: Face decomposes the PRD into work items in a first pass. Sosa reviews that breakdown before a single line of code exists, challenging it and asking the human clarifying questions. Face takes a second pass applying Sosa’s calls, and only then do items move to ready. Nobody codes against a plan that hasn’t been argued with first.

Once an item is ready, the execution order is: Murdock writes the tests first, defining what “done” means before anyone builds toward it. B.A. writes the code to pass those tests. Lynch reviews the tests and the code implementation together, because a passing test and a correct test aren’t the same thing. Amy then runs what the plugin calls the Raptor Protocol, systematically probing for weaknesses beyond what the tests cover, starting with wiring and browser verification — marked mandatory, not optional, right in the project’s own operating rules. I’ve been calling it, half-joking, the raptor fence testing protocol. My joke name got baked into the plugin. Clever girl 🦖

B.A. has one more move I like: if the test itself is broken, not just failing, B.A. can self-reject the item straight back to Murdock, no human or orchestrator needed in the loop, mirroring how Lynch rejects back to testing. The plugin’s own docs call it the rare path. It still counts against the same rejection budget as everything else, so it’s not a way to dodge the counter.

After all the work items reach done, Stockwell runs a Final Mission Review: one more pass, scoped to the whole PRD and the whole diff, looking for what per-item review misses when it’s only looking at one item at a time. Stockwell didn’t ship on day one. He landed two months later, commit #18, the same day I published the write-up on the testing pipeline, which is exactly why that post doesn’t mention him.

Right-Sizing the Work Units

A lot of people are chasing long-horizon autonomy with agentic LLMs right now — agents that run unattended for hours. I’d argue that’s the wrong unit to optimize. What you actually want is the right sized chunk of work that a team of subagents can consume and check, an output you can prove is what you asked for and that it actually works. That’s what I mean by a quality loop: work goes through a gate, gets bounded rework if it fails, repeats at every stage from planning through ship.

The gate itself is a rival pass: one agent whose only job is trying to reject what’s in front of it. Sosa is a rival pass on the plan. Lynch and Amy are rival passes on the implementation, at different depths. Stockwell is a rival pass on the whole mission. None of them are graded on being agreeable.

And every rival pass needs a limit, or it never converges. That’s the rework cap, and the plugin runs it at two different altitudes with the same shape. Per item, a rejection from Lynch, Amy, or B.A.’s self-reject all increment the same counter, and it defaults to 4 across every stage before the item goes to blocked for a human, configurable if 4 is wrong for your team. I’ll admit I had to go check the actual code to confirm that number, because one line in my own operating doc still says 2, written before the default changed and docs never updated. Even the guy who built the cap didn’t remember the cap. Per mission, Stockwell gets a smaller budget: reject up to 2 cycles before escalating to a human instead of trying a third time. And when Stockwell rejects, he doesn’t nuke the whole branch, he names the specific items that need another pass, and the orchestrator, Hannibal in this case, sends only those back to ready.

The Gate That Approved and Still Missed Three Bugs

Here’s the part that keeps me honest about all of this. There’s a mission in the plugin’s own history, M-20260702-001, where Stockwell approved the work. Final gate, whole PRD, whole diff, signed off. A manual post-mission review still found three real bugs in it.

A gate approving something is not proof it’s correct, which is exactly why the caps and the escalation to a human exist instead of trusting any single pass all the way down. That mission is what motivated the plugin’s later sweep command, a dedicated post-mission review and autofix step, because catching what the last rival pass missed needs its own pass too. Sweep deserves its own post — that one’s about prompt quality, and how you test prompts for the outcomes you actually want.

Past One Plugin

The A(i)-Team plugin is scoped to code. The shape underneath it isn’t. A gate that can reject and force bounded rework, with the agent doing the work kept separate from the agent checking it, works on any output you can define intent for. I’m already running a newer, more general version of the same pattern on non-code work. I run a 3D print farm and a Shopify store, and we post new products a lot, so I wanted to speed up the listing process. We broke it down into deterministic and agentic steps: it takes a raw photo and an edited photo from my editor as the reference, generates a few versions, and an LLM judge picks the best one. The maker, the rival, some bounded rework making the same loop but giving us different outputs.

If you want quality loops like these wrapped around your own team’s AI work, that’s what I do at TheAITeam — and each new loop gets a writeup here as it ships.

Lincoln’s cabinet didn’t agree with him because agreement wasn’t the job. It isn’t the job for Sosa, Lynch, Amy, or Stockwell either. Their job is to find what’s wrong before it ships. Mine is to keep building rooms for that argument to happen in.

Footnotes

1. CodeRabbit, “State of AI vs. Human Code Generation” report, https://www.coderabbit.ai/blog/state-of-ai-vs-human-code-generation-report ↩