AI Code Correctness Gap: Plausibility vs Reality Inspector

Deceptive AI Output (Rust) Compiler Rejection

Diagnostic Inspector & Memory State High Risk / Hidden Fault

⚠ Borrow Conflict (E0502)

Cannot borrow `items` as mutable because it is also borrowed as immutable in outer loop iterator.

AI Model Assumption

"Iterating through a vector while appending or modifying elements inside a helper closure is straightforward sequential logic."

Compiler / Runtime Truth

Rust's alias XOR mutability axiom forbids active iterator pointers while mutating vector capacity. Prevents dangling pointers!

Active References & Allocations

Production Stress-Test & Scaling Simulator O(N²) Quadratic Degeneration

Plausible AI code frequently passes toy inputs (N=10) but collapses under production scale. Adjust dataset volume to simulate latency & memory behavior:

Input Scale (N): 10,000

420 ms

AI Code Latency

1.2 ms

Idiomatic Latency

350x

Efficiency Gap

At N=10,000, repetitive quadratic lookups consume 100,000,000 operations vs 10,000 hashed lookups.

Code correctness lesson: dependency order and illustrative scaling

Your browser does not support video.

Read the explanation

The Rust preset presents a closure that captures the original vector for mutation while another loop wants to read it. The proposed refactor separates the two phases. Read the original values first and collect doubled values above ten in another vector. For five, twelve and twenty, that produces twenty-four and forty. After iteration ends, extend the original vector and retain an audit log of twelve and twenty. The dependency diagram shows the order required by the refactor. The site displays authored diagnostic steps, code and assertions; it does not invoke a compiler, inspect arbitrary submitted code or prove that a binary was rejected. Its compiler error label is teaching content, not a fresh compiler receipt. The Python example rebuilds a list of database identifiers for every incoming record and then searches that list. Work scales with incoming count times database count. Preparing a set once changes the expected work to the sum of those counts, with expected constant-time membership under ordinary hashing assumptions. The site substitutes illustrative timing equations: N squared times eight times ten to the minus eight milliseconds, versus N times two times ten to the minus six milliseconds. At ten thousand records the displayed formulas give eight milliseconds and point zero two milliseconds, or four hundred times. At one hundred thousand, they give eight hundred and point two milliseconds. The plot uses eight pixels per thousand records and point three five pixels per millisecond. It performs no benchmark; even its scripted eight point five second anecdote differs from these assigned curves. Preset selection resets the scripted step index. Next and previous navigate the authored diagnostic states; run trace advances those same states on a timer. The prompt and assertion tabs display fixed strings rather than executing a guard or a test harness. Export downloads a dossier containing selected code, scripted failure mechanics, refactor, prompt, assertions and the current metric strings. The dataset slider changes formulas and redraws the canvas chart. None of these interactions sends a model request or runs the displayed Rust, C plus plus, Go or Python code. Treat this as an interactive lesson and an exportable example, then validate real code in its actual toolchain.