Graphbit PRFlow - AI code reviewer that catches what others miss
byā¢
Your AI teammate that reviews every pull request before it ships.
Tested on 10 real projects, PRFlow found 7 critical security issues where competitors found zero.
Learns your team's standards over time. Pay per review, not per seat.
Replies
GraphBit
Hey Product Hunt! š Thrilled to be here on launch day.
I'm Junaid Hossain, one of the makers behind PRFlow, and I want to share why we built this.
We kept hitting the same wall: AI code reviewers that catch nothing meaningful on the first pass, flood your PR with noise, and feel completely different run to run. Consistency was broken at the foundation.
PRFlow is our answer to that. It doesn't just scan diffs, it traces the exact function that changed and follows it across cross-file dependencies in a single pass. That's how it caught 7 critical security issues, including an XSS vulnerability spanning a Ruby model, an HTML template, and a JavaScript file, where competitors found zero.
What makes it different in practice:
Every PR gets a structured review, every time, not just when you're lucky
It learns your team's standards from feedback, so noise goes down over time automatically
Pay per review, not per seat. Therefore, no bloated contracts for a tool you're still evaluating
We benchmarked on 10 real public PRs. Some of the reviews are live on GitHub. You can read them right now.
Would love for you to install it on a real repo and tell us what you think. We read every single comment. š
Quick question: does GraphBit support connecting to self-hosted or open-source LLMs (like Ollama or local Llama models), or is it limited to cloud API providers like OpenAI and Anthropic? Thinking about use cases where data can't leave the network.
GraphBit
@aanchal_dahiyaĀ GraphBit is model-agnostic by design and on-prem deployment is supported. For data-sensitive use cases, the architecture allows local tokenization before any LLM contact. Self-hosted models including local Llama setups can be connected. Happy to walk through the specifics if you want to share more about your setup.
GraphBit
@aanchal_dahiyaĀ Right now, it is limited to cloud API providers.
The current supported path is Anthropic, Azure OpenAI, and OpenAI, not Ollama or local/self-hosted Llama models today. But self-hosted models including local Llama setups can be connected. Would love to know your setup.
The 'deterministic baseline' angle is what caught my attention. Most AI reviewers feel like a black box that gives different results run to run. How do you handle PRs that touch generated code or vendored files? Those often create a lot of noise in reviews.
GraphBit
@christian_knautĀ Generated files and vendored dependencies are detected and skipped automatically before the review even starts. Lockfiles, protobufs, minified code, migration files; PRFlow classifies them and excludes them from the review scope. The model only sees code your team actually wrote
GraphBit
@christian_knautĀ Thanks. We filter a lot of that noise up front.
Generated or vendored paths can be excluded through file filters and repo-level ignore rules, so the review stays focused on real code changes.
GraphBit
Hey Product Hunt! Iām Rupak, one of the makers behind Graphbit PRFlow.
We built PRFlow to make pull request reviews faster, more reliable, and more context-aware, so teams can catch real issues before code ships.
It reviews PRs inside GitHub, leaves clear actionable comments, supports follow-up conversations on the PR, and gets better context over time from repository and conversation memory.
Happy to answer questions about how it works, what kinds of issues it catches and other technical functionalities.
Congrats on the launch! How do you define noise vs a real issue in your rule engine?
GraphBit
@barnaby_lloydĀ Thanks. In PRFlow, noise means low-value feedback like trivial nits, duplicate comments, or findings below the repoās configured threshold. A real issue is something actionable that affects correctness, security, performance, maintainability, or cross-file behavior.
GraphBit
@barnaby_lloydĀ @rupak_chandra_bhowmickĀ Rupak nailed it. The only thing I'd add is that the threshold shifts over time based on your team's feedback. If your team consistently dismisses a certain type of comment, PRFlow stops raising it. The definition of noise becomes specific to your repo, not a generic preset
Congrats, Musa! Does PRFlow handle cross file refactors where a function signature changes across 10 files?
GraphBit
@emily_carter18Ā , Thanks. Yes, within a single PR thatās exactly the kind of cross-file change PRFlow is meant to handle. It analyzes the PR holistically, so a function signature change across 10 files is reviewed as one connected refactor rather than 10 unrelated edits, subject to the PRās file-size limits.
GraphBit
@emily_carter18Ā @rupak_chandra_bhowmickĀ Rupak covered it well. The key word is "connected" PRFlow treats the whole PR as one unit, not file by file. That's what makes refactors like this reviewable in a meaningful way rather than generating 10 isolated comments that miss the bigger picture
What caught my attention was the cross file dependency tracing part. Most AI code review tools only look at the changed lines on their own, so they miss problems where a small change in one file ends up breaking something somewhere else in the codebase. Tracing how a function change affects its actual dependencies feels way more useful, and honestly thatās probably why PRFlow was able to catch security issues that other tools completely missed.
I was wondering how well that scales though. If someone opens a really large PR with hundreds of modified files, does the cross file analysis start slowing down a lot, or does the Rust based core keep the performance fairly stable even at that size?
Cross-file dependency tracing seems really useful - a lot of review tools miss issues that only show up across multiple files. If PRFlow catches something like an XSS issue, how does it present that to developers? Does it leave separate inline comments in each file, or generate one explanation that shows the full data flow across the stack? Iād imagine the way it surfaces the issue matters a lot here.
The architectural decision that intrigues me is how you deal with the reality that team norms are always changing. Your model has three months of "this is how we do it" in its weights after a staff engineer sends a new pattern on Monday and the team accepts it by Friday. Is it possible for PRFlow to distinguish between a team that is unintentionally regressing and one that is purposefully drifting? seems to be the most challenging issue in this area. For my part, I need a product that can address this issue.