Audit AI-generated pull requests for what the code forgot to handle.

Clean-looking code can still fail under real data, concurrency, retries, partial outages or scale. This workflow forces review toward omitted failure paths rather than style.

Time 30–60+ minSkill AdvancedTools 2–4Human verification Required

Operational workflowHuman verification required

The real problem

AI coding assistants are good at producing plausible implementations quickly. The harder review problem is negative space: transaction boundaries that were never considered, silent fallbacks, N+1 access patterns, unbounded collections, retry storms, partial writes, connection-pool pressure and race conditions that may not appear in small local tests.

Best tool fit

CursorUseful when the reviewer needs repository context, diff inspection and targeted code changes.Claude CodeUseful for repo-wide reasoning, tracing call paths and proposing verification steps.GitHub CopilotUseful inside GitHub/IDE workflows for PR-level review and implementation follow-up.ChatGPTUseful for independent review when you provide the diff, logs, schema and performance evidence.

Workflow

01Supply the evidence

PR diff, affected code paths, schema, expected load, transaction rules, relevant logs and existing tests.

02Review negative space

Ask specifically what failure paths, limits, retries, concurrent states and cleanup behavior are missing.

03Attach runtime evidence

Where available, include query plans, APM traces, flamegraphs, connection-pool metrics or realistic dataset sizes.

04Generate adversarial tests

Test exact boundaries, duplicate/retried requests, partial failures, concurrent updates and large data distributions.

05Verify the smallest fix

Prefer a targeted change that addresses a reproduced failure over broad AI-generated refactoring.

Guardrail prompt

Act as a Negative Space Auditor for this pull request. INPUTS - PR diff: [PASTE] - Relevant code paths: [PASTE] - Data model / schema: [PASTE] - Expected load / concurrency: [DESCRIBE] - Logs, traces, query plans or metrics: [PASTE] - Existing tests: [PASTE] YOUR JOB Do not review naming or formatting first. Look for behavior the implementation fails to model. Check explicitly for: 1. silent fallbacks that hide failure, 2. missing rollback / partial-write handling, 3. race conditions and non-atomic read-modify-write logic, 4. retry duplication / idempotency gaps, 5. N+1 queries or per-item network/database calls, 6. unbounded loops, filters, pagination or memory growth, 7. connection / thread / worker pool pressure, 8. timeout and cancellation behavior, 9. cache inconsistency, 10. exact-boundary and empty-state behavior. For every concern: - cite the exact code path, - describe the production condition required to trigger it, - separate confirmed defect from hypothesis, - propose the smallest test that could prove or disprove it, - do not invent runtime behavior that is not supported by the supplied evidence. Finish with: A. highest-risk confirmed issues, B. hypotheses that need runtime evidence, C. tests to run before merge, D. metrics to watch after deployment.

Evaluate your adapted prompt

Verification before merge

ConcurrencyRun simultaneous requests against shared records or stateful resources.

Rollback integrityForce failure midway and verify no partial state remains.

Query/load behaviorCompare request/query counts using production-like dataset sizes.

Fallback visibilityVerify errors are observable instead of silently converted into “success.”

Retry/idempotencyRepeat identical requests and verify no duplicate side effects.

Regression scopeRun targeted tests plus tests around adjacent behavior changed by the diff.