Scope
The required result, permitted actions, systems, and users.
dev branch · NOT production · production is falsegreen.comProof
FalseGreen verifies the result and produces the verdict — your AI coding agent never grades its own work.
The verification boundary
FalseGreen defines what the software must do, observes the exact implementation, and reports the gap.
The verification target is your whole program under a FalseGreen Job: its frozen criteria, exact observed source, execution environment, and required evidence.
Scope
The required result, permitted actions, systems, and users.
Behavior
The expected actions, state changes, and failure paths.
Evidence
The checks and artifacts that establish each criterion.
Report
A report of what passed, what failed, and what was never checked.
01 · The upside is real
The case for verification does not begin with “AI cannot write software.” Current engineering telemetry shows meaningful gains in throughput and delivery activity as AI adoption increases.
More output is valuable. It also changes what the organization has to validate before that output becomes a production result.
Faros AI Engineering Report 2026
Two years of telemetry · 22,000 developers · 4,000 teams
+66.2%
epics completed per developer
+33.7%
task throughput per developer
+16.2%
PR merge rate per developer
02 · The constraint moved
GitLab's 2026 AI Accountability Report found that 85% of respondents agreed AI had shifted the bottleneck from writing code to reviewing and validating it. Faros telemetry points in the same direction from the workflow itself: pull requests got larger while median review time increased.
Machine-speed output entered a human-speed review system. The result is not that review became optional; it became the scarce resource.
Review load
5×
Faros compares periods of low and high AI adoption within the organizations represented in its dataset.
03 · Adoption and trust
Sonar's 2026 survey describes a verification gap inside normal development practice: developers are using AI every day, but many do not trust the resulting code to be functionally correct.
The important signal is the distance between the two numbers—not a claim that AI-generated code is uniformly bad.
Read the Sonar survey report96%
do not fully trust AI-generated code to be functionally correct
Sonar survey · 1,100+ professional developers
48%
say they always verify AI-assisted code before committing
The survey's reported verification behavior
04 · Confidence is not evidence
CloudBees' research with more than 200 enterprise technology leaders found a sharp contrast between what leaders believed about AI-generated code and what they were experiencing downstream.
92%
expressed confidence in the production readiness of AI-generated code
Confidence reported in the CloudBees State of Code Abundance research.
81%
reported an increase in production issues tied to AI-generated code
A reported operational outcome, not a claim of causation.
05 · Completion is a claim
Public issue threads in the Claude Code repository document a narrower failure mode: completion can be reported without the underlying action or check being established.
These are user reports, not prevalence studies. They do not show that agents always behave this way. They show why “done” should remain a claim a machine tests — never one the builder declares.
The meta-issue is a user-created report, not an Anthropic-confirmed taxonomy; GitHub marks it stale and closed as not planned.
Claude Code issue #69499
user report · closed as duplicateThe report describes an AI coding agent marking documented workflow steps as complete without opening or executing the referenced procedure, then admitting it had not done so when asked.
Read the issue threadClaude Code issue #32650
user-created meta-issue · stale / not plannedA separate meta-issue compiles reported failure modes such as phantom execution claims, unverified file edits, and checks that cannot meaningfully return a failure result.
Read the meta-issueBenchmark / proof
In the retained benchmark, unguarded AI coding agents — including one that self-verified — reported 87.5% of incomplete tasks as complete. FalseGreen's independent verification recorded 0.0% false-green, 0.0% false-accept, and 0.0% false-reject on the same trials.
| Verification approach | False-green rate | False-accept / false-reject |
|---|---|---|
| Unguarded AI coding agent | 87.5% | — |
| AI coding agent + self-review | 87.5% | — |
| FalseGreen (independent verification) | 0.0% | 0.0% / 0.0% |
Measured in the retained 72-trial completion-assurance benchmark (v0.1.0): three arms over the same synthetic Python tasks. The retained run uses a stub model — it measures the acceptance mechanism, not any specific foundation model. These rates describe this benchmark, not a universal accuracy guarantee.
The report
Every FalseGreen Job ends in a shareable report: the verdict, the evidence behind each requirement, and the security findings — tied to the exact code it ran on.
Source-bound evidence
The requirements, the evidence, and the exact code they ran on stay together in one report.
Shareable result
A FalseGreen-issued report remains shareable after the coding session ends.
Actionable repair
A Failed verdict returns the exact failing test, violated rule, or counterexample — repair work for your AI coding agent.
FalseGreen response
Independent verification starts by agreeing what done means before implementation begins. It ends with a report decided on your exact code — not a completion message from the system that wrote it.
Define the target
Make the expected outcome and failure conditions explicit.
Freeze the criteria
Bind verification to the agreed source state.
Execute independently
Run the required checks and preserve the resulting evidence.
Report what was established
Separate verified results from assumptions, gaps, and failures.
FalseGreen is independent verification for consequential software changes — not another AI coding agent, AI reviewer, or generic scanner.