Review: Reading the Repo Behind the Diff
An illustrative case. A pull request changes four lines in a retry helper. The diff is clean: a timeout goes up, a log line gets clearer, the tests pass. A reviewer skims it in thirty seconds and approves.
The problem isn't in those four lines. It's in the ticket that asked for the change, the team rule two directories up that says retries on that service must stay idempotent, and the last three times someone fixed the same mistake in a different file.
None of that is in the diff. That's the gap CloudThinker Review is built around. Our product line for it is "Nothing breaks in production." The way we get there is by reading what surrounds the change.
Review is one of our Frontier Investigation Agents. The job is the same as in an incident: find the why, show the evidence, propose the fix, and leave the decision with an engineer.
Why diff-only review breaks
A diff tells you what changed. It doesn't tell you what the change was supposed to do, what rules the code lives under, or what this team has already learned the hard way.
Linters and pattern scanners match syntax. That catches a hardcoded secret. It doesn't catch a change that compiles, passes tests and still breaks the requirement in the linked ticket.
Human reviewers fill that gap with memory. They know the convention, they remember the last incident, they read the ticket. When they're busy, the memory doesn't make it into the review.
What Review reads
01What it reads
The change and its context
- The full diffFrom a clone of the repository
- The linked ticketJira, Confluence, GitHub or GitLab Issues
- Your rule filesAGENTS.md, CLAUDE.md and similar, by directory
- LearningsRules derived from findings you fixed
02CloudThinker Review
One pass
- SecurityInjection, secrets, cloud IAM risks
- QualityLogic errors, edge cases, performance
- RequirementsA compliance verdict against the ticket
Fast, Auto or Advanced
03Where it lands
In your pull request
- Inline commentsLine, severity, explanation, suggested fix
- Reviews workspaceTriage, vote, apply, re-run
- The next pushReviewed incrementally, fixes checked
When a developer opens a pull request on a connected repository, Review picks it up on its own. GitHub, GitLab, Bitbucket, Azure DevOps and AWS CodeCommit are supported.
It reads the full diff, the Jira ticket linked in the PR description or branch name, and relevant Confluence pages. GitHub Issues and GitLab Issues work the same way through Closes #123 style references. When a ticket carries acceptance criteria, the review records a verdict: Fully compliant, Partially compliant or Not compliant.
Review works from a clone of the repository, and it brings context from your running infrastructure. It knows when a change touches IAM policies, S3 permissions or database queries, and it flags cloud risks next to logic bugs and vulnerabilities in one pass.
It also reads the rule files your team already keeps: AGENTS.md, CLAUDE.md, CONVENTIONS.md, .cursorrules, .github/copilot-instructions.md and similar. No setup needed. Those files are scoped by directory, so for each touched file the rules in its own folder and every parent up to the root apply.
How a review runs
Findings land as inline comments with an exact line, a severity (Critical, High, Medium or Low), an explanation and a suggested fix.
You pick a workspace-wide mode. Fast is quick and cheap. Advanced splits the analysis across specialist agents for security, performance, correctness and patterns. Auto chooses between them by change complexity and risk.
Push new commits and the next review is incremental: only the new changes are analyzed. That same pass checks whether your push fixed the earlier findings.
Everything mirrors to Review → Reviews inside CloudThinker. You can vote a finding accurate or inaccurate there. An inaccurate vote needs a note on what it got wrong, and that note tunes future reviews for the repository.
What it learns from what you fix
01Finding
Review flags it
An inline comment with a line, a severity and a suggested fix.
02Fix
Your team resolves it
The resolved finding becomes evidence of how this team builds.
03Pattern
Learnings run
On a weekly or monthly schedule, recurring fixes become a rule.
04Rule
Cited and switchable
Each rule shows the past findings behind it and can be turned off.
05Next review
Applied
Active Learnings shape later pull requests in that repository.
Rule files are what your team wrote down. Learnings are what your team did.
On a schedule you set per repository (Off, Weekly or Monthly), CloudThinker looks for recurring patterns in the findings your team resolved. It writes repository-scoped rules with citations to the past findings behind them. Review applies the active ones to later pull requests.
A Learning needs a pattern, so one fixed finding isn't enough. A new repository can stay empty after its first run. Every rule shows how many findings it cites, and you can switch it off without deleting its evidence.
This is the part of the harness that's specific to Review. Resolve keeps lessons from incidents. Review keeps rules from fixes.
The bar we hold it to
01Benchmark
30 of 37 bugs caught
Real production bugs from Cal.com, Sentry, Grafana and Keycloak.
02The bar
Faulty line plus impact
The right file is not enough, and neither is a vague warning.
03In production
About 97% precision
FPT Cloud, on live merge requests, with full backend logic coverage.
We tested Review on 37 real production bugs from Cal.com, Sentry, Grafana and Keycloak, following Greptile's published methodology. Review caught 30. The full benchmark has the other five tools.
The bar matters more than the score. A bug counts as caught only when the review names the faulty line and explains the impact. Pointing at the right file doesn't count. Neither does "this looks risky."
We chose that bar because it's what a developer needs to act on a comment without redoing the review. A tool that flags many lines with no reason looks busy and still sends a person back to find the bug.
In production, FPT Cloud ran Review on live merge requests and saw roughly 97% precision, with full backend logic coverage in the evaluated set.
Design decisions
Rules come from your repo first. We read the files your team already maintains instead of asking for a new config format. Your coding assistants and your reviewer follow the same rules.
Learnings need evidence. A rule with citations is something you can audit. A rule from one bad week isn't.
Fixes stay in your hands. Apply fix commits one suggested change. Fix all with AI works through the unresolved findings. If you want to look first, ask for a separate branch:
@cloudthinker-ai autofix stacked pr
That opens a follow-up MR/PR and leaves the findings open for your review. Plain autofix pushes to the source branch without pausing, so use it when you trust the findings. CloudThinker never pushes to protected branches.
Honest limits
Review sees what a review can see. Bugs that only show up when the software runs still belong to tests, QC and human review.
The 37-bug benchmark is self-run. With 37 cases, each bug is worth about 2.7 points, so read it in bands. The top two tools were one bug apart.
Learnings take time. A quiet repository, or one with few resolved findings, won't have any for a while.
Command support varies by provider. GitHub and GitLab support every mention command. Bitbucket and Azure DevOps support review but not autofix. AWS CodeCommit supports top-level questions only.
Try it
Connect one repository and open a pull request you already know has a problem. Then ask from the review's chat drawer:
"Which of these findings would break the requirement in the linked ticket?"
"Is there a smaller fix for this finding that keeps the public interface the same?"
"Explain the impact of the critical finding, and what the fix changes."
Start a trial or book a walkthrough.