Have Another AI Rebut Your Design

AI design review is cheaper before any code exists. Ask a different model for the strongest rebuttal, check it against settled decisions, then revise.

Agent-written design docs read well, which makes their holes hard to see. In our test environment, before heavy design decisions, we ask a model from a different family to argue against the design. This covers that pre-implementation procedure and the failures behind it. For post-implementation code review and when to stop it, see When to Stop AI Code Review.

Why a different AI

Asked “what’s wrong with this design?” in the same conversation, a model tends to retrace its own reasoning. Claude Code’s best practices note that a fresh context improves code review because Claude won’t be biased toward code it just wrote (https://code.claude.com/docs/en/best-practices, checked 2026-10-16). We go further and use a different model family, which tends not to share the same blind spots.

The procedure

• The writer model drafts the design.
• A different-family model gives the single strongest technical rebuttal.
• The writer counters and produces a merged proposal.
• A human checks the proposal’s premises in the real environment.
• The other model reviews the implementation plan.
• The writer revises, tagging which finding was fixed where.

Ask for “the strongest rebuttal,” not “problems”: a list of problems buries the points that could overturn the design.

We run Codex CLI non-interactively. In our local codex-cli 0.163.0 (2026-10-16), codex exec --help shows -s, --sandbox with read-only and -o, --output-last-message to write the final reply to a file; the official reference lists the same options (https://developers.openai.com/codex/cli/reference, checked 2026-10-16). A rebuttal only needs to read:

codex exec -s read-only -o rebuttal.md - < ask_rebuttal.md

We show this for shape only and did not run it for this article (it would incur API usage). Treat web-search results in a rebuttal as unverified until checked in the real environment.

Pull settled decisions before designing

One first draft contradicted decisions already recorded in existing docs; the writer never read them. Multiple isolated reviewers rejected every claim, and the design had to be rewritten. More review doesn’t prevent this. Have the model pull settled decisions from the decision log first and list them at the top of the design as accepted premises; hand them to the rebutter too, so settled points aren’t reopened.

Count when it feels too complex

If a human reads the design and feels “too complex” or “bolted on,” treat it as a warning. Asking the agent to justify the structure yields justification. Count instead. An illustrative dummy design doc (not a measurement of a real design):

queue  2
lock   2
CAS    1
flag   2
retry  2
TTL    1

Five lines stack locking, retry and detection mechanisms. We once had an all-of-the-above design that went through review many times and turned out not to work in production. With the count in hand, ask: real improvement, or another extension?

Names fatten designs

Names that imply the caller has authority to rewrite data (“acquire,” “sync,” “update”) led the model to keep adding locks and retries to protect that authority. Names that signal a helper role (“hint,” “refresh”) didn’t. Ask the rebutter whether names imply more authority than the role.

After the rebuttal

Sort each point: accept (sound premise, real reason to change), verify first (premise may not hold in the real environment; a human checks it), or reject (reopens a settled decision or is out of scope). Record rejections with reasons in the design doc so the same rebuttal can be closed quickly next time.

Spec, then implement

The best practices suggest having Claude interview you for larger features, writing a spec, then starting a fresh session to implement; good specs name files and interfaces, state what’s out of scope, and end with an end-to-end verification step (same source). We attach the accepted and rejected rebuttals to that spec.

Prompt template

Give the single strongest technical rebuttal to this design.
- Settled decisions are listed below; do not reopen them.
- Skip minor issues; only points that could overturn the design.
- Cite sources for any external information.
- Check whether names imply more authority than the role.

Running several reviewers in parallel has its own failures: Subagent Failures in Parallel Runs.

Summary

• Have a model without the writing context, ideally another family, rebut the design.
• Ask for the strongest rebuttal; verify any external facts it cites.
• Pull settled decisions before designing; more review won’t catch that gap.
• When it feels too complex, count mechanisms instead of asking for justification.
• Authority-implying names fatten designs; name helpers as helpers.