Graphbit PRFlow - AI code reviewer that catches what others miss

@musa_molla Yes. Very noizy. You need a master PR reviewer jsut to review the AI reviewers 😅.... Is graphbit free for public repos? id love to try it on one particular public repo thats launching soon on PH https://github.com/eoncode/runner-bar/

@1mirul Exactly the balance we were going for. PRFlow handles the repetitive stuff so the senior devs can focus on what actually needs their eyes. Thanks for getting it

Thanks, @1mirul. That’s very much the design philosophy behind PRFlow. We’re not trying to replace human review, but to automate the repetitive process so engineers can focus on architectural decisions, business logic, and edge cases. The goal is to make review workflows more consistent inside GitHub while keeping humans in control of the final judgment.

@tanjum That's exactly the balance we were going for, baseline handled automatically so engineers stay focused on what needs human judgment.

On larger PRs and multi-file changes: PRFlow traces the exact function that changed and follows its dependencies across files in the same PR. Token budget is managed so larger PRs don't get shallow reviews. The depth stays consistent regardless of PR size

@tanjum Thanks. For bigger PRs, PRFlow builds context in layers using our own context engine. It extracts structured context from each changed file, enriches that with cross-file dependencies, and then reviews the PR as a whole rather than one file at a time. For very large PRs, it also uses token budgeting and file prioritization so the review stays focused and useful.

@byalexai Thank you for supporting us today, means a lot to the whole team 🙏

@abod_rehman Yes, it can run on every push to an open PR, not just when the PR is first opened. Right now PRFlow triggers on PR open, on new commits pushed to the branch, and when a draft is moved to ready for review.

@abod_rehman Thank you! PRFlow triggers on PR open and every push to an open PR, so automated pull request review happens continuously throughout the lifecycle, not just at the start. Every new commit gets a fresh pass. No gaps in coverage

@campritchard That's exactly it, the diff is just the entry point. The bug lives in what the change touches downstream. Glad that landed clearly 🙏

@campritchard Exactly. The diff is usually just the starting point, not the full problem surface. A lot of the real issues only show up once you trace what the change affects across related files. Glad that part came through clearly.

@lokesh_motwani1 Great question and glad you're going to try it on Badge.

The single pass doesn't mean one giant context window. PRFlow extracts only the relevant function scope and its cross-file dependencies before sending to the model, so the actual input is tight and focused, not a full repo dump. That's what keeps the middle from getting lost.

Token budgeting handles the rest, larger PRs get prioritized by semantic significance rather than being truncated blindly.

Important thing is, no system is perfect on very large PRs, but the extraction step before the model call is what keeps the signal-to-noise ratio high

@lokesh_motwani1 Good question. We try to reduce that risk before the model call, not after it. PRFlow does structured context extraction first, adds cross-file dependency context, then applies per-file token budgets and memory budgets so one large file does not crowd out the rest of the PR.

If the PR is too large, we prioritize the reviewable files instead of pretending nothing gets lost. So the approach is basically controlled compression plus prioritization, not “throw the full diff into one prompt and hope for the best.”

@liviu_chita hat's one of the sharpest questions we've gotten today.

Right now PRFlow follows what changed and traces its dependencies within the PR. A missing update at a call site that was never touched, that's a gap we don't fully close yet, because we work within the scope of what the diff includes.

What partially helps, cross-file dependency tracing sometimes surfaces the call site in context even if it wasn't edited, depending on how tightly the functions are linked. But I won't overstate it — detecting what should have changed but didn't is a harder problem and one we're thinking about seriously.

Good thing to keep pushing on

@liviu_chita That’s exactly one of the cases we try to catch. PRFlow enriches the changed code with cross-file references and can look up related functions or patterns outside the diff, so it can flag “this call site should have been updated too” even when the missed file was untouched.

The practical constraint is that the comment still has to anchor to a changed line in the PR, so the issue gets attached to the nearest relevant changed code rather than the untouched file itself.

@ebazan33 The bottleneck for us wasn't inference speed, you're right that LLM latency dominates. The reason we reached for Rust was deterministic routing. We needed the orchestration layer to be predictable and auditable, not probabilistic. When PRFlow makes a decision about what context to include or how to route a review, that decision has to be the same every time. Python frameworks gave us flexibility but not that guarantee

@ebazan33 Good question. It was not about making the LLM itself faster. The reason for Rust was the orchestration layer around enterprise agent workloads, things like concurrency, runtime stability, lower overhead in tool and memory flows, and more predictable performance under load, while keeping Python as the developer-facing layer.