Greptile, code review that knows the rest of the repository

Greptile, code review that knows the rest of the repository

Most automated code review tools look at the diff alone. They see what changed and comment on it in isolation, so they catch typos and miss what matters: a change breaking a call in another file, or a fix reverting an earlier one.

Greptile approaches it differently. Before reviewing, it indexes the whole repository into a graph describing functions, classes, variables, and the links between them, then traces the changed code's dependencies across files. The effect is that comments concern a change's consequences rather than its appearance.

What the difference is

A review based only on a diff answers "does this fragment look correct". A review based on a graph answers "does this change break something elsewhere".

That distinction shows in concrete cases. Changing the signature of a function called in seven places is one line in a diff, while its consequences sit in seven files the diff does not contain. Removing an empty value check looks innocent until you see that the only call to that function comes from somewhere an empty value is normal.

The tool can also reach into change history, so it recognises a new fix reverting something deliberately repaired earlier. That is one of those things a human reviewer usually misses, since nobody remembers a change from six months ago.

Indexing is the consequence of that approach. The repository must be analysed once on connection and updated on changes, which takes a moment on a large project and requires access to the code.

How it works in practice

Connecting means installing the application in your organisation on the code hosting platform and naming the repositories. From then on every new pull request receives comments.

More important than connecting is configuring what the tool should talk about. By default it comments on anything it deems worth noting, and on a first run against an older repository that can mean dozens of remarks on one change.

The settings live in a greptile.json file at the repository root and take precedence over the organisation settings from the dashboard. They are read from the pull request's source branch, so a configuration change can be tested in the very pull request that introduces it.

A newer format sits alongside that file: a .greptile/ directory holding config.json. It accepts the same fields and adds settings that cascade per directory, which in a monorepo lets you tighten review inside one package alone. Where both sit in the same directory the folder wins and greptile.json is ignored. The plain greptile.json still works, so the examples below remain valid.

{
  "instructions": "Do not raise formatting comments, we have an automatic formatter. Always check whether a new database query has an index.",
  "commentTypes": ["logic", "syntax"],
  "ignorePatterns": "legacy/**\n*.generated.ts",
  "strictness": 2,
  "triggerOnDrafts": false
}

The instructions field takes plain language and works better than a list of disabled categories alone, since it describes what matters in your project. A team with an automatic formatter needs no comments about spacing, and a team after an incident with a missing index wants them on every change.

Spend the first week refining rules. A tool raising ten comments of which seven miss the point will be ignored by the team within a month, and that is the commonest reason rollouts fail.

What to look for in the output

Automated review has three levels of usefulness worth distinguishing, since they shape how a team treats the comments.

The first level covers things any linter catches: an unused variable, a missing type, inconsistent naming. The value is slight, since the build pipeline should catch those, and before anybody opens a pull request.

That level can simply be switched off. The commentTypes field takes four values, logic, syntax, style, and info, and all of them are on by default. Passing a list replaces that default set, so keeping only logic makes the tool silent about syntax, style, and contextual notes while still speaking up on logic.

{
  "commentTypes": ["logic"],
  "strictness": 3
}

The strictness field takes values from one to three, where one means raising everything and three only critical matters. The default of two is a good start, and three rescues a rollout where the team has already stopped reading the comments.

The second level covers logic errors visible in context: an unhandled edge case, a query without an index, a call that can return an empty value unchecked. That is where the tool's main value sits and where its effectiveness deserves measuring.

The third level covers remarks about architecture and intent. The tool may notice that a new function duplicates an existing one, without knowing why the team chose duplication. Treat those not as binding but as a question worth considering.

The practical conclusion: do not set the tool as a merge blocker. Automated review is a pre filter, and the decision belongs to a person who knows the business context.

Rolling out to a team

A tool switched on without preparation usually ends with nobody reading its comments a month later. A few steps change that outcome.

The first is connecting one repository rather than all at once. Pick an active but non critical project and watch what the tool raises for two weeks.

The second is keeping a simple list: for every comment, note whether it landed, missed, or was irrelevant. After twenty pull requests you have a number to base the rollout decision on.

The third is adding rules as you go. Every off target comment is a candidate for a rule saying not to raise it. Every missed bug is a candidate for a rule saying to watch for it.

Rules can also be narrowed to a directory or a file type rather than applied across the whole repository. That matters in a project where part of the code carries different requirements from the rest.

{
  "customContext": {
    "rules": [
      { "scope": ["src/api/**/*.ts"], "rule": "Every route must validate its input against a schema" },
      { "scope": ["src/db/**"], "rule": "Always flag a query without an index" },
      { "scope": ["**/*.test.ts"], "rule": "Do not comment on repetition in tests" }
    ]
  }
}

The scope field takes path patterns with stars and braces, so one rule can cover several directories at once. The tool also reads guideline files already sitting in the repository, those written for coding assistants for instance, so some context comes for free.

The fourth is deciding who owns the comments. Without that, automated remarks hang unresolved, since everyone assumes somebody else will handle them. The simplest rule says the change's author resolves every comment: fix it or answer why not.

The fifth is a quarterly review. A repository changes, so rules written at the start may stop fitting, and comments that once were noise can become relevant.

What it means for the review process

Automated review changes how a reviewer's work is distributed rather than how much there is. Technical matters pass through a filter earlier, so a person can attend to what automation cannot see.

Three questions stay with people whatever the tool. Does this change solve the right problem, since correctly written code doing the wrong thing passes any automated review. Does it fit the direction the project is heading, since automation does not know the team's plans. Is the maintenance cost acceptable, since that is a judgement rather than a fact.

Remember too that automated review does not excuse tests. A comment about an unhandled edge case is valuable, but a test is what keeps that case from returning in six months. Tools like Vitest and a review bot work on different layers and do not replace each other.

For teams using a coding assistant, Cursor for instance, one more effect appears. More code arrives faster, so review rather than writing becomes the bottleneck. That shift in proportions is exactly what made automated review economically sensible.

Pricing

The billing unit is a credit rather than a pull request. One completed standard review costs one credit, one review with code execution in the T-Rex variant costs three. Skipped reviews count for nothing.

Seats are counted by active developers, meaning authors who received at least one completed review in the billing period. Somebody who opened nothing needing review that month generates no cost.

Once a given author's 50 credits run out, each further review of theirs becomes flex usage at 1 USD per credit. The pool is not shared across the team: every author works through their own 50 credits first, so one person opening a hundred pull requests does not eat everyone else's allowance.

The ceiling on that flex usage is set in the organisation settings. On reaching the cap Greptile skips reviews that would incur extra cost until the billing period ends or the limit is raised, while authors still inside their own 50 credits keep receiving reviews. A limit set to zero switches flex usage off entirely.

Two discounts sit outside the price list. Open source projects under MIT or Apache licences can get the tool free on application, and pre Series A startups with under two million dollars of revenue in the past twelve months pay half. Annual and multi year billing is quoted individually, with no rate published up front.

When estimating cost, count reviews per month rather than headcount. A ten person team opening two hundred pull requests generates different usage from a team of the same size opening forty.

Compare that cost against human review time too. If the tool catches one real bug per twenty pull requests, and fixing a bug in production costs a day of work, the arithmetic closes quickly. If it catches only typos, it never closes.

Greptile against the alternatives

The last row is not competition but groundwork. A formatter, a linter, and type checking belong in the build pipeline whatever review tool you choose. Without them, automated review wastes time on things a machine settles without a language model.

Choosing among the first rows depends on repository size. On a small project the difference between diff based and graph based review is slight, since all the code fits in context anyway. On a repository of several hundred thousand lines that difference decides whether comments land.

The second factor is the stakes. On an internal application used by ten people, a bug reaching production costs an hour. On a system handling payments the same bug costs considerably more, so a more effective tool pays off even at a higher price.

A third is where the code is allowed to go. Every option above ships the changed fragment to a vendor, so if company policy forbids that, self hosting is what remains. Qodo offers an open review engine you run in a container with your own keys, with the caveat that the project was spun out of the company and is community maintained as a legacy solution, while the paid offering runs on a different engine.

It also pays to run two tools side by side for two weeks on the same repository. Comparing their comments on the same change proposals gives an answer no comparison table replaces, since effectiveness depends on the programming language and the project's style.

Security and code access

A tool indexing a repository has access to all the code, so settle a few things before rolling it out inside a company.

The first is permission scope. An application installed in an organisation gets access to named repositories rather than to everything by default. Start with one and expand deliberately rather than granting organisation wide access immediately.

The second is where the index lives. The graph is built on the service side, so code physically goes there. Under compliance requirements you must check where that data sits and how long it is kept, and under stricter ones consider a self hosted variant.

The third is secrets in the repository. If keys typed in by mistake sit somewhere in the change history, indexing covers them too. That is a good moment to review the history and rotate what needs rotating, whatever tool you choose.

The fourth is directories worth excluding. Generated code, test data, and vendored dependency directories add nothing to a review while enlarging the index and lengthening analysis.

Exclusions go in the same configuration file, using the syntax familiar from a version control system's ignore file.

{
  "ignorePatterns": "**/node_modules/**\n**/*.snap\n**/generated/**\ninfra/secrets/**",
  "excludeAuthors": ["dependabot[bot]"]
}

The second field solves a separate problem: pull requests opened by a dependency update bot need no review, and at ten a week they generate cost and noise. The same applies to draft pull requests, unless you deliberately opt them in.

Common mistakes

The first is enabling the tool with no rules. The team then gets dozens of comments on its first pull request, treats them as noise, and stops reading.

The second is setting review as a merge condition. Automation lacks business context, so blocking a change on its comment leads to working around the safeguard rather than to better code.

The third is dropping static analysers. A tool built on a language model replaces neither a formatter nor type checking, and spending it on those tasks is costly and less effective.

The fourth is not measuring effectiveness. Spend a month noting how many comments landed, since without that number the renewal decision rests on impressions.

The fifth is connecting repositories holding sensitive data without checking terms. The tool indexes code, so under compliance requirements you must know where that index lives.

The sixth is treating automated review as a replacement for human review. It is a pre filter saving a reviewer's time rather than a decision maker on design questions.

FAQ

How does Greptile differ from other code review tools?

Before reviewing it indexes the whole repository into a dependency graph, so it analyses a change's consequences in other files rather than the diff alone. That translates into catching logic errors arising from dependencies invisible in the changed fragment.

What does Greptile cost?

The Starter plan is free for one active developer and grants 50 credits a month. Pro costs 30 dollars per seat monthly and also includes 50 credits per seat, with each further review by the same author charged at a dollar. Enterprise is quoted individually.

Does it replace human review?

No. It catches technical errors and cross file consequences but knows neither the business context nor the reasons behind the team's earlier decisions. The right arrangement is automation as a pre filter and a person as the decision.

Does it work with GitLab?

Yes, it supports both GitHub and GitLab, and reviews appear as comments on the pull request. Configuration means installing the application in your organisation and naming the repositories to index.

How do I reduce off target comments?

Through rules written in plain language: what to ignore, what to watch for, and which directories to skip. Spend the first week refining them, since a tool producing much noise stops being read, and then the quality of its remaining comments no longer matters.

Documentation sits on the project site, and comparisons with other tools appear in a code review tool roundup.