# 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](/harness/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](/harness/isolation) 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](/harness/circuit-breaker) for the
exact progression.

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

That is a separate, complementary control. [`forge secscan`](/harness/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](/harness/overview), run
independently.