← Blog

The Writer Never Approves

I keep a rule in my own operating instructions that names this failure by an incident rather than a principle. On 2026-08-13, the orchestrating agent in one of my sessions wrote roughly 2,968 lines of code directly, across eight files, in a single session — then reviewed its own output. A bug in its own formatting checker survived that review. It was caught only when a separate subagent, working downstream, refused to route around it.

writes work reviews own work approves blind spot closes the loop different reviewer can expose the defect
Self-review can approve a belief formed during writing; an independent reviewer supplies the missing frame.

What happened on 2026-08-13

The files were real infrastructure, not boilerplate: block_ledger.py (480 lines), test_r11_requirement_coverage.py (545 lines), watchdog_liveness.py (410 lines), test_block_persistence.py (451 lines), and four more. The orchestrator — the role in my setup meant to plan, decompose work, dispatch it to other agents, and validate what comes back — wrote all of it itself instead of delegating.

The stated reason was that delegation was unavailable: the harness the orchestrator was running in has a default that says not to spawn sub-agents unless the user explicitly asks for it, and the orchestrator read that default as meaning delegation could not happen at all.

The justification, and why it was false

That reasoning doesn't survive what happened next. Later in the same project, the operator said, in effect, "use your subagents" — and four Sonnet agents spawned immediately and did the work. Nothing about the harness had changed between the two moments. What changed was that the orchestrator stopped treating a default-off setting as a hard constraint.

A harness default being off is not proof that a capability is unavailable. The only honest basis for that claim is a probe with a recorded result. An unrun probe is an assumption wearing the shape of a conclusion.

What self-review missed

Why can't an AI agent reliably review its own code?

Because a reviewer checking its own work is judging that work against a belief it just formed while writing it — there's no independent frame left to check it against. The incentives point the same way too: momentum, confidence, and the wish to be finished all push toward approving what you just built, not questioning it.

The bug surfaced only when a different subagent, downstream, hit the broken checker and refused to work around it — refused to quietly route past the failure and report success anyway. That refusal is the mechanism working as intended, just one step later than it should have. It caught the defect because a second, independent agent happened to be in the loop at all, not because the original review was thorough. If the orchestrator's output had never reached another agent, the bug would have shipped believed-correct.

The mechanism now in place

How do you structure code review across multiple AI models?

Separate the writer from the approver by construction: the model or agent that produced the code is never the one that signs off on it. Route the work to a different model running as its own agent, with no stake in defending a draft it didn't write, and restrict the original author's role to planning, dispatching, and validating what comes back rather than approving its own output.

The fix was a role lock: the orchestrator plans, decomposes, dispatches, validates, and handles git and deploys. Substantial writing is delegated to a separate agent that did not produce the draft it reviews.

orchestrator plan · dispatch · validate writer produce the work reviewer inspect · approve may not write substantial work may not approve its own work may not rewrite the draft before review failure claim requires a probe and recorded result No silent assumption becomes a permission to write.
Role separation makes the prohibition explicit: the producer cannot be the approver, and an unavailable capability must be tested.

This is the same shape as the control I rely on for issue closure across the rest of the operation:

557closed issues in the ledger
544name a verifier different from the fixer
0self-verified

The other half of the fix is about the justification, not just the review. "Delegation is unavailable" now has to mean an attempt was actually made and failed — a probe with a recorded result — not an inference drawn from a setting being off. If delegation is genuinely blocked, the rule is to say so and ask before writing thousands of lines directly, not to assume and proceed.

What to copy

Pair that with a second discipline: before you claim a capability was unavailable, run the check that would prove it. An assumption you didn't test isn't a fact you're allowed to act on. It's a guess that hasn't been challenged yet — and the review that would have challenged it is exactly the one a self-approving process never runs.

Meharban Singh

Meharban Singh

AI systems / delivery architect. I build software with AI agents governed by rules, hooks, gates and independent review — and watch it in production after go-live.