Hacker News Reader

Comment by sunrunner | Hacker News Reader

> AI Agents are starting to write more code. How do we make sure we understand what they're writing?

This is a good question, but also how do we make sure that humans understand the code that _other humans_ have (supposedly) written? Effective code review is hard as it implies that the reviewer already has their own mental model about how a task could/would/should have been done, or is at the very least building their own mental model at reading-time and internally asking 'Does this make sense?'.

Without that basis code review is more like a fuzzy standards compliance, which can still be useful, but it's not the same as review process that works by comparing alternate or co-operatively competing models, and so I wonder how much of that is gained through a quiz-style interaction.

View on HN

Code review, to me, is not about validating the output. It's about a 2nd set of eyes to check for foot guns, best practice, etc. Code review is one step above linting and one step below unit tests, for me.

If someone were to submit this code for review:

    getUser(id: number): UserDTO {
        return this.mapToDTO(this.userModel.getById(id));
    }

and I knew that `userModel` throws an exception when it doesn't find a user (and this is typescript, not java, where exceptions are not declared in the method prototype) then I would tell them to wrap it in a try-catch. I would also probably tell them to change the return type to `UserDTO | null` or `Result<UserDTO>` depending on the pattern that we chose for the API. I don't need to know anything about the original ticket in order to point these things out, and linters most likely won't catch them. Another use for code review is catching potential security issues like SQL injection that the linter or framework can't figure out (i.e, using raw SQL queries in your ORM without prepared statements)

This lines up with my experience, sometimes it is as simple as "Your way is fine, but we did it this other way over here, and over here, should we make it consistent, even if it is consistent but not as good" or as you pointed out, looking for footguns. I also like the supervillian model of "Show this to an average 5 year old and see what obvious flaw they point out".

Depends how good your QA is. Where I am it is terrible so most of the time I spend in “code review” is spent checking out the code locally and testing it myself.

Yes, this is all on paper. Where I work we don't have QA

I imagine the quizzer could ask better questions along those lines with better context engineering (taking entire repo contents, design docs, discussions, etc and compressing those into a mental model). I just took the PR code changes and comments, so there's a lot of improvements that could be made there.

Reply on news.ycombinator.com