Why Coding Agents Need Review as Control Flow

Coding agents become more useful when they can do more than produce a patch. They also become riskier when a plausible patch can advance without an equally capable system for challenging it.

The answer is not simply “add code review.” In an agentic software-development lifecycle, review must be able to block work, redirect it, require repair, and repeat until the relevant evidence supports progression. Review is not a comment added after generation. It is control flow.

This distinction mattered in Chrysent’s work on sandboxctl, a security-sensitive Rust CLI for managing Kubernetes sandbox namespaces. Its implementation repeatedly moved through bounded implementation, specialist review, must-fix findings, focused repair, and re-review. Verification ultimately consumed more measured subagent compute than generation, while review findings changed authorization, evidence, identity, network, cleanup, and live-acceptance behavior.

Evidence boundary: Measurements in this article describe one instrumented OPI implementation worktree. Launch counts are launches, not unique agents, people, or models. The figures and finding summaries come from Chrysent’s internal OPI and sandboxctl delivery, adversarial-review, validation, and evidence report, version 2.0, dated August 8, 2026. They should not be generalized into a universal benchmark. Product-status disclosure: OPI Forge is in private beta. This article documents an internal delivery case study; it does not announce general OPI Forge availability.

Code generation is not software delivery

Generating code is an event. Software delivery is a sequence of decisions about whether that code is correct, secure, operable, and sufficiently evidenced to move closer to release.

Those decisions become harder as agents take on larger scopes. A change may compile while violating an authorization boundary. It may pass unit tests while failing open during an API error. It may report success after incomplete cleanup. It may even produce structured evidence without proving the condition that evidence claims to establish.

Final-only review concentrates too much uncertainty into one late checkpoint. By then, design choices may be entangled across implementation, tests, documentation, and operational behavior. A reviewer can identify a problem, but the workflow may still allow the authoring agent to reinterpret the concern, make a broad repair, or declare it closed without targeted verification.

A governed agentic SDLC needs explicit review states that determine what may happen next.

Review verdicts should change the next execution step

In the recorded OPI workflow, verdicts such as pass, complete, must-fix, and defer were not retrospective labels. They influenced progression.

The critical transition is must-fix. It prevents generated output from being treated as accepted merely because the authoring agent finished.

It also creates a retention requirement. A blocking finding needs a stable identity, an affected scope, a repair target, and closure evidence. Otherwise, the concern can disappear during parallel work, context compaction, or a later rewrite.

What a review-heavy implementation looked like

The sandboxctl implementation worktree recorded 466 timed launches: 454 completed and 12 failed. It recorded 2,094.3 minutes of summed subagent compute over a 2,441.6-minute wall-clock span.

Verification was the largest measured compute category in this worktree. The role distribution shows why “an AI reviewer” is too broad a category:

These figures are not a quality score, and the launches do not represent unique people or agents. They reveal an operating model in which implementation was repeatedly challenged from different perspectives.

One reviewer is not enough

Complex defects rarely fit one discipline.

A code reviewer may find a broken state transition. QA may notice that the same transition can still produce a false PASS. Security may find that an untrusted input can influence it. A Kubernetes reviewer may recognize that the assumed API behavior does not match how a controller behaves.

That pattern appeared throughout sandboxctl. Review was separated by the kinds of failure the system needed to detect: Rust correctness, adversarial security, test completeness, Kubernetes semantics, operational recovery, evidence integrity, and specification authority.

Review should be divided by failure class—not merely multiplied by reviewer count.

This matters for coding agents because generated code can be locally plausible while violating an obligation stored elsewhere in a specification, threat model, cluster contract, or evidence protocol.

Six times review changed the product

The strongest evidence for review as control flow is the difference between the implementation before and after a blocking finding.

1. Authorization could fail open

sandboxctl used operation-scoped Kubernetes SelfSubjectAccessReview checks to determine whether the current identity held the exact permissions required for an operation.

Security review found that an evaluationError path could fail open: a problem evaluating authorization could be treated too permissively instead of stopping the operation. The finding blocked progression. The authorization catalogs and error behavior were repaired, then passed focused security and technical re-review.

The broader rule is straightforward: when an authorization system cannot determine whether an action is allowed, review must test the error semantics—not only normal allow and deny responses.

2. Failed evidence could still produce PASS

The project connected accepted requirements, mappings, tests, and evidence through a traceability model. QA found that failed RB-05 evidence could still yield a traceability PASS.

That is a serious risk for AI-generated software: a system can appear governed because it produces structured evidence while its reporting logic overstates what was proved. The false-PASS path was repaired and rerun through QA, security, code, and technical review.

Evidence machinery needs the same adversarial scrutiny as product code. A green report matters only when the reporting path is fail-closed.

3. Duplicate evidence could mint mutation authority

The implementation introduced an opaque WritePermit so read-only inspection remained separate from authorized mutation. A permit was intended to exist only after exact prerequisites, authorization checks, and mutation targets had been validated.

QA found that a duplicate prerequisite report could still mint a permit. The repair rejected duplicate reports and strengthened binding between the permit, approved plan, and exact mutation targets. Focused review then verified the trust chain.

Evidence should not merely accompany authority. It must be structurally bound to the exact action it authorizes.

4. Credential publication was not crash-atomic

The identity flow wrote user credentials and kubeconfig artifacts. Review found that metadata failure could leave partial artifacts, crash states could expose an incomplete identity set, and certificate data used DER where Kubernetes clients expected PEM.

Different reviewers exposed different dimensions: partial publication, failure-matrix coverage, format compatibility, and credential-boundary safety. The implementation moved toward crash-atomic directory exchange, strict parsing, deterministic recovery behavior, and exact encoding.

“The credential command works” was not one question. It was a set of questions about correctness, compatibility, secrecy, atomicity, concurrency, and recovery.

5. Deletion and cleanup could overstate the final state

Review found that a network-exception removal path did not enforce its delete precondition. Later, the live harness could also report exact cleanup when collision handling or absence verification was incomplete.

A delete request is not proof that an object is gone. A failed command is not proof that rollback succeeded. A cleanup script completing is not proof that every named temporary resource is absent.

The repairs strengthened delete preconditions, collision refusal, phase-selective cleanup accounting, and final exact absence checks. The project then reran the local gate and live acceptance after the final harness changes.

6. An HTTP 503 was not proof of policy denial

The live harness needed to show that removing a network exception caused the expected Gateway-to-backend denial. A weak negative test could have accepted any failed request, even though a 503 might also come from a broken backend, stale route, replaced Service, transport problem, or unrelated cluster failure.

The review loop required more than the response code. The final check also corroborated that the exact exception policy was absent, the managed-policy inventory was empty, the backend remained current and ready, the Gateway and HTTPRoute remained accepted, and the generated Service retained the frozen UID and NodePort.

That converted a generic negative observation into a causal argument: the request was denied after policy removal while the surrounding route, backend, and Service identity remained healthy and stable.

An observed failure is not automatically proof of the cause a test hoped to exercise. The evidence must rule out realistic alternatives.

Focused re-review closes the loop

A blocking finding should not disappear into a broad rewrite. The repair should return to the reviewer whose concern defined the failure: security findings to security review, Kubernetes semantic issues to technical review, and false-PASS paths to QA. Cross-cutting repairs should then run through broader integration gates.

This avoids self-certification, where the repairing agent declares its own work resolved, and scope drift, where a large repair closes one issue but introduces unreviewed behavior elsewhere.

The recurring pattern in the sandboxctl worktree was must-fix → repair → focused re-review → pass. A coder’s completion message was not treated as closure evidence.

A reusable design for coding-agent review gates

Teams do not need to reproduce the exact role counts from this case study. They do need a control model with the same properties.

The important choice is not how many agents participate. It is whether the workflow can prevent unsupported progression.

What this process does not prove

Review-heavy delivery is not perfect assurance. The recorded process does not establish that every defect was found, and it does not replace an independent red team, penetration test, or third-party security audit. Its role counts and compute shares describe one OPI worktree, not a universal optimum.

The repository also retained two unresolved operator-authorization artifacts: an exact compliant ClusterRole/sandboxctl-operator manifest and its complete manual installation procedure. It therefore did not claim repository-wide specification parity.

The committed validation record reports that all seven local-gate commands passed, 416 Rust tests passed, and the default all-phase reference-cluster run completed with cleanup and final exact absence checks. Those live results remain repository-reported in the source analysis because the private raw run directory was not attached for independent inspection.

Preserving these limits is part of credible governance. A review system must retain unresolved work and evidence boundaries instead of smoothing them into a stronger claim.

Review must be allowed to say “not yet”

Coding agents are often judged by how quickly they produce something plausible. For systems involving authorization, credentials, infrastructure, policy, or operational state, the more consequential question is whether the delivery process can recognize when plausible output is not yet acceptable—and turn that finding into the next required action.

Review as control flow gives specialists the authority to block. It gives repairs a defined destination, evidence a scope, and unresolved risks a durable place to remain visible. It prevents “the agent finished” from becoming a substitute for “the work is ready.”

That is the difference between generating code and governing change.

For the broader design argument, read Beyond PRDs: Building an Adaptive AI Software Factory.