Compiler Fences: A C++ Sanitizer Workflow for AI-Generated Patches

A unit test proves what your agent intended; a compiler warning proves what the language specification requires. These two facts rarely carry the same weight, which is why the first reviewer of an AI-generated C++ patch should be the toolchain itself. Before you read a single diff, configure your compiler to reject undefined behavior, implicit conversions, and suspicious pointer arithmetic. Then feed the same errors back to the agent, and you will have a much more productive conversation.

The Warning That Started It

Consider a patch that rewrites a loop to use std::span and indexes into it with a signed offset. Your unit tests pass because the test vector happens to be long enough, and your debug build sees nothing unusual. When you compile with -O2 -Warray-bounds, the optimizer discovers that an index can be negative and emits a warning that test coverage completely missed. That discrepancy is the core argument for a compiler fence: static analysis catches the cases your examples never hit.

A fence means you deliberately build your code in two or three configurations and treat warning-as-error in each one. The first configuration uses a strict warning set. The second adds address and undefined-behavior sanitizers. The third, optional one, enables link-time optimization and aggressive inlining to expose warnings that only appear under optimization. This may sound like overkill, but for agent-generated code it is the cheapest insurance available.

Step 1: Harden the Compiler Invocation

Create a CMake preset that bakes in your non-negotiable flags. For GCC and Clang, a practical starting set looks like this:

add_compile_options(
  -Wall -Wextra -Wpedantic -Wconversion -Wshadow
  -Wformat=2 -Wnull-dereference -Wmisleading-indentation
  -Werror
)

if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
  add_compile_options(-Wdocumentation -Wcomma -Wrange-loop-analysis)
endif()

set(CMAKE_CXX_FLAGS_SANITIZE
    "-fsanitize=address,undefined -fno-sanitize-recover=all")

The -fno-sanitize-recover=all part is essential. With recovery enabled, the sanitizer prints a runtime error and continues running, so the program may exit zero and confuse your CI. Without recovery, the first violation aborts with a non-zero status, which gives your agent an unambiguous signal: this change is not acceptable as written.

You should also pin the compiler version. If your local machine uses GCC 13 and your CI uses GCC 12, a warning in the newer version will never surface in the pipeline. Use a container or a version manager to make the fence reproducible. The goal is a stable oracle, not a debate about toolchain differences.

Step 2: Run a Sanitized Test Pass

Create a script, for example fence.sh, that builds with the sanitize flags and then executes your test suite with ctest:

#!/usr/bin/env bash
set -euo pipefail

cmake -S . -B build-fence -DCMAKE_BUILD_TYPE=RelWithDebInfo \
      -DCMAKE_CXX_FLAGS="$CMAKE_CXX_FLAGS_SANITIZE"
cmake --build build-fence --parallel
ctest --test-dir build-fence --output-on-failure

Run this script before any human review. When your agent proposes a patch, you make one call to fence.sh. If the build fails because of a warning, the output is the correction message. If the tests crash under ASan, the stack trace points directly to the symptom, and you can include that trace as a prompt for the agent's next attempt. This loop is mechanical, but it is far more reliable than telling the agent “something is wrong, please review your changes.”

One caution: sanitizers can detect errors on code paths the tests do not cover. So a sanitized test pass is only as valuable as your test suite. Pair it with a few property-style tests, and you get a solid lower bound on behavior preservation.

A Decision Table for Warning Classes

Not all diagnostics deserve the same reaction. The table below maps common compiler messages to the agent behavior they indicate, so you can triage output quickly.

Diagnostic	What it reveals	Recommended action
-Wconversion	Implicit narrowing that changes values	Require explicit casts; send back to the agent
-Wnull-dereference	Dereference after a path where pointer is null	Reject immediately; add a null check
-Warray-bounds	Off-by-one introduced by indexing logic	Add a bounds assertion and rebuild
-Wshadow	A variable hiding an outer name	Usually cosmetic; can mask bugs
UBSan runtime error: signed integer overflow	Arithmetic overflows on a valid input	Non-negotiable; fix before merge
ASan heap-buffer-overflow	Memory access outside allocated region	Reproduce with a minimal test case

Use this table as a starting point for your own policy. The point is not to fix every warning mechanically, but to sort them into “must fix now”, “must understand”, and “safe to ignore for this patch”. Agents that keep seeing the same class of warning will eventually learn to avoid it, provided you give the warning output as context in the next iteration.

Integrating the Loop on Free Infrastructure

Running two builds and a sanitized test suite on every agent patch can burn time on metered runners. This is where a free server option helps: you can dedicate a small box to execute the fence exactly when a patch arrives, without paying per-minute fees. The free model access handles the subsequent fix attempts, which means your cost for the entire review cycle stays close to zero. The loop becomes simple: your agent proposes a change, the free server compiles it with the fence, and the sanitizer output returns as context for the next proposal. Disclosure: This article was prepared as part of MonkeyCode's product outreach.

Even with free resources, you should put a limit on each run. Use timeout 600 ./fence.sh and a memory cap like ulimit -v 2097152 so one misbehaving patch cannot take down the box. Free does not mean unprotected; it means the infrastructure is available, not unlimited. Treat your free server like any production system and define a budget for every job.

Limits of the Compiler Fence

Compilers do an excellent job of detecting undefined behavior, type mismatches, and obvious memory issues. They are completely blind to algorithmic complexity, API coherence, and design intent. A patch can pass every warning flag and still introduce a quadratic loop into a hot path, because no compiler flags can tell you about asymptotic complexity. You still need human judgment for structure and readability.

Sanitizers also have a runtime cost, often between 1.5x and 4x for the test suite. For a large project this can make the fence too slow to run on every commit. If that becomes a problem, schedule the fence to run on a filtered subset of tests that cover the modules touched by the patch, and run the full suite only once a day. The overhead is bounded and predictable, which matters more than absolute speed when reviewing agent output.

Finally, warnings differ across compilers and standard library versions. A patch that compiles cleanly with GCC may trigger -Wstringop-overflow with Clang, or the reverse. Choose one toolchain for the fence and document it. If your production environment uses a different one, add a separate configuration for that compiler but keep it as a secondary signal.

When You Should Skip This Workflow

If your patch only touches README text or build configuration, a full compiler fence is disproportionate. Likewise, a codebase already compiling with hundreds of warnings will drown your agent in legacy noise if you flip on -Werror globally. Introduce the fence progressively: start with a new module, then expand as the warning count drops. You can also exclude generated code and third-party dependencies, but never exclude code your agent wrote. The purpose is to force the agent to confront the same standards as a human contributor.

Set up one sanitizer build before your next agent patch. The compiler is the only reviewer that never gets tired, never assumes context, and never rationalizes away a mistake. Give it a seat at the table, and your review will become shorter, because the machine already asked the first round of questions.