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 →
Where this idea comes from
Eyes and edges: how code gets checked
In 1976 Michael Fagan at IBM published a method for code inspections: a small team reads the code together, with set roles and a checklist, before it is ever run. He reported it caught most errors far earlier than testing did.
One thing to hold: Heartbleed: a missing length check in the OpenSSL library’s heartbeat feature. It was added in a release in March 2012 and found in April 2014, in code that much of the internet relied on and that others had read.
Why it matters: Reading code finds faults that tests never try, but only if the reader tries the edges: the empty input, the huge one, the length that lies. Heartbleed was exactly that kind of edge.
What we don’t know: “Given enough eyeballs, all bugs are shallow” was named Linus’s law by Eric S. Raymond (The Cathedral and the Bazaar, 1999) after Linus Torvalds. Heartbleed is often given as the case against it; others answer that too few people were actually reading OpenSSL.
Dates:
- 1976 Fagan publishes IBM’s code-inspection method.
- 1997 Raymond’s essay The Cathedral and the Bazaar names “Linus’s law” (a book in 1999).
- 2012 The heartbeat bug ships in OpenSSL 1.0.1.
- 2014 Heartbleed is found and made public.