When you paste a diff into Claude.ai and ask for a review, you know what's happening: your source code is traveling to Anthropic's API. The same thing happens with automated LLM review tools — just without the paste.
This is not an argument against AI code review. It's a fact about what category of tool it is, and that fact has consequences for compliance, cost, and automation.
What the Payload Contains
BrassCoders's generation-mode benchmark used claude-sonnet-4-6 to review its own generated code. The API call for each review transmitted the full source file — typically 20–60 lines of Python in the benchmark, but in production use it's common to send entire files, diff context, and adjacent imports.
Most AI code review tools send one or more of:
- The raw source file or diff under review
- Import-resolution context (other files the reviewed code depends on)
- Project-level context to improve accuracy (README, type stubs, surrounding modules)
The payload is unmodified source code in plaintext. It travels over TLS, but once it reaches the provider's infrastructure it is subject to that provider's data-retention and model-training policies. Enterprise agreements and zero-data-retention tiers exist, but they require explicit opt-in and are not the default.
The Regulatory Gap
For many codebases, the question isn't whether to send code — it's whether they're allowed to.
A health-tech team whose test fixtures include PHI-adjacent patterns can't route those files through an external API on every commit without a signed Business Associate Agreement covering the review tool. A financial system under PCI-DSS processing scope has limits on what data can leave its network perimeter. A defense contractor under ITAR or CMMC has explicit restrictions on foreign-national data access and cross-boundary transmission.
These aren't edge cases. They're standard constraints for any team in a regulated industry. BrassCoders's --offline flag satisfies all of them: zero bytes leave the machine. Scanner findings stay local. Nothing is transmitted anywhere.
The Practical Gap for Proprietary Code
Outside regulated industries, most production codebases carry some proprietary constraint — an NDA, a trade-secret designation on the core algorithm, an investor agreement that limits disclosure, or simply a strong preference not to transmit novel IP to a third party's training pipeline.
Sending a Python file containing a novel pricing algorithm or a proprietary trading strategy to an external API on every commit is a legal and business-risk decision, not a technical one. Many teams make it implicitly, because the developer typed the diff into a browser tab and asked Claude. A systematic per-commit review tool requires a deliberate decision about what data classification rules apply.
BrassCoders's offline mode sidesteps the decision entirely. No data leaves. No agreement needed. The scan runs in CI on every commit, returning deterministic findings, with the same compliance posture as running flake8.
What the Paid-Plan Enrichment Actually Sends
For teams who want AI-powered enrichment and have no egress constraints, BrassCoders Paid sends a tightly scoped payload through the BrassCoders gateway — not raw source code.
The payload contains:
- Already-redacted scanner findings (credentials, PII, and high-entropy strings are stripped at the scanner layer before transmission)
- A project signature of at most 7,500 characters, derived from README content, the package manifest, top-level directory names, and entrypoint filenames
Raw source never leaves the machine under the Paid plan either. The BrassCoders data handling page documents the exact fields and their derivation.
The Automation Consequence
Beyond compliance, there's a practical automation gap. LLM-based code review is invoked. Someone has to ask. On the commits where nobody asked — the Friday afternoon push, the hotfix, the one-line change that "obviously doesn't need review" — nothing runs.
BrassCoders's generation-mode benchmark tracked whether the model issued proactive warnings after generating code that contained bugs. It warned in 0 out of 6 tasks. The model wrote an O(N²) loop and moved on. It only flagged the problem when the benchmark script sent an explicit review prompt.
A pre-merge gate has to run on every commit, not on the commits someone chose to review. brasscoders --offline scan in a GitHub Actions step runs on every push and every pull request. No invocation, no configuration per commit, no budget approval per run.
What to Run
The two tools do different jobs. A BrassCoders scan on every commit catches the deterministic, rule-matchable problems — performance anti-patterns, secrets, PII leaks, interprocedural taint flows — locally, for free, automatically. An LLM reviewer invoked by a developer on pull requests catches intent-level problems, naming issues, and the logic bugs that require reasoning to find.
The gate runs automatically. The conversation happens by choice. Neither substitutes for the other.
pip install brasscoders
brasscoders --offline scan /path/to/project
Top comments (0)