Skip to content
Download PDF

How Do You Verify Code Written by an AI Agent? ​

Short answer. Verifying AI-written code means running the project's actual test and lint commands plus spec-scenario coverage — not asking the model whether it believes the change is correct — and bounding how many times a failing change gets retried before a human has to step in. The second half is the part most tooling skips, and it is the one that stops an agent from looping on the same failure indefinitely.

Why "the agent says it works" is not verification ​

An AI coding agent can produce a confident summary of a change without that summary being backed by anything that actually ran. Verification has to be external to the model: a real command, with a real exit code, checked against evidence the tool — not the model — collected.

How Maistik Forge does it ​

forge verify runs the project's configured test/lint command plus spec scenario coverage and prints a verdict — PASS or FAIL. Run bare, it is read-only and always exits 0, so it is safe to drop into any existing workflow. Opted into with --change <c>, it becomes the verify circuit-breaker: Forge tracks consecutive failures for that change, and at a threshold (default 3) it prints CIRCUIT OPEN, returns a non-zero exit, and forces escalation to a human instead of retrying against the same wall. A passing verify resets the streak. For a change that needs to be checked away from a dirty working tree, isolated verification runs the same check against an ephemeral copy of the repo.

Questions people actually ask ​

What stops an AI agent from just retrying forever until a test happens to pass? ​

The circuit-breaker's threshold. forge verify --change <c> --max-failures N bounds consecutive failures; once the count is hit, the command returns non-zero and Forge treats that as a stop condition — not a suggestion the agent can ignore, because the exit code, not the agent, decides whether the loop continues. See the full mechanics for the exact progression.

Does verification also check for security issues, not just test failures? ​

That is a separate, complementary control. forge secscan statically scans a change for leaked secrets, PII, and prompt-injection strings and blocks on any unwaived finding — verification and security scanning are two of Forge's enforced controls, run independently.