Public evidence

The verification bottleneck is already here.

AI coding is producing real gains. It is also producing more software, faster than traditional review and validation processes can absorb.

The sources below are public engineering research and first-hand discussions. Together they show why a generator's confidence is not the same thing as independent evidence that consequential work is complete.

The shift in one frame

Generation↑ abundant
Review capacity→ constrained
Evidence✓ must be established

These sources are not endorsements of FalseGreen.

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

high AI adoption vs. low

+66.2%

epics completed per developer

+33.7%

task throughput per developer

+16.2%

PR merge rate per developer

Read the Faros research

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

median review time
PR size+51%
review time

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 report

96%

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 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 duplicate

The report describes an 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 thread

Claude Code issue #32650

user-created meta-issue · stale / not planned

A 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-issue

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 AI-generated code—not another coding agent, AI reviewer, or generic scanner.