Build Green Is Not Behavior Green

An AI agent moves a few modules, rewrites imports, runs the build, and reports success.

The build is green.

The application is not.

A button now returns to the wrong state. A plugin initializes after its first consumer. A live binding was converted into a captured value. A tray is still visible, but its orientation changed. A browser-extension message handler returns before its asynchronous response. A package export disappeared even though the bundled application still starts.

None of these failures contradict a successful build.

They expose the boundary of what the build was designed to check.

What a build actually proves

A build can provide valuable evidence:

• the parser accepted the source;
• modules resolved under the configured bundler;
• configured transforms ran;
• type checking may have passed;
• assets may have been emitted;
• the toolchain reached an output state.

That matters.

But it does not establish that:

• the same user flows still work;
• the same modules initialize in the same order;
• the same symbols remain available;
• the same storage and network contracts remain stable;
• the application behaves correctly after reload;
• a dynamic import still resolves under standard module semantics;
• visual layout is unchanged;
• background processes or workers still behave;
• an agent stayed inside the declared scope;
• the original repository remained untouched before acceptance.

A green build is one evidence layer, not a verdict on the entire change.

Why AI amplifies the gap

Human engineers have always introduced build-green regressions.

AI agents change the economics.

An agent can move more code, touch more files, and generate more plausible compatibility structures in one session than a reviewer can comfortably inspect. It can also produce a confident explanation that makes the change feel more understood than it is.

The problem is not that agents are uniquely careless.

The problem is that their mutation speed is outpacing the evidence and review systems around them.

When the diff becomes larger, “the build passed” becomes less reassuring, not more.

Example: initialization order

Consider a module that registers a provider at top level.

Another module reads that provider during its own evaluation.

An agent sees a large file and extracts both responsibilities into cleaner files. Imports resolve. Types pass. The final bundle builds.

But the new import graph evaluates the consumer before the registration side effect.

The failure appears only at runtime.

A good change-control system needs evidence about:

• top-level effects;
• dependency order;
• import topology;
• live bindings;
• before-and-after module load;
• actual runtime behavior.

No single check covers every case. Independent layers make the conclusion stronger.

Example: visible but wrong

Suppose an agent refactors a customization panel.

The panel remains in the DOM. A screenshot still contains the right colors. The build passes.

But the panel changed from a horizontal tray to a vertical stack, placing controls below the expected viewport. A selector-presence test also passes because the controls still exist.

The missing evidence is geometry and interaction:

• bounding boxes;
• orientation;
• visibility in the relevant viewport;
• clickability;
• state reached after interaction;
• comparison with the baseline.

“Element exists” is not the same claim as “the interface still works.”

Example: public surface drift

A refactor may preserve the bundled application but drop a public export used by another package.

The local build does not exercise that consumer.

The candidate seems correct until the next repository or release wave imports the symbol.

A transaction-aware guard should compare declared public contracts, not only local runtime success.

The same applies to:

• CLI flags;
• package export maps;
• generated artifact schemas;
• configuration keys;
• browser-extension message types;
• JSON payloads;
• plugin registrations.

Evidence needs causality

A common weakness in CI is that it evaluates the final repository state without understanding the intended transaction.

KodeProof is being designed around a different question:

Did this declared change introduce a regression, violate a protected contract, or fail to complete its objective?

That requires a before-state and a declared scope.

A useful transaction record includes:

• immutable original fingerprint;
• files and surfaces authorized to change;
• protected contracts;
• architectural objective;
• expected moves, additions, deletions, or consolidations;
• required project checks;
• runtime scenarios;
• candidate workspace;
• exact evidence and verdict;
• transfer state.

This lets the system distinguish several outcomes that a single green/red CI status cannot.

The outcomes should remain separate

A trial can be:

Behaviorally valid but incomplete

The agent did not break the program, but it also did not complete the requested decomposition.

Valid candidate, product-blocked

The independent grader says the candidate satisfies the task, but the guard refuses transfer. This may be a false block, a manifest problem, or an unresolved contract disagreement.

Agent-declared success, hidden regression

The agent says it is done, while independent evidence finds a material failure. This is false confidence.

Correctly blocked

The guard prevents transfer because the candidate introduced a verified regression or violated a declared contract.

Trusted and transferred

The candidate satisfies the independent task, the configured evidence, and the transfer policy.

These categories are commercially more meaningful than a composite score.

A verification product cannot grade itself

KodeProof’s own verdict cannot be the sole measure of whether KodeProof works.

That would create a circular claim:

The product says it is correct because the product’s checks passed.

Evaluation needs an independent grader that does not rely on KodeProof’s verdict.

For a frozen campaign, that means preserving:

• task and fixture;
• hidden grader;
• model and harness;
• reasoning settings;
• KodeProof build and configuration;
• budgets;
• repository before-state;
• rubric version;
• raw events and artifacts.

Known-bad candidates should be introduced deliberately to prove the grader can detect them. Valid alternative solutions should be tested to expose false blocks.

The uncomfortable results belong in the report.

Green needs strength and coverage

A green result should answer:

• Which checks ran?
• Which surfaces were covered?
• Which dynamic paths were not observed?
• Did the candidate pass an independent task grader?
• Was the environment valid?
• Was the evidence fresh for the exact source?
• Did the candidate transfer?
• What remains unknown?

The honest statement may be:

No configured layer found a regression for the declared transaction. Two dynamic-import paths were not exercised.

That is more useful than:

Verified safe.

The practical stack

For a risky AI-driven refactor, a layered workflow may include:

1. Source and environment snapshot.
2. Declared refactor contract.
3. Structural plan and preview.
4. Isolated candidate workspace.
5. Parse, type, lint, and build checks.
6. Import/export and module-load checks.
7. Initialization and effect analysis.
8. Selected tests and full project gates.
9. Characterized behavior or browser scenarios.
10. Independent task grading.
11. Causal blocker explanation.
12. Atomic transfer or non-transfer.
13. Immutable evidence record.

Not every change needs every layer.

The contract should select the evidence appropriate to the risk.

What the claim should be

KodeProof should not claim that it makes AI code correct.

The useful promise is narrower:

KodeProof turns a risky AI-driven change into an isolated, declared, evidence-backed transaction and controls whether the candidate reaches the original repository.

The build still matters.

It just no longer gets to speak for every property of the software.