Design the Hand-Back: Let Reviewers Return Agent Work Instead of Quietly Fixing It

A teammate runs a coding agent on a ticket. The diff is almost right — the logic works, but the error handling is thin and it silently drops a retry path. The fastest move is to fix it themselves. So they do. Thirty seconds of typing, one commit, done.

That tiny decision is consequential, and most AI coding interfaces make it the only move available. The reviewer is the decision owner. The consequence is real: the agent's failure pattern is never recorded, the prompt or context that produced it is never corrected, and the next run repeats the same mistake. Worst of all, this decision is irreversible in the record — the version history shows a clean fix, not a rejected agent attempt. The system just learned nothing.

This article is about designing the alternative: a hand-back, where the reviewer's first-class action is returning the work to the agent with the rejection attached, not patching it silently. I'll give you a hand-back review card you can implement as a structured template, a decision table for when hand-back beats direct repair, a research protocol with stop conditions, and an accessibility review. You can prototype the whole loop cheaply using free model access and a free server — I'll show exactly where that fits.

Why silent repair is the wrong default

Silent repair optimizes for the moment and taxes the system:

1. The failure evidence is discarded. The reviewer just demonstrated, in edits, exactly what the agent got wrong. That is the highest-signal feedback the system will ever receive — and it evaporates.
2. The reviewer becomes an unpaid ghost-worker. Over time, teams report "the agent is great" while their seniors quietly absorb a correction tax on every diff.
3. The decision owner disappears. When the patched code later breaks, the commit blames the human, but the defect originated in the agent's behavior. Nobody can reconstruct that.

The design fix is not "ask reviewers to write more comments." It's to make the hand-back a structured, one-screen action that is less effort than fixing the code.

The hand-back review card

Here is the pattern. When a reviewer rejects agent output, they don't open the file — they fill a small card. Proposed fields:

## Hand-Back Card
- Rejection reason (pick one):
  [ ] Wrong approach        [ ] Missing case        [ ] Style/convention
  [ ] Safety or side effect [ ] Unverifiable claim
- Where it failed (anchor): <file:line or quoted snippet>
- Evidence I saw: <what made me reject — a test run, a spec line, my own knowledge>
- Constraint for the retry: <one sentence the next attempt must satisfy>
- Retry scope: [ ] Retry this file only  [ ] Retry with new context  [ ] Escalate to me

Three design decisions matter here:

• The constraint field is mandatory, free text, one line. It forces the reviewer to convert "this feels off" into an executable instruction. If they can't, that's a signal the task was under-specified, not that the agent failed.
• The retry-scope selector prevents the most common failure of auto-retry: looping. "Retry with new context" requires the reviewer to attach something (a test failure, a spec excerpt) before the agent may run again. No new evidence, no retry.
• The card is the commit. The rejected agent output, the card, and the eventual accepted version are stored as one unit in the review record. The discarded information stays in the concrete record — nothing evaporates.

A compact decision table for reviewers:

Situation	Fix it myself	Hand back with card	Escalate / stop
Typo-level error, one line, unambiguous	✅
Missing edge case I can name in one sentence		✅
I can't articulate what's wrong in one sentence			✅ task is under-specified
Error touches auth, data loss, or billing paths			✅ never silent-fix, never auto-retry
Second rejection of the same retry			✅ stop condition hit

The hand-back flow, end to end

Agent produces diff
      │
      ▼
Reviewer opens review card (evidence attached: diff, agent's stated plan, tool log)
      │
      ├── Accept ──────────────► merge, card archived as "accepted, no corrections"
      ├── Hand back ───────────► card + constraint go to agent, ONE retry allowed,
      │                          requires new evidence if scope = "new context"
      │                                │
      │                                ▼
      │                     Retry accepted? ──no──► STOP: escalate to human,
      │                          │                  agent locked out of this ticket
      ▼                          yes
  Escalate/stop ◄───────────────────────┘

The stop condition is the load-bearing piece: exactly one automatic retry, then the agent is locked out and the ticket returns to a human. Without it, "hand-back" becomes "infinite free labor for the agent's learning curve, billed to the reviewer."

Prototyping this cheaply — where free models and a free server fit

The reason teams don't build review loops like this is rarely design disagreement — it's that testing a rejection-and-retry workflow burns paid tokens on deliberately bad output, and someone has to host the orchestration.

Disclosure: This article was prepared as part of MonkeyCode's product outreach.

This is one place where MonkeyCode's free model access and free server option are genuinely useful to the method rather than incidental: you can run the full loop — generate, review, reject with a card, single retry, stop — against free models, and host the small card-collecting service (the template above plus a couple of endpoints) on the free server option, without spending anything while you validate the pattern. The workflow looks like:

1. Seed 8–12 real tickets from your tracker, including at least three you expect the agent to fail.
2. Run the agent. Route every output through the hand-back card, not through your editor.
3. Measure: how often does the one-line constraint produce an acceptable retry? How often is the stop condition hit? How long does card-filling take versus silent repair?
4. Keep the full record — rejected attempts, cards, retries — as your evidence base for whether to adopt the loop on paid models.

If this is useful, the natural next step is to try the same loop against your own backlog and see whether your retry-accept rate justifies the pattern; the prototype is deliberately cheap enough to abandon.

Honest limitations. Free model tiers are the right place to test the workflow, not to benchmark model quality — don't generalize "the retry failed" from a free tier to a frontier model. Card fatigue is real: if filling the card takes longer than fixing the code, reviewers will route around it, which is exactly the silent-repair failure again. And this pattern does not belong on irreversible paths (migrations, secrets, external side effects) — there, rejection should stop the pipeline, not trigger any retry.

Research protocol: does hand-back actually help reviewers?

A proposal is not a finding. Before rolling this out, run a small scenario-based study:

• Participants: 6–8 reviewers who already review agent output. Scenario: each reviews 4 agent diffs — two designed to be acceptable, two seeded with a missing-edge-case failure — half via silent repair, half via the card, order counterbalanced.
• Success measures: time-to-resolution, whether the retry's constraint was reused or rewritten, reviewer-rated confidence in the final diff, and whether the failure evidence survives in the record.
• Stop measures (pre-registered): if card-filling exceeds silent-repair time by more than ~2×, or if reviewers skip the constraint field in more than a third of hand-backs, stop and redesign the card before touching the model.
• Accessibility review: the card must be fully keyboard-operable (the reason-picker and scope selector are native radio groups, not custom widgets); rejection reasons need visible labels, not icon-only buttons; the retry-scope state change must be announced to screen readers; and "Escalate" must be reachable without passing through "Retry" — tab order is a safety property here.

Separate what the study establishes (evidence) from what I asserted above (design hypotheses). The card's field set, the one-retry limit, and the decision table are hypotheses until your reviewers touch them.

The point

Every team adopting coding agents is building a review culture whether they design one or not. Silent repair builds a culture where agent failures are invisible and senior reviewers absorb the cost. A hand-back card, a hard stop condition, and a record that keeps the rejected work build a culture where the system is accountable for what it got wrong — and where the human's one-line constraint is treated as the valuable artifact it is.

Ask, before your next agent rollout: which missing evidence should stop a retry, and which extra field on the card would only add noise? If you can't answer, that's the design work to do first.