Most code review tools only look at diffs. That's like reading the last chapter of a book and trying to write a review.
I built ReviewPilot — an AI code reviewer that reads your full source files, traces imports, and understands your codebase structure before reviewing.
What it does
When you open a PR (GitHub) or MR (GitLab), ReviewPilot automatically:
- Reads the full files being changed, not just the diff
- Traces imports to understand dependencies
- Posts inline comments with severity badges (Critical, High, Medium, Low)
- Catches bugs, security issues, and architecture problems
Two review modes
Dev Mode — Fast, automated review on every PR. Catches bugs, security holes, and style issues in seconds.
Leader Mode — Deep architecture analysis with risk scoring, mentor feedback, and approve/request-changes decisions. Like having a senior engineer review every PR.
How it works
For GitHub: Install the GitHub App → done. Reviews happen automatically.
For GitLab: Add a webhook + access token → done. Works with gitlab.com and self-hosted.
Drop a .reviewpilot.yml in your repo to customize:
yaml
mode: dev
ignore:
- "**/*.test.ts"
- "dist/**"
rules:
min_severity: medium
focus:
- security
- performance
Free tier
- 3 developers
- 4 reviews per developer/month
- Unlimited repositories
- No credit card required
Tech stack
- API: Hono + Node.js + BullMQ
- Dashboard: Next.js
- DB: PostgreSQL + Drizzle ORM
- AI: Claude for code analysis
- Deploy: Docker + Vercel
Try it: [reviewpilot-dashboard.vercel.app](https://reviewpilot-dashboard.vercel.app/)
Top comments (1)
Reading full files instead of just diffs is the right instinct. The hardest bugs to catch in AI-generated code are not in the diff itself but in the relationship between the diff and the rest of the codebase. A function that looks correct in isolation might violate an architectural boundary or reintroduce a dependency the team explicitly removed last quarter.
One question: does ReviewPilot have any mechanism for encoding team-specific architectural decisions (like ADRs or internal style contracts) so the reviewer knows what constraints to enforce beyond generic best practices? That is the class of issue where full-codebase context matters most, and it is also the class that is hardest to catch without some record of what the team decided and why.