From reading code to reviewing code
The best way to learn a codebase is to review someone else's change to it. Today that "someone else" is Devin — an autonomous software engineer. You write a spec, Devin writes the code, and you review it like you would any colleague's PR.
What to look for in a PR
A great code review answers three questions:
- Does it do what the spec said? (Correctness.)
- Is it built the way the rest of the codebase is built? (Consistency.)
- Will the next person to touch this understand it? (Readability.)
You are not reviewing for:
- Whether you would have solved it the same way. That's your ego talking.
- Style preferences the linter already enforces. Let the machine do machine work.
- Things the PR didn't claim to do. Scope discipline matters.
The review rhythm
- Read the description first. What's the goal?
- Read the tests next. Tests tell you what the author believes the code does. If the tests are missing or weak, the rest of the review is harder.
- Read the code last. Look for surprise — anything that doesn't match your mental model is worth a comment.
- Leave comments at three levels:
- 🚧 Blockers — must be fixed before merge.
- 💭 Discussion — "have we thought about X?"
- ✨ Nits — minor, optional.
Your capstone
Use the Devin capstone below. Describe the feature, launch a session, and when Devin's PR lands, review it against the rubric.
In a later module we'll give you broken PRs to review — sometimes the spec is wrong, sometimes the code is wrong, and sometimes both are wrong. Your job as an engineer is to notice.