Every Pull Request (PR) your team opens is a small bet: that the code does what it is supposed to do and does not break anything downstream. Human reviewers catch a lot, but they also carry the mental load of reconstructing what a 30-file diff is actually trying to accomplish, in addition to their own work. Refacto reviews each PR as it opens, analyzes the changes with complete codebase context, and identifies issues so that engineers can focus on the areas that matter most.
For a broader view of how AI code review works across tools and workflows, start with our complete guide to AI code review.
What you need before starting
The setup is short. Before you open the Refacto dashboard, make sure you have:
- Admin access to the GitHub repository (or organization) where you want to enable reviews
- A Refacto account: the free trial covers your first repositories at no cost
- About five minutes to complete the setup process
That is genuinely it. Refacto connects to GitHub through the standard GitHub Apps mechanism, which means no tokens to manage, no webhooks to configure by hand, and no scripts to run.
Setting up Refacto on GitHub
The official setup lives in Refacto's documentation at docs.refacto.ai/integrations/github. The process follows four steps.
Step 1: Open the integrations page
Log in to your Refacto account and go to app.refacto.ai/integrations. This page lists all available integrations, currently GitHub, with more platforms on the way. GitHub will be the first option you see.
Step 2: Connect GitHub
Click the Connect button next to GitHub. Refacto redirects you to GitHub’s authorization screen, where you grant the required permissions.
Step 3: Authorize Refacto-bot
GitHub shows the Refacto installation screen, where you choose between two options:
- Select whether Refacto should have access to all repositories in your organization or only specific ones
- Confirm the installation by clicking Install & Authorize
Tip: Select one or two active repositories first rather than granting access to your entire organization. You can expand access later from GitHub's app settings page under your account or organization settings.
Step 4: Finish setup
After you authorize, GitHub redirects you back to the Refacto app. The GitHub integration now shows as Connected on the integrations page, and Refacto starts indexing the repositories you selected.
What happens after you connect
Once the integration is live, Refacto begins an initial index of the selected repositories. It builds a map of your entire codebase, understanding file relationships, shared utilities, and patterns across the code, rather than analyzing only the latest changes. That context is what separates a review that flags issues in isolation from one that understands the impact of a change.
Indexing time scales with repository size:
| Repository size | Approximate index time |
|---|---|
| Under 10,000 lines | Under 2 minutes |
| 10,000 to 100,000 lines | 5 to 15 minutes |
| 100,000+ lines or monorepos | Up to 30 minutes |
The dashboard shows indexing progress in real-time. Refacto holds off on reviewing PRs until the index completes, which ensures that the first comment it posts is based on full context rather than just the diff.
What Refacto's review looks like on a real PR
Open a PR on any connected repository. Within 60 to 90 seconds of the PR opening, Refacto posts its review. The output has two parts.
A PR summary appears at the top of the review thread, giving a quick view of the full diff: issue counts by severity, the most affected files, and patterns that span multiple files.
Inline comments are added directly on the flagged lines. Each comment explains the issue in simple terms and includes a suggested fix. These suggestions are also available as 1-click fixes so that developers can apply the change directly to the PR without copying and pasting code.
Developers reply to Refacto’s comments directly in the PR thread, just as they would with a human reviewer. Resolving a comment with a reason helps Refacto reduce similar feedback in future reviews on that repository.
What changes for your human reviewers
This is where the value becomes clear, and it typically shows up within a week or two.
Senior engineers reviewing PRs often report that a large portion of their review time goes toward comments they could write in their sleep: unused variables, missing null checks, inconsistent naming, and obvious error handling gaps. That work is useful, but it is expensive when it comes from a senior engineer's limited review bandwidth.
Once Refacto is in place, those mechanical layers are already handled before a human reviewer opens the PR. The review becomes a conversation about whether the code does the right thing: the architecture, the product context, and the edge cases that only a domain expert would catch.
| Refacto handles | Your engineers focus on |
|---|---|
| Catches bug patterns and logic errors | Evaluates architecture and design decisions |
| Flags security antipatterns (SQL injection, XSS, unsafe deserialization) | Weighs product context and feature intent |
| Enforces naming conventions and style rules | Spots cross-service and downstream side effects |
| Identifies unused variables and dead code paths | Transfers knowledge to junior engineers |
| Detects missing error handling and unhandled rejections | Flags assumptions that only a domain expert would catch |
For the full framework of what to look for on every PR once AI handles the mechanical layer, the Code Review Checklist: 2026 guide covers that in detail.
Three setup mistakes worth avoiding
Most friction with Refacto traces back to one of these three decisions made during the first setup.
Granting access to all repositories without configuring exclusions
If you enable Refacto across your entire organization and leave the defaults in place, you will get reviews on repositories where generated code, vendor dependencies, and build artifacts live alongside your actual source. The result is a noisy review queue that makes the tool feel like a linter with too many rules. Install selectively first, configure exclusions per repository, and expand from there.
Requiring Refacto approval before your configuration is stable
GitHub's branch protection rules let you mark Refacto as a required reviewer. That is a useful setting once you trust the tool's calibration on your codebase, but enabling it in the first week means a false positive on a generated file can block a legitimate PR from merging. Start with Refacto as an informational reviewer, give it two to three weeks, and then decide whether required checks make sense for your workflow.
Opening PRs before the initial index finishes
If a PR arrives before the index completes, Refacto reviews only the diff. It still posts useful comments, but it cannot flag issues that depend on understanding how a changed function interacts with callers elsewhere in the codebase. The dashboard shows a clear status indicator when indexing is complete.
Once your GitHub setup is stable, the next step is wiring Refacto into your deployment pipeline. The guide to integrating AI code review into your CI/CD pipeline covers how to combine PR-level reviews with your existing test and build steps.
Start your free trial and review your first PR in 5 minutes -> refacto.ai/signup