In a previous post I built a small harness that lets the compiler argue with demo-quality C++ code produced by coding models. That harness had a blind spot: plenty of model output compiles cleanly and is still wrong. Code that passes -Wall -Werror -pedantic can still read out of bounds, use-after-free, or rely on signed overflow the moment the optimizer gets aggressive.
This follow-up closes that gap. Instead of asking "does it compile?", the question becomes "does it survive AddressSanitizer and UndefinedBehaviorSanitizer?" — a much less forgiving judge. And because model access and CI compute both cost money, I'll also walk through how I structure the loop so the whole evaluation runs on free tiers, including MonkeyCode's free model access and its free server option, without making the results depend on any specific paid plan.
Why sanitizers are a better grader than a compiler
A compiler checks that code is well-formed. Sanitizers check that a specific execution is well-behaved. For evaluating model-generated fixes, that difference matters:
Compiler says yes, runtime says no. The classic model failure: it "fixes" a bounds bug by adjusting a loop condition that looks right but is off by one on the empty-input path. GCC/Clang accept it; ASan kills it on the first test case.
