One assistant helps you reproduce a bug and proposes a fix. You want a second assistant to review it before you merge. If you paste the debugging transcript, the reviewer receives the first model’s theory, confidence, and framing before it sees the evidence. It may spend the review defending or polishing that theory instead of looking for a different defect.
Use the first assistant to reduce the failure. Give the second assistant a neutral packet.
Make debugging produce evidence
The debugging phase should end with a reproducible state, not merely a plausible explanation. Capture:
- Repository, branch, and exact commit under test.
- Environment and versions that affect the result.
- Minimal reproduction steps.
- Exact command and exact error or unexpected output.
- Expected behavior and why you expect it.
- Relevant logs, traces, or test output with sensitive data removed.
- Files changed by the proposed fix.
- Checks already run and their results.
Record uncertainty honestly. “The failure occurs when the lease expires” can be observed. “Two workers race because this token is missing” may still be a hypothesis. Keep those categories apart so the reviewer knows what it is allowed to disprove.
Ask for defects in the proposed fix
The second assistant needs a bounded review job. Give it separate authorized access to the patch or named files and ask for concrete problems:
- Does the change address the reproduced cause?
- Which edge cases still fail?
- Does it weaken an existing security or concurrency property?
- Are the tests capable of passing for the wrong reason?
- What evidence would disconfirm the proposed explanation?
Ask for findings ordered by severity, with a path and reason for each. “What do you think?” invites a general impression. A review request should ask for defects, not reassurance.
Protect the reviewer from the first explanation
A different model is not automatically an independent reviewer: models can share priors and blind spots. What the reviewer sees controls one important source of anchoring, and preloading the complete reasoning that produced the fix makes the review less independent still.
Start with the artifact, requirements, reproduction, and evidence. Withhold the first assistant’s narrative for the first pass. If the reviewer reaches a different explanation, compare both against the same observations. If it needs the original rationale to evaluate a deliberate tradeoff, provide that rationale afterward and label it as the first model’s claim.
Do not hide human decisions. Constraints, non-goals, and accepted risks belong in the initial packet because otherwise the reviewer may report intentional behavior as a defect. The distinction is between relevant requirements and persuasive reasoning.
Send the neutral packet as a self-handoff
Have the debugging assistant draft the neutral packet to your own email on the account both assistants use. Review the reproduction, sanitization, and review ask, then explicitly confirm. No second account or contact request is involved, and RelayLink creates no email or magic link. The packet stays unread until any assistant pulls it; the account portal is the fallback inbox.
The package carries the approved structured text, not either assistant’s hidden context, repository, live terminal state, or full chat. A path, commit, or patch reference grants no access; give the reviewer separate authorized access to the exact repository state. A code-context handoff explains the coordinates the second assistant needs.
Keep API keys, webhook secrets, customer data, and confidential source out of the package unless the provider and receiving environment are authorized. Prefer paths, commit identifiers, test names, and sanitized evidence.
Let the human decide what survives
The reviewer may find a defect. It may also misread the architecture, repeat the first model’s assumption, or invent a concern unsupported by the code. A second answer is another input, not a verdict.
Run the reproduction before and after the change. Run the broader tests named by the repository. Inspect whether the added test fails without the fix and passes with it. Then decide which findings require changes.
This split is useful because debugging and review ask different questions: “What explains this failure?” and “What is wrong with this proposed answer?” Keeping the handoff neutral gives the second question a real chance to produce a different result.