Unfortunately this often represents the only feedback given by the people in those „higher“ positions.

„The indent is wrong here“

„Comments should end with a period“

Because this kind of feedback is and was always easy.

There's been a lot of talk about the purpose of code review recently. It makes sense in the face of AI. Heres a link that was submitted a little while ago: https://mathstodon.xyz/@mjd/115096720350507897

And in response I wrote a non-exhaustive checklist of things that a code review can look for:

- Does it functionally achieve what it sets out to (as per tacker issue or PR description)?

- Does it have extraneous code? Leftover debug prints, private API keys etc...

- Does it have any obvious defects? Memory leaks, un-handled edge cases, security flaws, obsolete API calls, etc...

- Could it be more understandable? Add/remove abstractions, better variable/method names, more/less functional etc...

- Is the style consistent with the codebase and/or style guidelines?

- Are there obvious performance improvements? Hashset instead of list, lazy evaluations, etc...

- Is it sufficiently well tested?

I think LLMs are okay at most of these, and worst at the first.