Thread

1. n4r9 · 1790545492 · focus · HN ↗

   There&#x27;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:&#x2F;&#x2F;mathstodon.xyz&#x2F;@mjd&#x2F;115096720350507897" rel="nofollow">https:&#x2F;&#x2F;mathstodon.xyz&#x2F;@mjd&#x2F;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&#x2F;remove abstractions, better variable&#x2F;method names, more&#x2F;less functional etc...

   - Is the style consistent with the codebase and&#x2F;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.

   1. anarazel · 1790546768 · focus · HN ↗

      - Do we want this? Cost&#x2F;Benefit etc

      - Is the change architecturally right?

      Particularly the latter LLMs seem still pretty useless at.

      1. birdatlaw · 1790549661 · focus · HN ↗

         The former feels more like a product leadership problem.

         Although I do think that LLMs have made it much easier to justify writing low-value code which can make this more common now.

         1. anarazel · 1790550951 · focus · HN ↗

            I work on an open source project, so to-be-reviewed work can come in without any involvement by anyone :)
         2. bunderbunder · 1790557723 · focus · HN ↗

            The thing is, leadership relies on the people actually building the software to provide concrete, accurate feedback about cost. Without that they have no chance to do a decent cost&#x2F;benefit analysis.

            But AI has engendered a collapse in developers’ ability to actually do that. Those of us who are stuck on the vibecoding bandwagon have lost the comprehensive understanding of the systems under our care that we need to understand and explain the quality and maintenance implications of a change.

            Worse, if you happen to lose your mind and suggest the initial development cost is anything more than ~zero, your friendly neighborhood Claude keener will publicly shame you for not having sufficient faith in the Glorious Agentic Future. Product leadership will then have no choice but to side with them, not necessarily because they agree, but because they, too, are aware that we’re still in the phase of the hype cycle where openly questioning said hype is a career-limiting move.

         3. goda90 · 1790565730 · focus · HN ↗

            The &quot;do we want this&quot; question can also apply to functionality, not just cost&#x2F;benefit. I&#x27;ve seen AI volunteer &quot;features&quot; that aren&#x27;t actually useful or are actively harmful to user experience but it generates them because they do make sense in different contexts.

Unofficial Hacker News client; not affiliated with Y Combinator.