rust-intel

Rust Intel — Defense Against LLM Failure Modes

Scope, stated up front. This spec assumes your code already compiles. It assumes cargo test is green. That is not enough. The categories below cover the failure modes that survive rustc, clippy, and the test suite, and only manifest as production incidents, semver breakage, performance collapse under load, or silent data corruption. Compilation-only failures (lifetime variance in safe code, trait bound mismatch, GAT lifetime bound errors, object-safety violations through generic methods, cyclic workspace deps, ? in main, HRTB depth, recursive macro limits, self-referential structs in safe Rust, no_std reflexive std::* imports, From/Into cycles) are deliberately omitted — rustc already catches them and the LLM cannot ship them. (Exception: variance soundness in unsafe raw-pointer wrappers is not caught by the compiler — that is §B18a, and it is in-scope. Second exception: a method added to a published library's public trait without where Self: Sized loses object-safety only at the consumer's dyn Trait call site — rustc cannot flag it in the author's own crate, so it stays in-scope under Operating mode item 3 and §C1, mechanically backstopped by cargo-semver-checks in Post-flight.) This spec covers what ships anyway.

The fifty-nine categories (held in this skill's theme modules — see the category→module map below) rest on an empirical base — a published 6-month field report on ~80k LOC of production LLM-generated Rust, academic benchmarks (RustEvo², SafeTrans, CRUST-Bench, SafeGenBench, Rust-SWE-Bench, AkiraRust), the error distribution observed across Claude/GPT/Cursor through 2025–2026, and real supply-chain incidents (CrateDepression 2022, faster_log/async_println 2025). (The count is of numbered categories; §B1, §B3, §B4, §B15, §B18, §B25, §C1, §C12, and §D1 split into lettered sub-sections — §B1a/b, §B3a, §B4a, §B15a–e, §B18a, §B25a, §C1a, §C12a, §D1a — that are referenced and triggered individually but counted under their parent.) Citations, URLs, sample sizes, and every percentage live in references/sources.md; load it alongside this file when a figure is load-bearing. The category→module map below is the index; the category bodies live in the theme modules, not in this file.

Industry signal: per Faros AI and Lightrun studies (2026), shifting from low to high AI adoption more than doubles the incidents-to-PR ratio, and 43% of AI-generated code changes need debugging in production; among surveyed engineering leaders, zero rated themselves "very confident" that AI-generated code behaves correctly once deployed. (These figures concern AI-generated code in general, not Rust specifically — see references/sources.md.) This is the empirical context this document defends against.

The categories split into six tiers and a meta-layer, listed below:

• Self-monitoring: a triggers table (phrase- and code-pattern-based) that maps user-request patterns to risk categories. Scanned before generating code.
• Tier A — Compile-fix reflexes that leave silent residue (§A1, §A2, §A3): not "the compiler caught it and you fixed it correctly", but "the compiler caught it and the cheapest fix compiles while leaving a real defect behind". Stale-but-valid APIs, supply-chain via slopsquatting, reflexive Arc<Mutex<T>>, pub as a hammer for E0603 that silently expands the public API.
• Tier B — Silent correctness bugs (§B1–§B29): pass compilation, often pass tests, fail in production. This is where the spec lives. Includes UB, async pitfalls (basic and advanced), lock ordering, memory leaks, silent task dropping, cryptographic insecurity, TOCTOU races, backpressure neglect, Mutex poisoning, equality/hash contracts, runtime borrow panics, manual Send/Sync, iterator invalidation through indirection, serde field-presence drift, JoinHandle semantics, the async-Drop impossibility, select! side-effect cancellation, timing-attack-prone equality on secrets, panic / ownership across extern "C" FFI, lossy numeric conversions, wall-clock vs monotonic time, and UTF-8 string-boundary hazards.
• Tier C — Architecture and ergonomics (§C1–§C12, and §C12a): design-level mistakes that are expensive to undo. Reflexive .clone(), procedural macro hygiene, Cargo feature flag hygiene, channel-and-runtime mismatch, tracing span leakage, workspace feature unification, Deref polymorphism, reinventing a solved problem (or a whole subsystem) that a world-recognized crate already handles correctly on the input the hand-rolled version misses.
• Tier D — Testing and CI gaps (§D1–§D5): code passes tests not because it's correct but because the tests are blind. Timing-based async tests, #[should_panic] without expected, unit-vs-integration placement drift, test/prod divergence of build profile, scale, and concurrency, grep-filtered runner output hiding hangs, Windows zombie-process link wedges.
• Tier E — Systemic cost (§E1–§E6): correct in the small, wrong at scale — performance, allocation, complexity, and contention costs that survive rustc/clippy/tests and only bite under load. A different axis from A–D (cost, not correctness); enforced 🟡/🟢, never 🔴.
• Tier F — Semantic conformance (§F1–§F4): defects of meaning, not mechanism. The code is self-consistent, compiles, passes its own tests and clippy — and implements the wrong thing: it diverges from the named spec or reference implementation, contradicts the project's own documented guarantees, mishandles the boundary/error-path lifecycle of a connection or resource, or ships an encode/decode pair with no round-trip obligation. No grep finds these; they are found by reading the claim (RFC, README, function name, doc comment) and checking the code against it counterfactually. Reviewer stance for this tier is different — see "Tier F — how to review for meaning" below.