Set strictness and comment types per directory before Greptile's first review, react to and answer every comment while it learns, and keep a person's approval as the merge gate. Public accounts name noise as their most common complaint about Greptile, and these are the settings Greptile documents for it.
When you need this
- Greptile is installed and engineers say its comments are noisy, or have started to skim them.
- Coding agents open a growing share of pull requests and reviewers want a first pass they can trust.
- Parts of a monorepo need different review depth, such as database code against front-end styling.
Evaluation criteria
Before work: set strictness by directory
How strict should Greptile be in each part of the repository?
Look forStart with strictness 2, the default on the 1 to 3 scale, in .greptile/config.json. Override it where risk differs. Set packages/db/.greptile/config.json to 1 for stricter database review while other directories stay at 2.
Before work: choose comment types and ignored paths
Which feedback does your team want, and which files should Greptile skip?
Look forcommentTypes enables logic and syntax comments, plus style, by default. If your team ignores style feedback, keep only logic and syntax. Add generated code and lockfiles to ignorePatterns, along with vendored paths. Greptile reports 30 to 50% faster reviews with those exclusions.
During work: react and reply to every comment
Does Greptile learn what your team ignores?
Look forUse thumbs up and down reactions and replies to train Greptile. Its docs say it stops commenting on ignored topics after 2 to 3 weeks. Explain context-specific mistakes in a reply so it learns where the exception applies.
During work: send fixes to your coding agent
Who applies the fixes Greptile suggests?
Look forFix with your Agent sends a comment and its file and line context, plus the suggested fix, to Claude Code, Codex, Conductor, Cursor, or Devin. Fix All sends every issue. Review the agent's diff before pushing.
Before merge: use the confidence score to route review
What should a 5/5 score change about human review?
Look forUse the score to prioritize human review. Review simple 5/5 changes faster and assign an expert when the score is low. Auto-approve, in beta, requires a clean 5/5 and a risk level at or below your limit. Leave it off until you measure which comments lead to changes.
Questions to ask vendors
- Which strictness and comment types does each directory of our repository need, and who owns those .greptile files?
- What share of Greptile's comments on our repositories lead to a code change, and how does that share move after three weeks of reactions?
- Which pull requests should run at Plus or Apex, and does our credit budget allow it?
- Does any branch protection rule count Greptile's approval, and who decided that?
- Which coding agent receives Fix with your Agent requests, and who reviews its diff before merge?
Red flags
- Comments left without reactions or replies, so Greptile has nothing to learn from.
- Strictness left at 1 across the whole repository after the first week.
- Auto-approve switched on before the team has measured which comments lead to changes.
- Authors merging on a 5/5 score without a person reading the change.
- Greptile judged by how many comments it leaves and never by how many lead to a change.
Products in this piece
Sources
- Official documentation
- 6
- Public source
- 6
- Greptile docs: Controlling nitpickiness
- Greptile docs: Memory and learning
- Greptile docs: Overview
- Greptile docs: Fix with your Agent
- Greptile docs: Auto-approve PRs
- Greptile docs: Review tiers
- Hacker News: James Hartig on Greptile at their employer (Aug 4, 2025)
- Hacker News: sebra on a three pull request trial (Jan 27, 2026)
- X: Michael on weeks of running Greptile and CodeRabbit (Dec 22, 2025)
- X: Sherwood (Sazabi) on the Greptile 5/5 (Sep 8, 2026)
- Hacker News: ej88 on Claude Code answering Greptile reviews (Jan 7, 2026)
- GitHub: whocards measures Greptile against its code-review skill (Sep 7, 2026)