BrassCoders + Cursor: Triage AI-Generated Code Findings in Minutes
Run brasscoders scan, open .brass/ai_instructions.yaml in Cursor, ask Cursor to triage. The workflow for reviewing AI-generated code without reading 1500 raw findings yourself.
Cursor generates code fast. Reviewing it is the bottleneck — not because you’re slow, but because the raw output of 12 static-analysis scanners on a real codebase lands somewhere between 300 and 2,000 findings, and nobody reviews 2,000 findings. BrassCoders solves this by producing a single YAML file structured for AI assistant consumption. Open it in Cursor. Ask Cursor to triage. Done in minutes.
Why Cursor Needs a Deterministic Layer First
BrassCoders ran its AI-coder-bug benchmark in June 2026 against 12 AI-generated Python files and caught 11 of 12 planted bugs — matching a frontier model on every category where deterministic rules apply, and catching four performance anti-patterns that Bandit and Pylint scored zero on.
Cursor is an LLM. It’s fast, it reasons well, and it will hallucinate package names, miss cross-file dataflow bugs, and occasionally miss the list.insert(0) anti-pattern that degrades silently under load. What it won’t do is check every file, every commit, automatically, with no prompt required. BrassCoders runs 12 deterministic scanners — Bandit, Pylint, Pyre/Pysa, Semgrep, ast-grep, detect-secrets, and six custom detectors for secrets, privacy/PII, AI-pattern hallucinations, performance, content moderation, and JavaScript/TypeScript — before Cursor sees any finding. The pattern scan is dumb and honest. That’s the point.
The division of labor matters. BrassCoders finds the structural markers: the SQL query built with string concatenation, the high-entropy string that looks like a private key, the while True loop with no exit condition. Cursor reads those findings, applies context, and decides what to fix. The benchmark numbers at coppersun.dev/blog/we-benchmarked-brasscoders-against-a-frontier-model/ show what each layer catches — and where each layer fails. Read them before deciding how much to trust either tool alone.
The Two-Step Workflow
BrassCoders writes everything to .brass/ai_instructions.yaml — one file, one command, structured for AI consumption.
Step 1: run brasscoders scan . in your terminal. On a typical Python project this takes 20-40 seconds. You’ll see each scanner check in as it finishes. When the scan completes, .brass/ai_instructions.yaml exists at the project root.
Step 2: open .brass/ai_instructions.yaml in Cursor. Then ask:
“Read this file and triage the findings. Tell me which to fix first, which are false positives, and write the fix for the top three Critical items.”
Cursor reads the structured YAML, applies context from the rest of your codebase, and returns ranked, fix-ready output. The whole loop — scan, open, triage — takes under five minutes on most projects.
Here’s what the YAML structure looks like at the top level:
how_to_read_this_file:
purpose: "AI-consumable scan output for triage and fix generation"
severity_scale: [CRITICAL, HIGH, MEDIUM, LOW, INFO]
confidence_note: "High confidence = deterministic rule match. Medium = heuristic."
findings:
- id: "B001-001"
scanner: "bandit"
severity: CRITICAL
confidence: HIGH
file_path: "app/auth/login.py"
line_number: 47
title: "SQL query built with string formatting"
description: "f-string used to construct a SQL query. Parameterized queries prevent injection."
The how_to_read_this_file block at the top instructs the AI assistant on severity scale, confidence levels, and scanner provenance. Cursor reads that block first. By the time it gets to the findings list, it knows a HIGH confidence Bandit finding is a deterministic rule match — not a guess.
What the ai_instructions.yaml File Contains
BrassCoders emits findings ranked by severity and confidence, with enough per-finding context that an AI assistant can make a fix decision without reading the source file line by line.
Each finding carries: the originating scanner (Bandit, Pylint, Pyre/Pysa, Semgrep, detect-secrets, or one of the six custom detectors), severity (CRITICAL through INFO), confidence (HIGH for deterministic matches, MEDIUM for heuristic), file path, line number, a human-readable title, and a description of what the pattern means. The description is written for the AI consumer, not the human reviewer — it names the risk category, not just the pattern.
The YAML is not intended for human review. It’s long, it’s repetitive by design (every finding is self-contained), and the how_to_read_this_file section reads like instructions to an LLM because it is. Cursor uses the structured context to produce fix-ready advice with line-level specificity. Trying to read it top-to-bottom yourself defeats the purpose. Open it in Cursor and let Cursor read it.
The OSS core emits all findings without enrichment. BrassCoders Paid ($12/dev/month) adds a semantic deduplication pass that collapses near-duplicate findings, clusters related issues, and ranks survivors against a project signature derived from your README and manifest. A scan that emits 1,500 raw findings typically reduces to ~300 after the Paid enrichment pass — based on published case studies at coppersun.dev/benchmarks/ against Django, FastAPI, NodeGoat, and PyGoat at pinned commits. You can reproduce those numbers.
Pre-Commit vs. Cursor Review
BrassCoders catches the structural bugs before an LLM ever touches your code — run it before you open the diff in Cursor for review.
The workflow that catches the most bugs: run brasscoders scan . before you open a Cursor review session. Any Critical or High finding in .brass/ai_instructions.yaml is something BrassCoders caught deterministically, with no hallucination risk. Fix those first. Then open the diff in Cursor and ask for a higher-level code review — at that point Cursor is reviewing logic, not chasing SQL injection markers it might or might not catch depending on context-window state.
For CI, the same principle applies. Add brasscoders scan . as a pipeline gate that runs before the PR is mergeable. The GitHub Actions integration guide at coppersun.dev/blog/add-brasscoders-to-github-actions/ covers the exact step configuration — including how to set a severity threshold so the build fails on Critical findings and passes on Medium. When Cursor AI review happens after that gate, it’s reviewing code that has already passed deterministic scanning.
The pattern is: deterministic first, reasoning second. BrassCoders runs everywhere, automatically, with no prompt. Cursor reasons with full context when you ask it to. Neither tool replaces the other.
Install BrassCoders — pip install brasscoders, then brasscoders scan . — and open .brass/ai_instructions.yaml in Cursor today. The install guide at coppersun.dev/install/ covers setup, activation, and the first-scan walkthrough in under ten minutes.
Frequently Asked Questions
What file does Cursor read from a BrassCoders scan?
BrassCoders writes all scan output to .brass/ai_instructions.yaml at the project root. Open that file in Cursor and ask it to triage the findings — the YAML is structured specifically for AI assistant consumption, with a how_to_read_this_file section at the top that instructs the AI on how to interpret severity, confidence, and scanner source.
How long does a BrassCoders scan take?
A typical Python project scans in 20-40 seconds. The 12 scanners run in parallel where possible. The output is a single .brass/ai_instructions.yaml file you can open immediately in Cursor.
Does BrassCoders send my source code anywhere?
The OSS core makes zero outbound network calls. If you activate BrassCoders Paid, the enrichment step sends scanner findings (already redacted) plus a short project signature — at most 7,500 characters from your README, manifest, and entrypoint filenames. Raw source code never leaves the machine.
Do I need a BrassCoders account to use it with Cursor?
No. The OSS core is Apache 2.0 licensed — pip install brasscoders, run brasscoders scan ., open the output in Cursor. No account, no signup, no API key. The Paid plan ($12/dev/month) adds AI-powered semantic dedup and ranking, but the core Cursor workflow works without it.
Where does BrassCoders fit relative to Cursor's own AI review?
BrassCoders runs first, deterministically, on your local machine — 12 static-analysis scanners, no hallucinations, no context-window limits. It produces a ranked YAML file. Cursor then reads that file and applies reasoning: source-verifying findings, dismissing false positives, and writing fix-ready code. Cursor is the smart triage layer; BrassCoders is the honest pattern reporter.
Can I run BrassCoders in CI before Cursor review?
Yes. Add brasscoders scan . as a CI step and fail the pipeline on Critical findings. The GitHub Actions guide at coppersun.dev/blog/add-brasscoders-to-github-actions/ covers the exact workflow — including how to cache .brass/ across runs.