A Senior Asks Five Questions Before Reading Your Generated Patch

A generated patch rarely fails review because of formatting, naming, or even local correctness. It fails because the reviewer cannot reconstruct the failure it was meant to fix, the files it read, and the decision it quietly made. A senior engineer paired on such a patch will often ignore the diff for the first ten minutes and walk a fixed ladder of questions instead. Once those answers are written down, the patch becomes either clearly acceptable or clearly wrong, and the debate collapses into a record.

The ladder matters more than the lint

Lint, type checks, and unit tests answer questions about the code exactly as written. They say nothing about the reasoning that produced the change, which is where generated patches go wrong most often. A patch can pass every check and still edit a module nobody asked it to touch, or hard-code an assumption that only held inside the prompt. The review therefore needs two distinct gates: a mechanical gate for the artifact, and a conversational gate for the intent behind it.

The five questions, in order

1. Reproduction first. Can the failure be reproduced from a clean checkout without the patch? Acceptable evidence is a command, an exit code, and one log line. If the honest answer is "probably", the session ends before the diff is opened.
2. Read set second. Which files, tables, or endpoints does the patch read outside the module it edits? Acceptable evidence is a grep, a trace, or an explicit import list. This catches the most common dead end: a patch that solves the stated problem by reaching into three unrelated packages.
3. Contract third. Which existing behavior does the patch promise to preserve, and where is that promise tested? Acceptable evidence is the name of an existing test that still passes. Silence here usually means the patch is a rewrite wearing a bugfix costume.
4. Rollback fourth. If the patch turns out wrong in production, what single command or flag reverses it? Acceptable evidence is the revert path itself, not a plan to write one later.
5. Owner fifth. Who answers for this decision in six months, and where is that recorded? Acceptable evidence is a name plus a file, usually the same decision record the session produces.

Questions one and two eliminate most candidates within minutes. Questions three through five decide whether the survivor is mergeable today or needs a follow-up ticket instead.

Running the session as a reproducible artifact

1. Scaffold the session directory and freeze the candidate. Copy the patch and hash it, so the reviewed bytes cannot drift during the conversation.
2. Record the base revision. Without it, no later reader can tell which tree the patch was generated against.
3. Answer the ladder in a machine-readable file. Free text in a chat thread is not a decision record; JSON or YAML is.
4. Gate on completeness before anyone runs the tests. An unanswered question should stop the pipeline, not scroll past it.

# questions.yml - the ladder as data
- id: q1_repro
  text: "Can the failure be reproduced from a clean checkout without the patch?"
  evidence: "command + exit code + one log line"
- id: q2_readset
  text: "Which files or tables does the patch read outside the edited module?"
  evidence: "grep output or trace excerpt"
- id: q3_contract
  text: "Which existing behavior must be preserved, and which test proves it?"
  evidence: "existing test name + passing run"
- id: q4_rollback
  text: "What is the single command or flag that reverses this change?"
  evidence: "revert command, not a plan"
- id: q5_owner
  text: "Who owns this decision, and where is it recorded?"
  evidence: "name + decision file path"

#!/usr/bin/env bash
# review-session.sh <session-dir> <candidate.patch>
set -euo pipefail

SESSION_DIR="${1:?usage: review-session.sh <session-dir> <patch-file>}"
PATCH="${2:?usage: review-session.sh <session-dir> <patch-file>}"
mkdir -p "$SESSION_DIR"

cp "$PATCH" "$SESSION_DIR/candidate.patch"
sha256sum "$SESSION_DIR/candidate.patch" | awk '{print $1}' > "$SESSION_DIR/candidate.sha256"
git rev-parse HEAD > "$SESSION_DIR/base-rev.txt" 2>/dev/null || echo "no-repo" > "$SESSION_DIR/base-rev.txt"
printf '{}\n' > "$SESSION_DIR/answers.json"

cp questions.yml "$SESSION_DIR/questions.yml"
echo "session scaffolded at $SESSION_DIR"

#!/usr/bin/env bash
# gate.sh <session-dir> - blocks until every ladder entry has an answer
set -euo pipefail

SESSION_DIR="${1:?usage: gate.sh <session-dir>}"

jq -e 'all(.[]; (.answer | type) == "string" and (.answer | length) > 0)' \
  "$SESSION_DIR/answers.json" > /dev/null \
  || { echo "BLOCKED: unanswered question in the ladder"; exit 1; }

jq -r 'to_entries[] | "\(.key)\t\(.value.answer)\t\(.value.evidence)"' \
  "$SESSION_DIR/answers.json" > "$SESSION_DIR/decision.tsv"

echo "PASS: decision record written to $SESSION_DIR/decision.tsv"

The two scripts are deliberately boring, because the value is in the ordering. The hash pins the artifact, the base revision pins the context, and the gate refuses to let a partial conversation look like a completed review.

Where a free model and a free server fit

A candidate patch has to come from somewhere before the ladder can be applied to it. MonkeyCode offers free model access for producing that candidate and a free server option for running the reproduction in a disposable environment rather than on a reviewer's laptop. Disclosure: This article was prepared as part of MonkeyCode's product outreach. In this workflow the product participates in two narrow steps only: drafting the patch that the session will interrogate, and hosting the clean checkout where questions one and four get verified. Availability, allowances, and terms for both options can change, so confirm the current details on MonkeyCode's own documentation before depending on them for anything scheduled.

Keeping the reproduction off the reviewer's machine matters for a mundane reason. A clean checkout on a disposable host proves the failure exists without local caches, editor plugins, or half-installed dependencies. The session log then records a host and a revision instead of a workstation nobody else can reach.

The decision table the session produces

Limitations and who should not use this

This workflow assumes a repository with a reproducible entry point and at least one automated test that can run headlessly. It is poor value for typo fixes, dependency bumps, and one-line configuration changes, where the ladder costs more than the patch. Teams shipping one candidate patch per week will find the ten-to-fifteen minute session overhead hard to justify, and teams handling regulated data should confirm vendor terms and internal policy before pushing any source to a hosted free service.

The free server option is a disposable environment, and it should never hold production credentials, customer data, or long-lived secrets. The ladder also does not replace a security review, a license scan, or a human who understands the domain the patch touches. Treat the recorded decision file as evidence of process, not as proof of correctness.

Dead ends worth naming

The most expensive dead end is a patch that reproduces the failure only after an uncommitted local edit, because question one then has no clean answer. The second is a read set discovered after the merge, which usually appears as a surprise import in a diff nobody re-reads. Both are cheap to catch at the start of a session and expensive to catch three weeks later during an incident review.

If a team wants to try the pattern without provisioning anything, the free model access and free server option through MonkeyCode are a reasonable place to run one session end to end and see whether the ladder earns its keep.