5 Anti-Patterns Cora Code Caught That Other Reviewers Missed

Code review is not just about catching bugs. It is about catching patterns that lead to bugs, maintenance debt, and architectural decay. Here are five real anti-patterns that Cora Code flagged across our production repositories — patterns that diff-only reviewers consistently missed.

1. Silent Error Swallowing with unwrap()

Cora Code's static scanner flagged 68 .unwrap() calls in a single repository. A naive approach would be to fix all 68. But Cora's tree-sitter AST analysis showed that 67 of them were inside #[cfg(test)] blocks and #[tokio::test] functions — perfectly idiomatic Rust test code.

Only one unwrap() was in production code. That is the one that needed fixing. Without AST-aware context, a human reviewer (or a diff-only AI tool) would either flag all 68 (wasting time on 67 false positives) or miss the one that matters.

2. Cross-Module Duplication

A developer added a validation function in a new service module. A diff-only reviewer saw clean, well-written code and approved it. Cora Code's Brain Mode search found that an identical validation function already existed in a shared utility module — same name, same logic, same edge cases.

The fix was a one-line import. Without semantic search across the full codebase, this duplication would have shipped to production and created a maintenance headache when the validation rules inevitably needed updating.

3. Broken Caller Chain After Refactor

During a refactor, a developer renamed a core function from process_order to handle_order_flow. They updated the tests and the direct callers. But they missed an indirect caller three layers deep in an event handler.

Cora Code's cora impact command traced the recursive dependency chain and found the broken reference. cora callers confirmed there were 7 total callers, but only 6 had been updated. The 7th was the event handler that would have caused a runtime panic in production.

4. Security Scanner False Positive vs Real Vulnerability

Cora Code runs 13 security patterns and 15 secret detection patterns as deterministic rules (no LLM needed). In one repository, it flagged a CORS wildcard (Access-Control-Allow-Origin: *) in a markdown documentation file.

This is a false positive — the documentation was describing API behavior, not implementing it. But in the same scan, it caught a real hardcoded API key in a test fixture that was about to be committed. The dual-scanner architecture (static patterns + LLM review) with shared false-positive suppression means you get both breadth and accuracy.

5. LLM JSON Truncation in Scan Results

This is an anti-pattern in the tool itself, not the code being reviewed. During a cora scan, the LLM returned truncated JSON responses that caused entire batches of findings to be silently dropped. The output still said No issues found! — misleading because the LLM batches were skipped, not scanned clean.

We fixed this with a three-stage fallback: strict JSON parse, then repair_truncated_json (bracket-closing), then partial object extraction that recovers complete objects from truncated arrays. The lesson: always verify that your AI tools are actually processing data, not silently skipping it.

The Pattern

Every one of these anti-patterns shares a common thread: they require understanding code beyond the diff. Duplication lives in other files. Broken callers live in distant modules. False positives live in test code. Semantic analysis is not a luxury — it is the difference between catching real problems and generating noise.