One validation rule, a visible diff, and enough evidence to make an acceptance decision.
The importer needed to reject a blank SKU. The proposed fix also cleaned up the names, changed the order of the results, and introduced a shared validation class. That is a plausible AI coding exchange, not a report from a production system. The useful question is what the maintainer should accept when the requested repair arrives attached to three other decisions.
“Make the patch smaller” is a start, but it leaves the assistant to decide what small means. Ten changed lines can alter a public interface. Fifty lines of fixtures can make a one-line repair easier to judge. The unit worth bounding is the behavior: one thing should change, with enough evidence to show which neighboring things did not.
Google’s code review guidance describes a small change as self-contained and focused on one thing, including its related tests. It also warns against making a change so small that its implications become hard to understand. That is a useful distinction for AI-assisted work. The goal is a review a person can finish with a decision, rather than a diff that happens to fit on one screen.
Consider a deliberately small inventory importer. It accepts rows containing a string SKU and a quantity, visits them in their supplied order, and returns accepted rows alongside row-numbered errors. It does not parse a CSV file, connect to a database, or write inventory. Those boundaries matter because this example can show a validation repair without pretending to prove the behavior of an entire import service.
Its initial SKU predicate is return value != “”. An empty string fails, but a string containing two spaces passes. The requested rule is that a SKU must contain a non-whitespace character. Valid rows must retain their original values and order, while a rejected row must produce the existing message: “SKU must contain a non-whitespace character.”
A bounded request can state all of that in ordinary language. Change only the SKU predicate in the importer; use the supplied fixture and expected output; preserve the output shape, ordering, quantities, and accepted SKU strings. Return the diff and the focused check results. If the repair requires a broader interface or storage change, stop and explain the dependency before implementing it.
The last sentence gives the assistant somewhere to put a discovery. Perhaps the real code handles missing columns before validation, or another caller sends a non-string value. Those findings deserve attention. They do not automatically authorize the assistant to redefine every caller while fixing the blank-string case. The maintainer needs to choose whether the larger problem belongs in this patch or in a separately scoped change.
For the disposable example, the patch changes the predicate to return bool(value.strip()). Python documents that calling strip without an argument removes leading and trailing whitespace from a copy of the string. Testing whether that copy is nonempty implements the stated rule for the string inputs in this example. It does not assign the stripped result back to the row.
That distinction carries the most interesting acceptance condition. The SKU B-202, with a space at either end, should still appear with those spaces in the accepted output. Rejecting an identifier made entirely of whitespace and normalizing an identifier are different changes. A reviewer who approves the former has not necessarily approved the latter, even if trimming looks like a helpful cleanup.
The fixture contains five rows in order: A-101, an empty SKU, a two-space SKU, B-202, and C-303. Their quantities are two through six. The expected result keeps the first, fourth, and fifth rows exactly as supplied, with errors attached to rows two and three. This makes the changed disposition visible without treating every output difference as an improvement.
A local Python 3.12.10 run of this synthetic example produced the expected contrast. Before the patch, the two-space row was accepted. After the patch, it produced the specified error, and the accepted rows matched the expected values and order. Five focused checks passed after the change; three passed before it. The two baseline failures were whitespace rejection and equality with the complete expected output.
Those checks are intentionally modest. Complete-output equality checks the fixture’s fields, values, and sequence, while the narrower checks make an individual failure easier to locate. This is evidence about five synthetic rows and a string-only predicate, not a performance result, a model comparison, or proof that an existing importer is safe to deploy. A real repository needs its own relevant checks and its actual callers inspected.
The diff still deserves a separate reading. In this example, the implementation diff contains only the predicate replacement; the row loop, error message, and output construction stay as they were. In a working repository, begin with the list of changed files, then read the changes in the allowed files. A successful test command does not explain why a dependency file or a storage adapter appeared in a validation repair.
A useful small-patch review card can fit into the change description. Write the requested behavior, the allowed files, the behavior that must remain unchanged, the fixture and expected result, and the command that checks them. Add the exact revision reviewed and the person who decides whether it is accepted. That last pair prevents an approval of one candidate from quietly becoming an approval of the next candidate too.
The before-and-after fixtures belong beside that card. Keep the input and expected output fixed while comparing both implementations, and retain the actual outputs rather than reporting only a green result. If the assistant changes the expected result during the repair, that is another decision to review. A passing check is only useful when its definition of passing still matches the task.
This does not mean rejecting every extra line. A regression test for the new rule belongs with the repair, and a necessary change at a caller may belong there too. The author should explain that connection in terms the reviewer can follow. An unrelated rename or a new validation framework can wait for a patch whose stated purpose makes those decisions reviewable on their own.
The maintainer now has a concrete choice. Accept the bounded repair after the repository’s required checks and review, ask for a correction when the stated behavior fails, or request a separate proposal when the assistant has found a larger design problem. The patch earns acceptance by showing the requested change and respecting the behavior around it. Give the assistant one repair to make, and give the reviewer enough evidence to decide whether that repair is the one that arrived.
Use Google’s guide to small changes to scope your next repair around one behavior and the evidence needed to review it.
If this was useful, forward it to one engineer who needs less noise in their feed.