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: <a href="https://mathstodon.xyz/@mjd/115096720350507897" rel="nofollow">https://mathstodon.xyz/@mjd/115096720350507897</a><p>And in response I wrote a non-exhaustive checklist of things that a code review can look for:<p>- Does it functionally achieve what it sets out to (as per tacker issue or PR description)?<p>- Does it have extraneous code? Leftover debug prints, private API keys etc...<p>- Does it have any obvious defects? Memory leaks, un-handled edge cases, security flaws, obsolete API calls, etc...<p>- Could it be more understandable? Add/remove abstractions, better variable/method names, more/less functional etc...<p>- Is the style consistent with the codebase and/or style guidelines?<p>- Are there obvious performance improvements? Hashset instead of list, lazy evaluations, etc...<p>- Is it sufficiently well tested?<p>I think LLMs are <i>okay</i> at most of these, and worst at the first.
Unfortunately this often represents the only feedback given by the people in those „higher“ positions.<p>„The indent is wrong here“<p>„Comments should end with a period“<p>Because this kind of feedback is and was always easy.
Pangram check on the article: 94% of this text is AI
I couldn’t agree more. Code review is integral to engineering, to sharing system understanding, to building sustainable systems.<p>Something is missing in the new ai bot review paradigm we’ve all sleepwalked into.<p>I’ve been building Archme.io for this reason. PR reviews for the age of AI
I think this applies to the writing of code as well