# 2 · Read: run it, and look for harm before style You will notice style first, because it's on every line and it's easy to name. Bugs are in a few lines, and you only see them if you're looking for them. This step is about where to look, in what order, and how to know rather than guess. On a small change: ask the D2 questions, run the tests (D3), check D4 for the one or two things that apply. Skip the reading order and the AI-code section unless something looks off. --- > **In ihumane Pro** (https://ihumane.ai/#pricing): > - D1 · Read in an order that explains the change ### D2 · Harm first, style last **Rule:** Go through the change asking these questions, in this order, and spend most of your time on the first five: 1. **Data:** can this lose, corrupt or leak stored data? (A delete or update without the right filter, a migration with no way back, a write that can half-finish.) 2. **Security:** can someone see or do what they shouldn't? (A permission check removed or loosened, input that builds a query, command, path or HTML: Code craft C9, a secret in code: C8.) 3. **Correctness:** does it do what the intent (I1) says, for every input that can reach it? (Off by one, wrong condition, the empty case, two requests at once.) 4. **Users:** does behaviour change for people who didn't ask for it? (A default changed, an error message gone, a page slower, a setting reset.) 5. **Other code:** does anything else break? (A changed function, export, response shape, event or column: D5.) 6. Then performance, then readability and structure (Code craft S1 to S8), then naming and style, only where the project's rules say so (I4). **Why:** The author can fix a name in ten seconds after merge. Lost customer data can't be fixed at all. A review's value is almost entirely in the first five questions, and those are the ones that need you to think rather than notice. **Agent trap:** "Consider renaming `d` to `discount`", "Nit: trailing comma", "Could use optional chaining here", and nothing about `await db.orders.deleteMany({ status })` where `status` can be `undefined`, which matches every order. **Check:** for each of questions 1 to 5, you can say either what you found or "checked, nothing found" and how you checked. If your comments are mostly style, go back through 1 to 5 before posting. ### D3 · Run it; don't review by eye **Rule:** Get the change running before you judge it. Check out the branch (or apply the diff), install, and run the project's tests, build and type checker (Code craft B4). Look at the CI results if there are any, and read the failures, not only the colour. For a bug fix, make the bug happen on the main branch and check it's gone on this one. For new behaviour, call it once the way a user or caller would. If you can't run it (no access, no environment, secrets you don't have), say so in the first line of your summary. **Why:** Reading code tells you what it seems to do. Running it tells you what it does. The author already believes it works; your review is useful when it adds evidence they didn't have, and a review that ran nothing adds none. **Agent trap:** "LGTM, the logic looks correct" on a change whose tests fail on CI with an import error, because you read the diff and never opened the checks. Or trusting a green CI run that only lints, with no tests in it. **Check:** your summary lists each command you ran and what it showed, and says "not run" for anything you didn't. For a bug fix: you saw it fail before and pass after, or you say you didn't. **Limit:** a copy change or a one-line config change may not need the app started. It still needs the build and tests, or a line saying why you skipped them. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - D4 · Look for what's missing > - D5 · Follow every changed interface outside the diff > - D6 · A diff too big to review well: say so ## Code an agent wrote More and more changes are written partly or wholly by agents, sometimes by you. It fails in its own ways: it looks finished, it's consistent with itself, and it can be confidently wrong. If the description, the commit messages or the style suggest an agent wrote it, or you're not sure, read it with D7 to D9 as well. Don't accuse anyone: these are checks, not verdicts. > **In ihumane Pro** (https://ihumane.ai/#pricing): > - D7 · Check every unfamiliar call exists and does what the code assumes > - D8 · Check the tests can fail > - D9 · Look for the helper that already existed and the layer nobody needed