Human Review: A Person Reads It Before It Goes In

Step 6 of 7.

The branch has code, tests and an AI review. Nothing has left your machine. Now a person reads it, and only after a person approves does it go any further. This is the step that nothing else replaces.

Our goal: know why a person reads and approves every change, what to look for that the AI is likely to miss, and what happens after approval.

Here is the route:

1. How a team does it: the author reads their own work, then a teammate.
2. Why an AI does not change that.
3. What to read, in what order.
4. What to look for.
5. Approve, or send it back.
6. Push and open the pull request.

We leave out the details of any one hosting service's review screens, since they differ.

How a team does it

On a good team, no change goes in because its author says it is fine. The author first reads their own change, line by line, as if someone else had written it. Then they ask a teammate to read it too. The teammate asks questions, and the author answers or fixes. Only then does it merge.

The point is ownership. Whoever's name is on the change owns it. "It came from the tool" is not an answer to "why did you put this in?", just as "I copied it from the internet" never was.

Why an AI does not change that

An AI wrote the code and another pass reviewed it, so it may seem the reading is already done. It is not, for three reasons.

• It only knows what was written down. It checks the code against the spec, and a spec can be wrong. Only a person knows that the shop's real shelves hold two copies of the same book.
• It can be confidently wrong, and it looks the same either way (lesson 02). A tidy diff with a clear message is no evidence that the change is right.
• Someone must answer for it. A model cannot be asked why in a month, and a person can.

The AI makes writing fast. It makes reading more important, because there is more to read.

What to read, and in what order

Do not start at the first changed line. Start with the promise, then check the work against it.

The diff is the difference between the branch and the main line: the old lines and the new lines side by side. It is the one place that shows exactly what this task changed. Your editor shows it for each file.

If the branch is large, that is a sign. A change that cannot be read in one sitting cannot be reviewed, so keep each task small. That is one more reason the specs are small (lesson 09).

What to look for

You do not have to read every line as a compiler would. Read like a teammate, and ask questions the AI is not likely to ask.

The last row matters most, and it is the one only a person can answer. If you see the feature working and realise a promise in the spec was wrong, do not patch the code. The spec was wrong. Change the docs first, then the code (rule 1). Lesson 14 shows that order.

💡 Reading someone else's code is a skill. A new reviewer asks "what does this line do?" a lot. That is fine. Ask the AI to explain a line you do not understand, then judge whether the explanation fits the spec. Do not approve a line you cannot explain.

Approve, or send it back

There are two outcomes.

Send it back. Say what to change, in plain words, pointing at the spec line or the convention. "The list ignores the sort rule in the spec" is a better note than "fix the list". The agent fixes the branch, the tests run again, and you read the change it made. A person is allowed to refuse, and a small fix is cheaper than a regret.

Approve. You have read it, you can explain it, and it does what the spec says. Only now does anything leave your machine.

Push and open the pull request

Until now, the branch lived on your computer. To let others see it, you push it to the shared server (the remote, such as GitHub or GitLab). Then you open a pull request: a page that says "please merge this branch into the main line", where teammates can read the diff, leave comments and approve.

The push is the first thing that leaves your machine, so it comes after your approval, not before. The wall from lesson 10 (a deny rule on git push) keeps the agent from pushing by accident, so you push yourself, once you have read the work. Alone on a project, you still read it first. A good habit is to read it after a break, when it looks less familiar.

In a team, the pull request is where your teammates read it too. They bring their own knowledge of the code. The AI saved the typing. The reading is still shared.

Where we ended

Nothing new is added to the project. The branch has been read and approved, pushed, and put up for review.

bookshop-backoffice/            on the branch task-03-add-book,
                                pushed, with a pull request open

Recap

• On a good team, the author reads their own change, then a teammate reads it, then it merges. Whoever's name is on it owns it.
• An AI does not change that. It only knows what was written down, it can be confidently wrong, and someone must answer for the result.
• Read in order: the spec, the summary, the tests, the diff, the file list. Keep each change small enough to read.
• Look for what is extra, missing, surprising, secret, not our way, and whether the plan is still right.
• Send it back with a note that points at the spec. Approve only what you can explain.
• Only after approval do you push and open the pull request. If the plan was wrong, the docs change first (rule 1).

Questions to think about

The answers are left out on purpose. Try them in your own words first.

1. Why does an AI-written change still need a person to read it?
2. Why start reading with the spec and not the code?
3. What can a person see that an AI review is likely to miss?
4. Why does the push come after your approval and not before?
5. If you see the feature working and the spec was wrong, what do you change first?

Next lesson: step 7, Refine. Tick the feature off, write what you learned back into the docs, and finish with a checklist.