Quick answer: A green build proves the code compiles, the types line up, and the existing checks still pass, and it does not prove the new behavior is correct. The build runs the checks that already exist, so a changed path with no test passes while carrying a logic defect. Add a real request and a business-flow check on the changed path before merging, and treat the build as one gate rather than a verdict.
What a green build actually proves
A continuous-integration pipeline typically runs a typecheck, a linter, and the existing test suite. A green result means those specific checks did not fail, which is real evidence that the code is internally consistent and has not broken an already-tested path. It is worth having, and a red build is a hard stop.
What it does not provide is evidence about behavior nobody wrote a check for. If the AI change introduces a new branch or alters a condition and no test exercises it, the suite stays green because the new logic is simply not evaluated. The build answers "does it still compile and pass known checks," and it cannot answer "does it do the right thing."
Build evidence versus behavior evidence
| Evidence type | What it confirms | What it misses |
|---|---|---|
| Typecheck | Types and signatures line up | Whether the logic is correct |
| Linter | Style and known patterns | Business rules |
| Existing tests | Already-covered paths still work | New, untested branches |
| Real request | The live endpoint behaves as expected | Paths the request does not cover |
| Business-flow check | The multi-step flow still completes | Edge cases outside the flow |
The last two rows are the evidence the build cannot generate, and they are the ones that confirm the change rather than the consistency of the code.
How to add the missing checks
- Read the changed path and identify the new branch or condition the diff introduces.
- Confirm whether an existing test reaches it, and treat a missing script as unverified.
- Send a real request that exercises the new path and assert the response against the contract.
- Run the business flow around it, so the change is checked in the sequence it really runs.
- Keep the build green as a baseline, but only merge once the new path has its own evidence.
Consider a change that adds a filter excluding archived notes. The build stays green because no test covers the new condition. A real request that deletes a selection containing an archived note reveals the note is now dropped, and the business-flow check shows the caller that still expects it. The defect is invisible to the build and obvious once the changed path is exercised.
The empty-result trap
A run that returns no failures is not automatically a pass when the check did not actually cover the change. If the test command is missing, the selector matches nothing, or the new path is never invoked, the result can read as success while proving nothing. Confirm the check ran against the intended code rather than trusting the zero-failure output.
The verdict model keeps this distinction: no verified evidence is inconclusive, partial verification stays partial, and only fully verified evidence passes, with no LLM involved in that decision.
Powerduck classifies the evidence by type and keeps the static and dynamic results separate, so the reviewer can see that a green build does not cover the new path.
Adding checks without slowing the gate
Real requests do not have to replace the fast build, and the two run at different points. Keep the typecheck and the existing suite in the quick pipeline so every commit gets the cheap static gate, and run the targeted requests on the changed path as a separate, slightly later check rather than bundling everything into one slow stage. This keeps the fast feedback fast while still confirming the new behavior, and the merge waits for the dynamic gate rather than the build alone. As the request set grows, keep it tied to the changed paths so it stays focused, and reuse the stored calls so the verification does not become a manual burden each time.
Honest limits
Real requests and flow checks also have scope. They confirm the specific paths they exercise, and they do not cover every edge case, and dynamic loading or external consumers can remain outside the test. The review can raise false suspicions or miss defects, and an AI-only claim stays a hypothesis until a runnable check backs it.
Frequently asked questions
Does a green build mean the change is safe? It means the code compiles and known checks pass, and an untested new path can still be wrong.
What if there is no test for the new branch? The branch is unverified, so add a real request or a test before the merge.
Is a zero-failure run always a pass? No. If the check did not cover the change, an empty result proves nothing.
The bottom line
A green build is a necessary gate and an insufficient verdict: it confirms compilation and already-covered paths, while the new behavior can stay untested and still pass. Add a real request and a business-flow check on the changed path, and remember that an empty result is not a pass when the check never ran. Static consistency plus verified behavior is what makes a merge confident, not the color of the build alone. Read more in the AI code review guide.
