Agents Grade Their Own Homework. That’s Broken.

We would not design a production release process around one person who implements the change, decides what the acceptance test should be, explains the result, and signs their own exception. Yet that is the default loop for many coding agents: write, test, summarize, declare victory. It works often enough to feel normal—until it fails in the quiet way that looks complete right up to the moment it matters.

The missing “tell” in agent work

Humans have always graded their own homework badly. We become attached to an interpretation, rush through the test plan, and see what we expected to see. But human work has visible signals: hesitation in a review, an unfamiliar tone in a handoff, a teammate saying “can you sanity-check this?” Agents remove those tells. The final response can be equally polished whether the change was carefully verified or merely plausible. In fact, the more fluent the agent is, the easier it is to confuse a good explanation with a good result.

That makes “the agent ran tests” a strangely incomplete control. Which tests? Chosen against which interpretation? Did the test demonstrate the behavior users care about, or merely confirm that the new function returns the value the agent expected? Did the test suite pass because the agent fixed the bug, or because it never reached the real code path? The agent might answer each question honestly and still never ask it without a role whose job is to ask from outside the original frame.

More agents is not the answer

The obvious reaction is to spin up a reviewer, a tester, a planner, a fixer, and a manager until the architecture looks like an org chart. That usually creates a different failure: context gets diluted, every worker emits commentary, and a human becomes the integration layer. An agent swarm is not a separation-of-duties strategy. It is often a way to make the same confused assumption arrive in five different message formats.

The useful split is smaller. Keep one strong primary agent responsible for the task. Give the verifier a narrow job: reconstruct the change, attempt to falsify the finish claim, preserve the evidence, and return a clear result. If it finds a real defect, a repairer may prepare the smallest allowed patch. Then a fresh verifier checks that repair before anything is applied. Each role has a success criterion that would be awkward for the author to grade alone.

What actually breaks the loop

Independence is not a magic word. Using a different model does not erase correlated failures if both systems share the same incomplete requirements, repository state, or weak test environment. The practical goal is a different vantage point and a different final object. The author asks, “Did I implement what I understood?” The verifier asks, “What would show that this claim is wrong?” The author reports a summary. The verifier returns evidence and limits. That change in incentives is the value.

Critique implements this as a finish handoff. The primary agent calls critique finish from the worktree it just changed. Critique reconstructs the change in disposable workspaces and tries consequential hypotheses. It can use local development or test environment files during local validation without adding those files to patches, proof artifacts, or cloud uploads. The output is JSON with an outcome, issue list, changed paths, artifacts, limits, usage, and a stable exit code. The primary agent remains the one that tells the user what happened next.

The repair boundary matters as much as the review

A bad review system gives you a warning and makes the human or original agent reconstruct the fix from scratch. A bad repair system gives a new agent broad write access and then accepts its own patch. The useful middle ground is a bounded repair contract. Critique supports no repair, a repair pack, or repair apply. In the apply path, a patch is only returned to the original working tree after a fresh verification workspace has approved it. The verifier’s job is not to own the repo; it is to make the next move smaller and better evidenced.

How to adopt this without slowing everything down

The standard should be simple

Coding agents will keep getting better at writing and narrating code. That makes a strong completion boundary more important, not less. The standard is not “never trust an agent.” It is “do not let the same agent be the only author of its own proof.” Give the primary agent a verifier it can call without losing the session, ask that verifier to show its work, and make uncertainty an acceptable output. That is enough structure to improve the loop without turning software delivery into process theatre.