There is more to code review than (automatable) detection
Thread
Unofficial Hacker News client; not affiliated with Y Combinator.
There is more to code review than (automatable) detection
Unofficial Hacker News client; not affiliated with Y Combinator.
n4r9 · · focus · HN ↗
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.
aeonik · · focus · HN ↗
Is there already a pattern or code on in in the existing codebase that handles this functionality,
Do we really need net new code to achieve this functionality?
Can existing code be extended or abstracted to more cleanly implement this feature or functionality.
bunderbunder · · focus · HN ↗
I don’t think I have ever even once seen an LLM solve a problem related to overengineering by simply removing the overengineering. They always choose to add more epicycles and further compound the complexity.
sfn42 · · focus · HN ↗
classified · · focus · HN ↗
sfn42 · · focus · HN ↗
I'll lay out a vague plan and let the AI fill in the blanks, mostly it'll get them right and where it doesn't I'll just tell it to do it differently and how. Works great for me.