Scope
The required result, permitted actions, systems, and users.
Proof for independent acceptance
Don’t ship the agent’s confidence. Ship evidence.
Coding agents can produce more software. The acceptance burden does not disappear.
FalseGreen verifies the exact implementation against frozen requirements instead of accepting the coding agent's own completion claim.
The evidence can come from software checks, Lean formal proofs, security tooling, or rendered UI observations. The acceptance authority stays independent.
Frozen requirements in. Independent result out.
The evidence below combines public research and a FalseGreen benchmark. It does not verify or certify an entire foundation model.
Why the boundary matters
AI advisinghuman reviewed
AI actingconsequential
Independent evidence✓ must be established
These sources are not endorsements of FalseGreen.
The verification boundary
Verify the implementation, not the agent's confidence.
FalseGreen defines what the software must do, observes the exact implementation, and reports the gap.
The verification target is one bounded consequential software Job: its frozen criteria, exact observed source, execution environment, and required evidence.
Behavior
The expected actions, state changes, and failure paths.
Evidence
The checks and artifacts that establish each criterion.
Handoff
A durable report of observed results and remaining gaps.
01 · The upside is real
AI coding is working.
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
More code did not create more review capacity.
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×
PR size+51%
review time5×
Faros compares periods of low and high AI adoption within the organizations represented in its dataset.
03 · Adoption and trust
Teams are using AI code they do not fully 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
AI-assisted share of committed code42% today → 65% expected by 2027
04 · Confidence is not evidence
Production readiness cannot be inferred from confidence.
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
The coding agent can say it is finished before the work is finished.
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 to test rather than the final authority.
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 a 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
The coding agent said done. FalseGreen found otherwise.
In the retained benchmark, unguarded agents — including an agent 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 coding agent | 87.5% | — |
| 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.
Case study · Ada/SPARK
From wrong theories to ACCEPT.
On one bounded SPARK change, the acceptance target stayed fixed while verification evidence repeatedly falsified incomplete or overbroad implementation theories. The coding agent repaired and narrowed the solution; FalseGreen independently reverified the source-bound change and issued ACCEPT.
Same agent. Better solution. A real stopping condition.
Read the full case study →target fixed
theory falsified by evidence
repair verified against the same boundary
result source-bound ACCEPT
Durable evidence
Keep the result after the coding session ends.
FalseGreen issues a durable, shareable result tied to the observed source, frozen criteria, and evidence from the verification run.
Install FalseGreen →Source-bound evidence
Criteria, observations, and the exact server-observed source identity stay together.
Durable result
A FalseGreen-issued report remains shareable after the coding session ends.
Actionable repair
Failed criteria return concrete repair work within the defined scope.
The FalseGreen response
The generator should not be the final authority.
Independent verification starts by defining what done means before implementation begins. It ends with evidence tied to the source state—not a polished completion message from the system that made the change.
01
Define the target
Make the expected outcome and failure conditions explicit.
02
Freeze the criteria
Bind verification to the agreed source state.
03
Execute independently
Run the required checks and preserve the resulting evidence.
04
Report what was established
Separate verified results from assumptions, gaps, and failures.
FalseGreen is independent verification for consequential consequential software changes—not another coding agent, AI reviewer, or generic scanner.