iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Most AI code review tools read more than the changed lines, but “more” covers very different inputs. One tool may gather context across the whole repository, another may read instruction files you already keep in the repo, and a third may learn from reviewer reactions and merged changes. Whether a tool can apply your team’s rules depends on three things: which inputs it documents reading, where your rules live, and which data terms apply to your deployment.
The descriptions below reflect vendor documentation as it read in October 2026. They describe how each tool is designed to work. They do not establish how accurately any tool enforces a given rule, and product, plan, and privacy terms change often.
Short answer: what each tool documents reading
None of the four tools covered here documents reading only the diff. Each describes some wider context, but the scope, the rule sources, and the feedback mechanisms differ. “Not stated” in the table means the cited vendor page does not describe that behavior. It does not mean the feature is absent.
Free tools Windows power users keep installed
One-click scans. No signup required.
| Tool | Repository scope documented | Rule sources documented | Learns from history or feedback | Documented exclusions | Connected context |
|---|---|---|---|---|---|
| GitHub Copilot code review | “Full project context gathering” in agentic review; analyzes the entire repository to understand changes | Repository-wide and path-specific instruction files, AGENTS.md, agent skills | Not stated | Three listed file categories | MCP servers, when configured and relevant |
| Greptile | Graph built from enabled repositories, which its learning page says can extend to adjacent repositories | Repository configuration, organization defaults, scoping by repository, directory, or file type; automatically indexed rule files | Reactions, tags, and what gets merged | Not stated | Not stated |
| CodeRabbit | Codebase analysis; the FAQ does not detail how far it reaches | Team standards it analyzes; the sources of those standards are not detailed | Data used to fine-tune reviews, per the FAQ | Not stated | Not stated; its VS Code plugin reviews committed and uncommitted changes |
| Qodo | Cross Repo Review across dependent repositories and Git providers; one context engine across IDE and Git surfaces | Rules mined from PR history; governed skills discovered across repositories | PR history | Not stated | Git provider integrations (GitHub, GitLab, Bitbucket, Azure DevOps, and others); other connected systems not stated |
The six inputs a review can draw on
“Repository context” is not one thing. Separating the layers prevents the common mistake of assuming that a tool which reads “the codebase” also reads your rules, your history, and your ticketing system.
#1 Best Overall
- The diff. The changed lines in the pull request. Every tool here reads it, so the useful question is what surrounds it.
- Surrounding repository code. Functions, classes, and files the change touches or depends on. GitHub, Greptile, and Qodo each describe this in some form.
- Other repositories. Greptile says its graph can cover adjacent repositories, and Qodo describes reasoning across dependent repositories.
- History and feedback. Merged changes, reviewer reactions, tags, and PR history. Greptile and Qodo both describe using these signals.
- Written rules. Instruction files, rule files, configuration, and agent skills that tell the tool what your team expects.
- Connected systems. Issue trackers, documentation, service catalogs, and incident tools. GitHub documents this through MCP servers.
“Documented to read” is not the same as “sent to a model on every review.” None of the cited pages explains how much of this context reaches the model for a given pull request, or how that context is selected. If your codebase is large or split across many services, ask each vendor that question directly before you rely on cross-repository review.
What “following your rules” requires
A written rule is only enforced when the tool reads the place where the rule lives, the rule’s scope matches the code it governs, and the rule is specific enough to check against a change. The vendor pages address the first two directly. Only GitHub documents which branch the rules are read from.
- Branch version. GitHub reads instructions and skills from the pull request’s head branch. A pull request that edits the instruction file is therefore reviewed against the edited rules, and a rule removed in that branch no longer applies to that review.
- Scope. Scope is the most common mismatch. A rule written for payment services should not apply to documentation folders. Check whether the tool can limit a rule to a path or file type; GitHub and Greptile both document this.
- Specificity. A rule such as “use our logging conventions” is hard to check against a diff. A rule that names the logger, the forbidden call, and the directory it applies to gives the reviewer something concrete to flag.
GitHub Copilot code review
Repository context and agentic review
GitHub’s overview of Copilot code review says its agentic capabilities provide “Full project context gathering” and analyze the entire repository to understand code changes. GitHub describes the expected benefit this way: “The more Copilot knows about the code in your repository, the tools you use, and your coding standards and practices, the more accurate and useful its reviews will become.” That is GitHub’s own description of the design, not an independent measurement.
Instruction files and scope
The usage guide for code review describes three places to put guidance:
Rank #2
.github/copilot-instructions.mdfor repository-wide guidance..github/instructions/**/*.instructions.mdfor path-specific rules.AGENTS.mdfor project context.
Agent skills can also inform a review. Because instructions and skills are read from the pull request’s head branch, keep rule files in the same review process as code changes, so that a rule change is visible to reviewers before it takes effect.
What GitHub excludes
GitHub lists three categories excluded from review: dependency-management files such as package.json and Gemfile.lock, log files, and SVG files. The list is specific. It does not mean that every generated file is skipped, so check any generated code your team commits against the list rather than assuming it is ignored.
Connected context through MCP
GitHub documents that reviews can use MCP servers to pull context from issue trackers, documentation, service catalogs, and incident tools, when the context is relevant and configured. Nothing in that description connects external systems automatically. If a review needs a ticket’s acceptance criteria, someone must configure the server first.
Plan, policy, and preview conditions
The overview describes plan and organization-policy conditions and paid AI-credit usage. Some related behavior, including approval behavior, is labelled public preview. Confirm your plan and organization policy before you assume availability or cost.
Greptile
How the graph is built
Greptile’s introduction page says it connects to enabled repositories, builds a graph of the codebase covering “every function, class, and dependency,” and analyzes pull-request changes with that context. Its learning and custom context page adds that the graph can cover the repository and adjacent repositories. This is Greptile’s explanation of its mechanism. It is not an independent description of what is retained.
Rule files and scoping
Greptile documents repository-level configuration and organization defaults, with scoping to repositories, directories, or file types. It also says it can automatically index rule files, including Claude.md, AGENTS.md, and Cursor rules. If your team already keeps these files, confirm they are indexed and decide whether a directory-level scope is needed on top, because automatic indexing does not by itself limit where a rule applies.
What it learns from your team
Greptile states: “Greptile automatically learns from your reactions, tags, and what gets merged to make code reviews more relevant over time.” This is a useful feedback loop, but it means the tool’s behavior changes as your team reacts to comments. Review how reactions and merges are treated in the terms you sign, particularly if your team handles sensitive code.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Self-hosting
Greptile describes a self-hosted deployment option. The pages reviewed do not detail what data stays inside your network in that mode, so request a written data-flow description if self-hosting is part of your requirement.
CodeRabbit
Review surfaces and codebase analysis
CodeRabbit’s FAQ describes context-aware pull-request reviews for GitHub and GitLab, and a VS Code plugin that can review both committed and uncommitted changes. It says the tool analyzes a codebase and your standards. The FAQ does not spell out which standards files it reads or how far repository analysis reaches, so test path-specific rules during a trial before you depend on them.
Retention and fine-tuning statements
The FAQ says source code is not retained after a review, except when review caching is enabled. The same page says data is used to fine-tune reviews, and separately describes an opt-out from data storage. These statements cover different purposes and configurations. Together they do not support a blanket claim that CodeRabbit never stores or trains on code. Before you decide, confirm the current privacy policy, the data processing agreement, the caching setting, and the plan you are on.
Qodo
Cross-repository review
Qodo’s product page describes IDE and Git review surfaces that share one context engine, one set of rules, and the same review agents. Its Cross Repo Review, the page says, can reason across dependent repositories and across Git providers. Listed integrations include GitHub, GitLab, Bitbucket, Azure DevOps, and others. For a team whose services depend on each other, this is the most explicit cross-repository claim in this group, but it remains a vendor description of capability.
Recommended Free Tools
Rules from PR history and skills
Qodo says it mines rules from PR history, discovers skills across repositories, and enforces standards on each change. This matters for teams whose standards exist mostly as habits. Because the rules are derived from past pull requests, review the mined rules as a team before treating them as policy, since a rule learned from an old pattern may not reflect what you want to enforce now.
Best Value
![MixPad Free Multitrack Recording Studio and Music Mixing Software [Download]](https://m.media-amazon.com/images/I/71ltIxIuz1L._SL160_.jpg)
- Create a mix using audio, music and voice tracks and recordings.
- Customize your tracks with amazing effects and helpful editing tools.
- Use tools like the Beat Maker and Midi Creator.
- Work efficiently by using Bookmarks and tools like Effect Chain, which allow you to apply multiple effects at a time
- Use one of the many other NCH multimedia applications that are integrated with MixPad.
Deployment and retention claims
Qodo advertises zero data retention, BYOK (bring-your-own-key), and single-tenant, on-premises, or air-gapped deployment options. The page states: “Your code is analyzed and discarded. Nothing stored, logged, or used to train models.” This is Qodo’s claim about its zero-retention offering. Which controls apply depends on the plan and contract you sign, so check them against those terms rather than the marketing page.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Retention, training, and access are separate questions
A tool can read a lot of repository context and still handle stored data differently. Keep these questions apart when you compare vendors, because the answers come from different documents.
| Tool | Stated retention | Stated use of data for training or tuning | Stated deployment controls |
|---|---|---|---|
| GitHub Copilot code review | Not covered in the cited overview; check the data terms for your plan | Not covered in the cited overview | Not covered in the cited overview |
| Greptile | Not stated in the cited pages | Learns from reactions, tags, and merges; the cited pages do not say whether this trains a shared model | Self-hosted deployment described by the vendor |
| CodeRabbit | Source code not retained after review, except when review caching is enabled | Data used to fine-tune reviews; a separate opt-out from data storage is described in the FAQ | Not stated in the FAQ |
| Qodo | Zero data retention claimed as a vendor offering | Vendor states nothing is used to train models | BYOK; single-tenant, on-premises, or air-gapped options |
None of the cited pages states who inside each vendor can view customer code or review data. Ask for that answer in writing, along with the retention and training terms.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsHow to check rule-following on your own codebase
Vendor documentation tells you what a tool is designed to read. It cannot tell you whether it will flag your team’s rules in your code. Use this sequence before rolling a tool out.
- List every rule source you already have: instruction files, rule files, configuration, and any written standard that is not yet in a file.
- Assign each rule a scope: whole repository, one directory, or one file type.
- Create a sandbox repository or branch that mirrors your structure. Add a deliberate violation for three to five rules, with at least one rule at each scope level.
- Open a pull request and record which violations are flagged, which are missed, and which comments are noise. Edit one rule and run the test again to confirm the change took effect.
- Add a lock file change and a generated file to the same pull request, and check whether the tool comments on them, against the exclusions documented for that tool.
- Obtain the data terms in writing: retention, caching, training or tuning, access by vendor staff, and deployment mode.
What the evidence does not establish
The cited vendor pages describe how each tool gathers context and applies rules. None establishes how accurately any of them enforces a given team rule, and this article does not cite an independent comparison of rule-following accuracy. Feature names, plan terms, and privacy statements can change, so treat each claim above as something to confirm against current documentation and your contract. The verdict on which tool suits your team depends on the results of step four in the checklist above, run against your own rules.
Also note the scope of the limits. Each vendor describes its own context-gathering and data practices, and where a page says “not stated,” the answer should come from the vendor, not be assumed from the absence of a claim.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →
