In part four of his agentic setup series, developer Aviv L. revealed a strict protocol where every pull request undergoes an automated, read-only review by an AI agent before a human ever opens the diff. With approximately 50 PRs arriving weekly, L. refuses to review code cold, instead deploying a fleet of agents that operate in isolated panes. These agents are constrained by a binding charter that prohibits them from commenting, approving, pushing, or merging on GitHub, ensuring they function purely as internal intelligence reports written to the local machine.
The Cross-Vendor Mandate
The core architectural decision in this workflow is the requirement that the reviewing model must come from a different vendor than the model that wrote the code. Since L.'s primary coding agents run on Claude, the review gate is pinned to OpenAI's GPT-6.1 Sol at high effort. This cross-vendor check prevents the echo chamber of an AI reviewing its own output. The setup explicitly notes that the omp override for the reviewer role does not automatically apply to 'scout' subagents, requiring the fmreview script to manually inject the openai-codex/gpt-6.1-sol model flag into every dispatch message to guarantee compliance.
Read-Only Charter and Grid Layouts
The agent's authority is strictly limited by a 'read-only, without exception' charter. The scout can only read the PR diff, files, and checks using the gh CLI, and its sole deliverable is a local report.md file. To manage the volume of 50 PRs, L. uses a batch launcher called fmreview that integrates with herdr to create a grid of panes. The system handles the counter-intuitive herdr split ratio logic, where --ratio defines the share the original pane keeps, requiring a calculated 1/n ratio at each step to carve out equal review spaces for multiple PRs simultaneously.
Five-Pass Analysis and Spec Verification
Each agent performs five distinct review passes. Four passes analyze the code's correctness, edge cases, and error handling using tools like pr-review-toolkit. The fifth pass is a 'spec reviewer' that operates with reduced context, seeing only the diff and linked tickets to check for intent alignment. This pass categorizes findings into three buckets: 'asked but not built,' 'built but not asked for,' and 'built wrong.' This separation ensures that the agent validates whether the code actually does what the ticket requested, rather than just checking if the code is syntactically sound.
Review Budgets and Escalation Rules
To prevent infinite loops of AI-generated feedback, L. implemented a hard 'review budget' in late October. The default limit is three review rounds per PR, with the first round being a full audit and subsequent rounds checking only changed code and open findings. Extensions to five rounds are reserved for critical areas like security, permissions, and data loss. Every finding is tracked in a ledger with a specific outcomeβfixed, rejected with a reason, or openβensuring that no AI-generated nitpick disappears into the void without a human decision.
Key Takeaways
- Vendor Diversity: The reviewer model (GPT-6.1 Sol) is explicitly different from the author model (Claude Sonnet 5.5) to avoid self-confirmation bias.
- Read-Only Enforcement: Agents are prohibited from posting comments or merging PRs; they only write local reports for human review.
- Spec-First Logic: A dedicated pass checks code against the ticket intent, flagging 'built wrong' or 'asked but not built' scenarios.
- Hard Budgets: Review rounds are capped at 3 by default to prevent agent loops, with strict ledger tracking for every finding.
The Bottom Line
This isn't just automation; it's a firewall for code quality. By forcing a cross-vendor, read-only AI gate before human eyes ever hit the diff, L. has turned the PR review from a reactive chore into a proactive intelligence operation. Most teams let agents write code; this setup makes the agent the first line of defense, and it never gets a vote.