Most code review tools today produce confident-sounding noise. Some catch real issues. Most waste your time. We're building Revund because senior engineering review — the kind that shapes good code — is too valuable to fake.
An LLM with a diff isn't a senior engineer. It's a very confident intern who didn't read the rest of the codebase. It will tell you a function is unsafe without knowing what calls it. It will recommend a pattern your team deliberately abandoned two quarters ago. It will flag style choices your linter already enforces.
Static analyzers have the opposite problem. They're precise, fast, and free of hallucinations — and they can't reason. A regex doesn't know your business rules. A type checker can't tell you that a query is N+1 in a hot path. Both miss the things that actually matter when a senior engineer reviews a PR.
The result: most automated review either drowns the real signal or stays so shallow that humans rubber-stamp it. The dev who could have caught the bug spends their attention elsewhere. The PR ships. The bug ships.
A review is trustworthy when each finding answers two questions: what is wrong and why does it matter here. “Why” is the load-bearing word. Without it, every finding is the same: a wall of warnings someone has to triage. With it, findings become arguments — and arguments can be evaluated, accepted, or refuted on their merits.
Revund is built on this premise. Every finding carries an explicit rationale grounded in the actual code under review, not a templated “consider also…” from somebody's prompt. If we can't explain why, we don't surface it.
A finding without a why is a warning. A finding with a why is a conversation. We only ship the conversations.
Six principles shape the engineering. They're not taglines — you can read them in the code.
Four passes review every PR — security, performance, architecture, style. Each has its own prompt, its own output schema, its own confidence calibration. A security finding is judged against the security pass's standards, not whatever the model felt like that day.
We resolve real symbols, run the project's own type checker where one exists, and bundle the relevant unchanged code into the review. The model sees what a human reviewer would scroll up to find — not just the diff. On TypeScript that means tsc and ts-morph; other languages get the analyzer the language already has.
Every finding carries a confidence score. Below a threshold, we drop it silently. Better to miss a marginal finding than to drown the real ones in speculation.
When you mark a finding as a false positive (with a reason — the trust loop runs both ways), Revund fingerprints it and never raises that pattern on this repo again. The codebase teaches the tool what it already knows about itself.
Revund won't catch a logic bug that requires domain knowledge it doesn't have. It won't replace your design discussions. It will catch the things a careful senior reviewer would catch on a good day — consistently, on every PR, without fatigue.
Findings post to GitHub Checks, GitLab discussions, and Bitbucket Code Insights or PR Comments — your team's choice per workspace. Reviewers don't context-switch to a separate dashboard to read a review.
Code review is a craft. We're trying to amplify it, not replace it.
Teams that ship real code on real codebases. Engineers who already know what good review looks like and are tired of tools that don't. Tech leads who want senior-grade review on every PR, not just the ones they personally have time to read carefully.
We review any codebase. We go deeper on TypeScript today because that's where we have full type resolution and project-wide context running cleanly — tsc and ts-morph feed every finding. Python, Go, and Rust enrichment land next. The depth comes from the language analyzer; the discipline and the “why” carry across all of them.
The bet is that code review — thoughtful, grounded, specific code review — is one of the highest-leverage things a senior engineer does, and that doing it consistently across every PR a team ships is worth more than any single feature flag, observability dashboard, or productivity tool we could build instead.
If you've ever shipped a bug that a 30-second second opinion would have caught, you already know.