A customer reports that checkout occasionally creates two orders. Your local tests pass. The coding agent reads the payment handler and immediately proposes a fix. Stop there: you have a symptom, not a diagnosis. The useful pairing pattern is to make uncertainty explicit, gather discriminating evidence, and let the agent help build a reproducible failure before changing behavior.
1. Turn the bug report into an evidence ledger
Give the agent the original report, relevant code, and sanitized logs. Ask it to separate observed facts, missing information, and hypotheses. For example: two order identifiers exist for one checkout session; the customer remembers clicking once; the request count is unknown. A remembered click count is not proof that only one request reached the server.
Set boundaries immediately: inspect and propose, but do not edit production behavior, access credentials, or run commands against live systems. Remove payment details and personal information before sharing artifacts.
2. Ask for competing explanations, not a confident patch
Use this prompt: List three plausible causes. For each, identify supporting evidence, contradicting evidence, and the cheapest safe experiment that would distinguish it. Require file and function references for claims about the code.
- A browser retry submits the same checkout twice.
- A webhook replay creates a second order.
- Concurrent requests both pass an application-level duplicate check.
Have the agent rank experiments by diagnostic value, not just rank causes by plausibility. Reading retry configuration may eliminate one branch without changing code.
3. Reconstruct the conditions around the missing failure
Ask the agent to compare the failing environment with your test environment: application revision, feature flags, database constraints, worker count, queue delivery behavior, and relevant configuration. Capture these details in the issue rather than leaving them in chat.
Build a minimal timeline using request identifiers, checkout session identifiers, webhook event identifiers, and order creation timestamps. Record timestamp precision and clock differences where relevant. If the evidence cannot establish event order, mark the sequence as unknown instead of letting the agent invent one.
4. Add instrumentation that separates the hypotheses
Ask for a small, reviewable instrumentation patch. For this checkout example, log the entry point, correlation identifier, a safe representation of the idempotency key, and whether order creation succeeded or hit an existing record. Do not log request bodies or payment credentials.
Define what each result would mean before collecting it. Two browser requests suggest a different path from one browser request followed by repeated webhook processing. Keep verbose logging scoped, access-controlled, and removable; assign an owner and removal condition.
5. Build a deterministic failure with the agent
Once evidence supports a concurrency hypothesis, ask the agent to construct a controlled test. Coordinate two checkout attempts so both reach the duplicate check before either proceeds. Use synchronization hooks in the test harness rather than hoping a sleep creates the right timing.
Review what the test actually proves. Mocking away the database cannot demonstrate how its real uniqueness constraints behave. Use an isolated test database when the suspected failure depends on transactions or constraints. Run the test against the unchanged implementation and confirm that it fails for the reported reason.
6. Review the smallest fix and its failure paths
Now request a patch tied explicitly to the failing test. If the cause is a check-then-create race, review whether uniqueness must be enforced atomically at the database boundary. Have the agent explain transaction behavior, conflict handling, and what repeated requests return.
Check adjacent cases: a legitimate second purchase, a retry after a partial failure, and a duplicate webhook. Keep unrelated refactoring out of the patch so reviewers can connect each change to evidence.
7. Preserve the investigation and verify the release
Run the regression test and relevant existing tests, then review the diff yourself. Document the reproduction conditions, rejected hypotheses, remaining uncertainty, and rollback trigger. After release, inspect the targeted signals; a passing local test does not establish that the customer’s issue is resolved.
For future pairing sessions, SwiftRelay provides pay-as-you-go access through tools such as Claude Code, Codex, and Gemini CLI. Sign up for SwiftRelay if that setup fits your workflow. Keep the evidence ledger and tests in your repository so the investigation remains portable across agents and models.