Graphbit PRFlow - AI code reviewer that catches what others miss

@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.

@imogen_wallace Yes. PRFlow analyzes the PR holistically, not file by file, and adds cross-file dependency context during review. That makes it better at finding issues that span several dependent files.

@imogen_wallace Yes, that is the core of how PRFlow works. Most tools do diff-level scanning and miss issues that live in connected files. PRFlow does cross-file bug detection in GitHub PRs by tracing the actual function that changed and following its dependencies. In our benchmark we caught an XSS vulnerability spanning a Ruby model, an HTML template, and a JavaScript file - classic case of automated XSS detection that a diff-only tool would never reach. Reducing technical debt with AI code review only works if the review actually sees the full picture. Happy to share the GitHub link to that specific finding if useful.

@boyuan_deng1 Great question. We don't use a rule engine, that's actually a key part of how PRFlow avoids noise in pull request security auditing.

Instead of predefined rules, PRFlow uses context-aware pull request analysis. It extracts the exact function that changed, pulls in cross-file dependencies, and retrieves past feedback from your team's correction history. The AI then evaluates against that full picture, not a checklist.

What reduces noise in practice: if your team has previously flagged something as intentional, PRFlow stores that and stops raising it. Over time the signal-to-noise ratio improves automatically without you writing a single rule.

The honest answer is no system is perfect on day one, but the memory layer is what separates it from tools that feel like a coin toss every PR. Happy to dig into specifics if you have a particular case in mind.

@boyuan_deng1 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.

@olivia_bennett7 Yes, for monorepos inside a single repo. PRFlow uses cross-file dependency analysis and repo-level context, so it can reason across multiple projects in the same PR, with practical limits on very large PRs.

@olivia_bennett7 Within a single repo it handles cross-file dependencies well out of the box. Full cross-project monorepo support is something we're working on.

What's your setup? Happy to tell you exactly what PRFlow would and wouldn't catch for your case

@daniel_harris11 Yes. When your team replies to a PRFlow comment, "this is intentional" or "we prefer this pattern" it stores that and applies it to future reviews automatically.

No manual training setup. It learns from how your team actually works

@daniel_harris11 Yes. Today that happens mainly through configuration plus feedback loops: repo-level review rules, ignored paths, path-specific focus, and explicit corrections from developers in PR conversations. That is how PRFlow starts aligning with team-specific patterns over time.

@asher_luca Thanks. Right now, PRFlow is GraphBit cloud-based rather than self-hosted. The review orchestration runs through the GraphBit cloud.

@asher_luca Cloud-based for now. Self-hosting is something we hear interest in, especially from enterprise teams. Good to know it matters to you, noting it

@jason_shen3 This is the hardest problem in the space and you've articulated it perfectly.

Honest answer: right now PRFlow learns from explicit corrections, when your team flags something as intentional, it stores and applies that. So a new pattern gets reinforced when engineers actively confirm it in review conversations.

The drift vs regression detection you're describing - knowing when the team is intentionally evolving vs accidentally breaking convention - that's a deeper layer we're working toward. The memory architecture is built to support it but we're not claiming to solve it fully yet.

Appreciate you pushing on this. The teams that think at this level are exactly who we're building for 🙏

And congrats on @articuler.ai, Matching on intent across 980M profiles is a genuinely hard problem, the playbook feature especially, turning a cold connection into a warm conversation before it even starts. Rooting for you on launch day..

@jason_shen3 Thanks. Right now, PRFlow learns team standards from explicit review feedback and corrections, so when engineers mark a pattern as intentional, that gets stored and reused in future reviews.
Detecting intentional standard drift versus accidental regression is a harder unsolved layer; the memory architecture is designed for it, but we’re not claiming full automatic drift detection yet.

@bilal_niaz Exactly that. The diff is just the surface, the bug usually lives in how the change connects to everything else. Appreciate you getting it.

@bilal_niaz Thanks. Really appreciate that. That was one of the biggest things we wanted to solve, moving beyond line-by-line diff comments and giving the reviewer enough surrounding context to catch architectural or cross-file issues that would otherwise get missed.

@gaius_loxley Not yet, PRFlow currently triggers on PR events, so it works on open and updated PRs. Retroactive auditing on closed PRs is something we've heard interest in. Good signal, noting it

@gaius_loxley Not yet. Right now PRFlow is event-driven, so it works on open and updated PRs rather than closed PRs retroactively.