I operate from the presumption that code's first job is to be as easy for a human to understand as possible. It should clearly communicate what it's attempting to do. If your code isn't written so that your colleagues, or you 2 years from now, can read it and understand it, it's bad even if it's whip tight, fits all the AC and has 100% test coverage with a perfect mutation score. That's what I focus on when I review code: does it communicate intent semantically. Code that can be understood is code that can be reused, optimized, altered when use cases change, generalized out into even more reusable code, and provide insights that technically perfect but incomprehensible code can't. I, like you, assume that the coder knows what they were trying to do and how to test for it, so that only gets a cursory glance to spot common errors like missed nullables, inverted conditionals and shit like that. I look at it from the perspective of "If I had to add functionality to this, could I do so easily". Because I'm gonna one of these days.