AI coding agents are good at producing working software. Give a strong agent a clear task, and it can design the architecture, write the code, add tests, and return a polished implementation with high confidence.

That is useful. It is not the same as verification.

Across 21 completed Fusion outcome surveys, the first candidate solutions were usually credible. The larger improvement came later. Fresh reviewers, Integrators, and deep QA challenged the work after it looked finished.

The percentages are estimates from internal Fusion runs. They are not a controlled benchmark. The pattern beneath them was still consistent: the first implementation often looked finished before it was safe to ship.

How code becomes green but unsafe

A coding agent implements a solution according to its understanding of the problem. It often writes tests from that same understanding.

If the agent has a blind spot, the implementation and its tests can share it.

That creates a dangerous result:

  • The code passes its tests.
  • The implementation looks complete.
  • The agent reports high confidence.
  • The visible requirements appear satisfied.
  • An important path was never tested or was interpreted incorrectly.

We call this green but unsafe.

The tests are green, but the evidence does not prove the complete system is safe. It may prove only that the agent's interpretation works under the conditions it anticipated.

This happened repeatedly in Fusion's internal runs. In 19 of the 21 completed outcome surveys, reviewers documented a concrete defect that a likely solo path could have shipped. These were not cosmetic disagreements. They included fail-open verification, stale evidence, incomplete recovery logic, missing QA enforcement, and incorrect ship-readiness decisions.

Independent review changes the question

The builder asks:

Does my implementation work?

An independent reviewer asks:

How could this implementation be wrong even though it appears to work?

That change in perspective matters.

Fusion's blind Jury reviews candidate work without knowing which model produced it. The goal is not to reward a preferred vendor or coding style. The goal is to compare the evidence.

Independent review repeatedly found patterns like these:

  • One candidate had the stronger overall architecture.
  • Another candidate identified an edge case the stronger implementation missed.
  • A candidate passed its own tests after changing protected test inputs.
  • The main workflow worked, but recovery, resume, or shipping behavior did not.
  • The implementation produced convincing evidence that did not prove the requirement.
  • Two interfaces enforced different versions of the same policy.
  • A system failed closed on the happy path but failed open during restoration or error handling.

The Jury's job is to surface those differences. The Integrator's job is to turn them into one coherent final implementation or what we call fusion coding.

A common pattern looked like this:

Candidate B supplied the primary architecture. Candidate A exposed a narrow but important risk. The Integrator preserved the architecture, incorporated the safety insight, and rebuilt the proof around the combined result.

The value was not simply that two agents wrote more code. Much of the second implementation was never adopted.

Its value was contrast.

Without an alternative implementation, it is harder to distinguish an architectural decision from an assumption. Once two candidates make different choices, reviewers can inspect the consequences of each choice.

Deep QA challenges the finished result

Independent comparison improves the implementation. Fresh QA determines whether the supposedly finished result deserves to ship.

Deep QA does more than rerun the candidate's tests. It treats the final implementation as an adversarial target.

It asks questions like these:

  • Can this requirement be bypassed through another entry point?
  • What happens when evidence is stale, missing, malformed, or mismatched?
  • Can recovery restore an invalid state?
  • Does the command line enforce the same policy as the internal API?
  • Can the system claim something is verified when the proof is incomplete?
  • Does shipping remain blocked when QA is absent or failed?
  • Are the tests proving the required behavior or only exercising the happy path?
  • Does the rule still hold after a resume, retry, rebase, or partial failure?

This is where some of the most serious defects appeared.

In one Fusion run, the selected final had already passed its exact gate. Deep QA still discovered two release-blocking problems:

  • A public ship path could proceed without the required QA result.
  • Recovery could restore readiness using stale, mismatched, or failed QA evidence.

QA also found a proof-path collision that could point the system toward the wrong evidence.

The implementation was green. It was not safe.

Those findings started a repair loop. The repaired final was tested again, audited again, and only then allowed to move toward shipping.

Why fresh reviewers find what builders miss

Fresh reviewers have three structural advantages.

They are not invested in the implementation

The builder's job is to complete the task. A reviewer's job is to challenge the claim that the task is complete.

That difference reduces confirmation bias. The reviewer does not need the architecture to be right. The evidence needs to be honest.

They bring different assumptions

A second agent may test a path the builder never considered.

That does not mean the second agent is always a better builder. It means the second agent approaches the system with a different internal model. Different assumptions expose different failure modes.

They review the complete system

Candidates naturally focus on the requested implementation.

Deep QA examines how that implementation interacts with the rest of the system:

  • Recovery
  • Resume behavior
  • Receipts and evidence
  • State transitions
  • External interfaces
  • Shipping
  • Failure handling
  • Existing policies
  • Previously verified behavior

Many serious defects live at those boundaries. They do not live inside the new function or module.

Fusion is not about writing twice as much code

Running multiple coding agents can produce substantial duplication.

Across the measured Fusion runs, about half of candidate work was not directly adopted into the final result. That sounds inefficient if the only goal is to preserve generated code.

Retained code is not the only useful output of a candidate.

An unselected implementation can still:

  • Expose a hidden assumption.
  • Demonstrate an alternative architecture.
  • Reveal an edge case.
  • Give the Jury a concrete comparison.
  • Supply one important safety mechanism.
  • Increase confidence that the selected approach was chosen deliberately.

The objective is not to preserve every candidate's code. The objective is to ship the strongest result with the strongest available evidence.

Use the right amount of Fusion

Not every change requires a full tournament.

The outcome surveys suggest a more economical approach based on risk.

Routine, low-risk changes

Use one strong builder with independent QA.

This works when the task is narrow, the behavior is well specified, and system-owned tests cover the important paths.

Ambiguous or moderately risky changes

Use two candidates and independent review.

This is valuable when multiple architectures are plausible or when a second perspective is likely to reveal assumptions hidden in the first implementation.

Trust-critical changes

Use the full tournament with deep QA.

This includes work involving verification, security, payments, recovery, permissions, evidence, receipts, shipping, or external publication.

In these areas, a polished implementation can be more dangerous than an obviously incomplete one. It may look ready while quietly weakening the system's guarantees.

The practical takeaway

Fusion's largest advantage is not that two agents can write twice as much code.

It is that the process separates building from believing.

One agent builds. Another independently challenges the reasoning. A Jury compares the evidence. An Integrator reconciles the strongest ideas. Deep QA attacks the finished result through paths the builders overlooked.

The builder can make the code green.

Fusion asks whether green is enough.

When software controls verification, recovery, security, or shipping, that distinction matters. It is the difference between code that looks finished and code that has earned the right to ship.

Source ledger

  • Fusion Outcome Survey portfolio, 21 usable surveys completed from June 30 through July 10, 2026.
  • FUS-355 required Build deep-QA tournament, including the selected-final deep audit and gate-integrity repair.
  • Fusion run lifecycle, the Gate, Jury, Integrator, QA Review, and QA Audit sequence.
  • Fusion MVP PRD, FR-19, FR-31, and FR-31a.