Reference

How to review code

As assistants write more of the first draft, the job shifts from writing to checking. The reviewer’s one rule: never trust “it’s done” — run the edge test. Here are the moves the lab drills. Open the review lab →

• Read the spec first

  You can’t review code against nothing. Know exactly what it must do — including what it must do at the edges (empty, zero, the boundary) — before you read a line.

• Never trust “it’s done”

  A confident assistant is not a correct one. The research is blunt: an AI that hands over answers raises your confidence and lowers your learning. Verify, don’t trust.

• Test the EDGE, not the happy path

  A typical input often passes even on buggy code. The bug lives at the edge: the empty list, the zero denominator, all-negative numbers, an index past the end. Pick the test that hits it.

• A failing test names the bug

  When your chosen test prints the wrong thing (or crashes), you’ve found a real defect — now trace it to the one line that causes it.

• Request changes with a specific comment

  A useful review comment says WHAT is wrong and WHERE — “add the empty-list guard before dividing”, not “looks buggy”.

• Re-run your test on the fix

  A change isn’t done because it was made — it’s done when your test passes. Re-run the same edge test on the revision and confirm it’s green.

The edges a good test hits

• Empty listDoes it handle []? (loops that never run, count = 0, dividing by count)
• ZeroA zero denominator crashes; a zero starting value can win a max/min it shouldn’t.
• Negative numbersA max that starts at 0 fails when everything is negative.
• The boundaryOff-by-one: is it < n or <= n? ..< or ...? First and last positions.
• One itemLists of length 1 catch loops that assume “at least two”.

Auto is deterministic — a fixed, rule-based assistant, not a live model, so nothing you review leaves your device. The code is a teaching subset of the Swift language. Review a case →