Concurrency Anti-Pattern Detection Prompt

This prompt is designed for platform engineers, tech leads, and code reviewers who need to systematically identify known concurrency anti-patterns in submitted code before they reach production. The job-to-be-done is not a general code review but a targeted, pattern-based scan for specific, well-documented concurrency defects such as incorrect double-checked locking, unbounded thread-per-request creation, busy-wait loops, and unsynchronized lazy initialization. The ideal user is someone who understands the concurrency primitives of the target language but wants a consistent, automated second pair of eyes that won't overlook subtle, repeatable mistakes buried in a large diff.

To use this prompt effectively, you must provide the full source code of the change or module under review as [INPUT], along with the programming language in [LANGUAGE] so the model can apply language-specific pattern recognition. The prompt works best when the code is self-contained and the anti-patterns are structural—meaning they can be identified from the code's shape and synchronization usage without requiring a running trace. Do not use this prompt for performance tuning, lock contention profiling, or for finding novel, zero-day concurrency bugs that require deep domain knowledge of a proprietary system. It is a pattern detector, not a formal verifier or a substitute for dynamic race detectors like ThreadSanitizer. If the code change is a complex, multi-service workflow where concurrency risk is distributed across network boundaries, this prompt will miss those cross-system interactions.

The output is a structured report of findings, each mapped to a specific anti-pattern name, code location, a human-readable explanation of the flaw, and concrete refactoring guidance. This makes the prompt directly embeddable into a CI/CD pipeline as a quality gate, where findings can be posted as automated review comments. However, you must pair this prompt with a validation step: false positives are possible, especially when the model misinterprets intentional, low-level synchronization for an anti-pattern. Always require a human reviewer to confirm or dismiss each finding before blocking a merge. For high-risk code paths handling financial transactions or safety-critical state, escalate findings to a mandatory senior engineer review rather than relying solely on the prompt's severity classification.

This prompt template is designed to be dropped into a code review pipeline or used manually by a platform engineer. It instructs the model to act as a concurrency reviewer, scanning the provided code for a specific set of high-risk anti-patterns. The template uses square-bracket placeholders for the code under review, the programming language, any additional constraints, and the desired output schema. This separation ensures the prompt can be reused across different repositories and languages without modification.

textCopy
You are a senior systems engineer specializing in concurrent and parallel programming. Your task is to review the provided [LANGUAGE] code for known concurrency anti-patterns.

Review the following code:
```[LANGUAGE]
[CODE_DIFF_OR_SNIPPET]

Specifically, you must detect and report on these anti-patterns:

1. Double-Checked Locking Bugs: Incorrect implementations of the double-checked locking pattern, including missing volatile keywords, incorrect null checks, or partially constructed objects.
2. Busy-Wait Loops: Loops that repeatedly check a condition without yielding, sleeping, or using proper signaling mechanisms, leading to CPU starvation.
3. Unbounded Thread/Goroutine Creation: Patterns like "thread-per-request" or "goroutine-per-task" without bounds, connection pooling, or worker pools, which risk resource exhaustion.
4. Incorrect Double-Checked Locking: Any variant where the synchronization logic is flawed, even if it doesn't match the classic pattern exactly.

For each detected anti-pattern, provide a structured finding with the following fields:

• anti_pattern_name: The name of the anti-pattern.
• location: The specific file path and line range (e.g., src/handler.go:45-52).
• explanation: A clear, concise explanation of why this code matches the anti-pattern and the concurrency risk it introduces.
• severity: One of CRITICAL, HIGH, MEDIUM, or LOW.
• refactoring_guidance: A specific, actionable suggestion for fixing the issue, including a brief code sketch if helpful.

[CONSTRAINTS]

• Only report on the four anti-patterns listed above. Do not flag general code style issues or other concurrency concerns.
• If no anti-patterns are found, return an empty list.
• Base your analysis strictly on the provided code. Do not speculate about external systems.

Return your findings as a JSON object matching this exact schema: { "findings": [ { "anti_pattern_name": "string", "location": "string", "explanation": "string", "severity": "CRITICAL|HIGH|MEDIUM|LOW", "refactoring_guidance": "string" } ] }

To adapt this template, replace the placeholders with your specific context. [LANGUAGE] should be set to the programming language of the code under review (e.g., Java, Go, Python). [CODE_DIFF_OR_SNIPPET] is the actual code, which could be a unified diff from a pull request or a standalone code block. The [CONSTRAINTS] section is a powerful extension point: you can add rules like "ignore test files," "focus only on files changed in the last commit," or "do not report issues already present in the main branch." For high-risk production systems, always route findings with CRITICAL or HIGH severity for mandatory human review before merging.

This prompt is designed to be called programmatically as part of a pre-merge or post-commit review pipeline. The primary integration point is a CI/CD system (GitHub Actions, GitLab CI, Jenkins) that triggers on pull request creation or new commits. The application layer is responsible for extracting the code diff, assembling the prompt with the correct [CODE_DIFF], [LANGUAGE], and [ANTI_PATTERN_CATALOG] placeholders, and handling the model response. Because concurrency anti-patterns can indicate data corruption risks, the implementation must treat model output as a suggestion that requires deterministic validation before blocking a merge.

The implementation harness should follow a strict sequence: Input Assembly → Model Call → Schema Validation → Deduplication → Severity Routing → Human Review Gate. For input assembly, extract the unified diff from the PR and truncate it to fit the model's context window, prioritizing files in concurrent execution paths (e.g., files importing threading, asyncio, java.util.concurrent, or sync packages). The [ANTI_PATTERN_CATALOG] should be a curated JSON array of known patterns with names, descriptions, and regex or AST signatures where available. After the model returns JSON, validate it against a strict schema that requires anti_pattern_name, file_path, line_range, explanation, and severity fields. Reject any finding where the file_path does not exist in the diff or the line_range falls outside the changed lines—this catches hallucinated locations. Deduplicate findings that reference the same code location and anti-pattern, keeping the highest severity instance. For each validated finding, route based on severity: critical and high findings should create blocking review comments on the PR; medium findings should create non-blocking suggestions; low findings should be logged to a review dashboard without blocking the merge. All findings must include the raw model output and validation result in structured logs for auditability.

Model choice and retries: Use a model with strong code reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set temperature=0 for deterministic output. Implement a retry loop with up to 2 retries if the response fails schema validation or returns empty results for a diff that contains concurrency primitives. On the second retry, append the validation error message to the prompt as additional context. If retries are exhausted, log the failure and surface a manual review request in the PR rather than silently passing. Tool use and RAG: For teams with a known anti-pattern database, pre-filter the [ANTI_PATTERN_CATALOG] to only include patterns relevant to the detected language before sending the prompt—this reduces token usage and improves precision. Do not use RAG for the code diff itself; the diff must be provided inline to avoid retrieval latency and staleness. Human review: Critical findings must require a human reviewer to acknowledge or dismiss before the PR can merge. Implement this as a required status check that only passes when a reviewer with code ownership permissions resolves the finding in the review tool.

What to avoid: Do not use this prompt as the sole gate for merge decisions without deterministic post-processing. The model may misidentify safe patterns (e.g., a correctly implemented double-checked locking pattern flagged as broken) or miss anti-patterns that require deeper inter-procedural analysis. Never send entire repository codebases in the prompt—limit input to the diff plus minimal surrounding context (e.g., 50 lines of unchanged code around each changed block). Avoid running this prompt on every commit to a feature branch; instead, trigger it on PR creation and on pushes to PRs that modify concurrency-sensitive files. Finally, do not log the raw code diff to observability systems that lack access controls—code is sensitive intellectual property and must be treated accordingly in prompt logs.