Ehhhhh yeah kinda? Yes, you should spend most of your time on "API Semantics" (what does it look like using this code?), and you should spend a lot less time on

Ehhhhh yeah kinda? Yes, you should spend most of your time on "API Semantics" (what does it look like using this code?), and you should spend a lot less time on "how are the tests?" but, for example, Writing good tests massively contributes to good implementation details and API semantics; and test code is also code that needs to be reviewed under more-or-less the same criteria as the rest. Also - documentation (or, legibility, if you're onboard with self-documenting code) can be more important than either implementation details, and even API semantics, as it can define whether the entire work is useable or maintainable. I might say instead: - What will it be like reviewing this code? (style, test coverage, etc - do I have to worry about spotting typos, and other stupid stuff?) - What will be like debugging this code? (patterns, logging, etc - which might handled by a framework) - What will it be like altering this code? (documentation/legibility, implementation details, etc - when the business needs change or grow) - What will it be like using this code? (API semantics, API docs - when I go to build something on top of this) And then yeah; the top should be entirely automated, and you should (generally) spend most of your time on the bottom.