Birbla

What tools are you using for human code review of AI-assisted code?

What tools are you using for human code review of AI-assisted code?

6 pointsby dafelst0 comments

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Most of the time I just give Claude Code the PR link and then do the human side of the review based on the feedback it gives me.

    Sometimes I'll prompt again to scrutinize further.

    by wbnns
  • It seems most people directly issue review commands to the LLM, whereas my approach is to use different skills to perform repeated cross-checks, and after each check I add corresponding tests to prevent regressions.
    by cjg007
  • Hey there! Coderabbit DX staff here. We have a new interface we are exploring for code review called change stack. Would love to hear your feedback on it and learn of the issues you mentioned above. If you have a PR we could take a look at I can bring this to the tea,
    by juanpflores
  • TBH I just use another ClaudeCode to review or ask the agent to explain its reasoning process with me. I personally believe the reviewable unit shouldn't be the final diff. Instead, review the decision trace: plan, assumptions, etc. And if you agree with the agent's decision trace, probably you will also agree how the code was implemented
    by BonanKou
  • BugBot in Cursor has been great, I rarely find myself looking at it and disagreeing, especially with medium/high impact. I also have a custom architecture reviewer that just runs Claude, that's been great for finding duplicate code, boundary breaking, etc. We still have Github Copilot reviewing because it will (very occasionally) catch something BugBot missed, but the false positive rate is wayyyy higher, to the point I've considered disabling it a few times.
    by joshgachnang
  • I’m considering a set of skills that I can apply common lenses to PRs (metrics, error handling, testability + tests, architecture, security), and fetch the code and pr details via the GitHub CLI or an MCP. This seems like it might get absurdly expensive, but maybe w the right tuning it’ll be possible to run most of them on smaller models. Each would let me zoom in on its area and help me through the process of reviewing.

    The problem is with full on misses that I’d be able to catch by going line by line. The more static analysis and style enforcement the better - I’m still not sure whether it will come out as a benefit, esp when you consider cost of tokens. AI often creates its own extra work alongside the benefits, and it’s a bit like nicotine in that it works for a minute but then you’ll need to keep applying it to even return to baseline.

    by taurath
  • Me and my team use https://pyor.review instead of github, which I built myself, it’s a far better alternative and fixes our exact pain points
    by othmanosx
  • Hey,

    the fact that Github's PR interface isn't suited anymore and that review must go from detailed style/code focus towards architecture and high-level design really resonates with a pain I've had for months.

    A friend and I are just building something to solve that. In a nutshell we capture the AI sessions along the development to extract the key decisions and choices. We then use that to help navigate the diff and guide the reviewer towards what matters.

    Feel free to have a look => https://www.herve.review/ we're reaching the end of the beta phase, but happy to still loop you in :)

    by ArnaudDebray

Explore Birbla archives