[ocharles]

I recently started using LLMs to review my code before asking for a more formal review from colleagues. It's actually been surprisingly useful - why waste my colleagues time with small obvious things? But it's also gone much further than that sometimes with deeper reviews points. Even when I don't agree with them it's great having that little bit more food for thought - if anything it helps seed the review

[oldmanrahul]

Yes, exactly!

The objective of this initial review is to catch those low-hanging fruit that your colleagues would waste cycles on.

LLMs can catch syntax and basic semantics. Peers can spend time on more interesting things like design and relevant biz context.

[danlamanna]

Are you using a particularly well crafted prompt or just something off the cuff?

[eterm]

Personally, this is what I use in claude code:

"Diff to master and review the changes. Branch designed to address <problem statement>. Write output to d:\claudeOut in typst (.typ) format."

It'll do the diffs and search both branch and master versions of files.

I prefer reading PDFs than markdown, but it'll default to markdown unprompted if you prefer.

I have almost all my workspaces configured with /add-dir to add d:/claudeOut and d:/claudeIn as general scratch folders for temporary in/out file permissions so it can read/write outside the context of the workspace for things like this.

You might get better results using a better crafted prompt (or code review skill?). In general I find claude code reviews are:

  - Overly fussy about null checking everything
  - Completely miss on whether the PR has properly distilled the problem down to its essence
  - Are good at catching spelling mistakes
  - Like to pretend they know if something is well architectured, but doesn't

So it's a bit of a mixed bag, I find it focuses on trivia but it's still useful as a first pass before letting your teammates have to catch that same trivia.

It will absolutely assume too much from naming, so it's kind of a good spot if it's making wrong kind of assumptions about how parts work, to think how to name things more clearly.

e.g. If you write a class called "AddingFactory", it'll go around assuming that's what it does, even if the core of it returns (a, b) -> a*b.

You have to then work hard to get it to properly examine the file and convince itself that it is actually a multiplier.

Obviously real-world examples are more subtle than that, but if you're finding yourself arguing with it, it's worth sometimes considering whether you should rename things.

[sultson]

This one's served fairly well: "Review this diff - detect top 10 problem-causers, highlight 3 worst - I'm talking bugs with editing,saving etc. (not type errors or other minor aspects) [your diff]". The bit on "editing, saving" would vary based on goal of diff.

[morkalork]

Not who you're replying to but working at a small small company, I didn't have anyone to give my code for review to so have used AI to fill in that gap. I usually go with a specific then general pass, where for example if I'm making heavy use of async logic, I'll ask the LLM to pay particular attention to pitfalls that can arise with it.

[ocharles]

We're a Haskell shop, so I usually just say "review the current commit. You're an experienced Haskell programmer and you value readable and obvious code" (because that it is indeed what we value on the team). I'll often ask it to explicitly consider testing, too

[afro88]

This is exactly the right approach IMO. You find the signal amongst the slop, and all your colleagues see is a better PR.