They leave "which issues count" undefined. Explicit categorical criteria do the work — e.g. "flag comments only when claimed behavior contradicts actual code behavior," not the vague "check that comments are accurate."

Define which issues to report (bugs, security) vs skip (minor style, local patterns) as categorical rules — not confidence-based filtering.

Define explicit severity criteria with a concrete code example for each level, so the model classifies the same way every run instead of guessing what "critical" means.

A high-FP category undermines developer trust in every category — even accurate ones. Temporarily disable it to restore trust while you improve its prompt, then re-enable.

Few-shot prompting — give 2–4 worked examples. It's the most effective technique when detailed instructions alone produce inconsistent, inconsistently-formatted output.

The reasoning for why one action was chosen over plausible alternatives — so it teaches judgment for ambiguous cases (tool selection, branch-level coverage gaps), not just an answer.

Include examples demonstrating the exact desired format — e.g. location · issue · severity · suggested fix — so output stays consistent.

Examples distinguishing acceptable code patterns from genuine issues cut false positives, while still letting the model generalize to novel patterns rather than matching only pre-specified cases.

Examples covering varied document structures (inline citations vs bibliographies, methodology vs embedded details) and varied formats address empty/null extraction of required fields and informal measurements.

Tool use with a JSON schema. Define an extraction tool whose input schema is the shape you want and read the data from the tool_use response — this eliminates JSON syntax errors.

• "auto" — model MAY call a tool or return text (no guarantee)
• "any" — MUST call a tool, model picks which (unknown doc type, multiple schemas)
• {"type":"tool","name":"extract_metadata"} — forces one specific tool

It eliminates syntax errors. It does not prevent semantic errors — line items that don't sum to the total, or a value in the wrong field.

Mark those schema fields optional / nullable. Required fields that may be absent force the model to invent values to satisfy them.

Add enum "unclear" for ambiguous cases and "other" + a detail string for extensible categories. Put format-normalization rules in the prompt alongside the strict schema.

The original document, the failed extraction, and the specific validation errors — appended to the prompt so the model self-corrects.

Succeeds: format mismatches and structural output errors. Ineffective: when the required information is simply absent from the source (e.g. it lives only in an external document you didn't provide).

Extract "calculated_total" alongside "stated_total" to flag discrepancies, and add a "conflict_detected" boolean for inconsistent source data.

It records which code construct triggered each finding. When developers dismiss findings, you analyze these patterns to find and fix false-positive sources. (Semantic errors ≠ syntax errors, which tool use already removes.)

• 50% cost savings
• up to a 24-hour processing window
• no guaranteed latency SLA
• no multi-turn tool calling within a single request

Batch: non-blocking, latency-tolerant work — overnight reports, weekly audits, nightly test generation. Sync: blocking workflows like pre-merge checks a developer waits on.

Calculate from the processing window: with 24-hour batch processing, submitting every 4 hours guarantees a 30-hour end-to-end SLA.

custom_id correlates request/response pairs and lets you resubmit only failed documents (e.g. chunk ones that exceeded context limits). First, refine the prompt on a sample set to maximize first-pass success.

The model that generated the code retains its reasoning context and won't question its own decisions. An independent instance (no generation context) catches subtle issues — more effectively than self-review instructions or extended thinking.

Split into focused passes: analyze each file individually for local issues, then run a separate integration pass for cross-file data flow. Avoids attention dilution and contradictory findings.

The model reports a confidence level alongside each finding, enabling calibrated review routing — auto-apply high-confidence findings, send low-confidence ones to a human.

• "Use a larger context window" — the problem is attention quality, not capacity
• "Require consensus across multiple full-PR passes" — suppresses intermittently-caught bugs
• "Make developers split the PR" — shifts the burden, doesn't fix the system