If an agent writes the code, another reviews it, and a third deploys it - who reads it? It depends on what you mean by "read."

What does not work

The naive approach skips human review and trusts the agent's own tests. Agents write tests that pass, not tests that catch their own mistakes: a buggy function comes with a test validating the bug.

The other extreme - a human reads every line - scales poorly. At 500 lines per PR, the human is the bottleneck: the agent has not saved time, only changed who does the typing.

What works

The correction loop changes the risk calculation:

An agent produces a change and opens a PR.
Deterministic gates check the diff for secrets, schema violations, and quality thresholds.
If a gate catches a problem, a new run starts with the gate's evidence as context; the agent fixes it and produces a new diff.
The original PR stays as it was - the audit trail records both the failure and the fix.
Only after all gates pass does the PR reach a human reviewer.

The human reads the gate evidence and diff summary instead of every line, shifting from "find the bug" to "does this change make sense at the design level?"

How Farna Control handles this

Farna Control's correction loop does this: when a gate catches a problem, a new run starts with the feedback attached, and the original stays as evidence. The reviewer sees the gate results, the original output, and the corrected output, then decides whether the design is right. Farna Control lets you set which change classes are safe to auto-merge, and an agent never approves its own block-level changes - a separate reviewer or a human must clear them.

We run our own delivery on Farna Control, and the numbers are public.

The principles behind this: correction never rewrites history - a failed output produces a new run with feedback attached, and the original stays as it was - and deterministic gates catch failures before they reach a human reviewer.