Build a critic agent that challenges code-review plans before implementation using structured prompts, tests, and guardrails. Full breakdown.
What a rubber-duck critic agent does
A rubber-duck critic agent is a structured review step that sits before you write code. Instead of explaining a plan to a silent rubber duck, you hand the plan to an agent whose job is to challenge it: find missing edge cases, weak test ideas, risky assumptions, and scope that does not match the change you intend to make. The goal is not to generate patches. The goal is to force the plan through adversarial questions so implementation starts from a clearer, safer design.
This fits code-review workflows because review quality depends on what you decide early. If the plan is thin, reviewers later argue about intent, not just diffs. A critic agent compresses that friction into a deliberate pre-implementation pass you can run yourself or as a team checklist step.
Structured prompts that force useful challenge
Free-form “review this plan” prompts tend to produce polite summaries. A critic agent needs a fixed prompt shape so it always attacks the same weak spots. Give it the problem statement, the proposed approach, the files or interfaces you expect to touch, and the acceptance criteria. Then require answers in sections such as: assumptions that could be wrong, failure modes, missing tests, simpler alternatives, and what should stay out of scope.
Require the agent to rank concerns by impact and to mark each one as must-fix before coding, nice-to-have, or overreach. That ranking keeps the critique useful instead of turning every nit into a blocker. Keep the output short enough that a human can act on it in one pass—enough detail to decide, not an essay that replaces thinking.
Tests and guardrails around the critic
Treat the critic like any other component in the workflow: constrain what it can claim and how its output is used. Guardrails should block the agent from inventing requirements that are not in the plan, from approving work it has not actually challenged, and from expanding scope without calling that expansion out. Prefer templates and checklists over open-ended judgment so the same plan type always gets the same scrutiny.
- Feed only the plan, acceptance criteria, and relevant context—not the full repo unless needed.
- Require every high-severity concern to name a concrete test or check that would catch the failure.
- Refuse to start implementation until must-fix items are resolved or explicitly deferred with a reason.
- Log the critic output next to the plan so later code review can compare intent to the diff.
When you have automated tests for the workflow itself, assert that the critic response includes the required sections and that unresolved must-fix items block the next stage. That turns “we usually ask hard questions” into a gate the process can enforce.
How to fold it into everyday review flow
Run the critic after the plan is written and before the first commit. Use its must-fix list to revise the plan, then re-run once if the design changed substantially. During human review, point reviewers at the critic transcript so they can skip restated concerns and focus on residual risk in the actual code.
Keep the loop tight: plan, critique, revise, implement, then normal PR review. The agent is a pre-filter for weak plans, not a substitute for judgment. When the critique and the final diff disagree, treat that as a signal—either the implementation drifted or the plan was incomplete—and fix the process for the next change rather than ignoring the gap.