# Open Code Review: Don't Leave Code Review to the Agent's Mood

> Alibaba's Open Code Review lets code decide which files get reviewed against which rules, and leaves only the verdict to the model. Strong on coverage, deliberately low on recall; a companion to PHPStan, not a replacement.

- Author: [Halit Yeşil](https://halityesil.com/en/about/)
- Published: 2026-10-08
- Language: English
- Canonical URL: https://halityesil.com/en/open-code-review-ai-code-review-cli/
- Turkish version: https://halityesil.com/open-code-review-ai-kod-inceleme.md
- Category: Artificial Intelligence / AI
- Tags: AI agents, Alibaba, CI/CD, code review, Open Code Review, open source, PHP, static analysis
- License: https://creativecommons.org/licenses/by-nc/4.0/
- Cite as: Halit Yeşil. “Open Code Review: Don't Leave Code Review to the Agent's Mood”. halityesil.com, 2026-10-08. https://halityesil.com/en/open-code-review-ai-code-review-cli/

---

Anyone who has walked through airport customs knows the officer does not pick which suitcase to open on a whim. The scanner and a list decide first; only then does the officer look inside. An officer without a list has two modes. Either every bag gets opened and the queue locks up, or fatigue sets in by the third bag and the rest get waved through.

Most AI code review tools today work like that officer without a list. This week's radar entry tries to fix the problem from the other end: Alibaba's Open Code Review, OCR for short (not the optical character kind, though it also reads things for a living). Let's look at what it does well, where it lets you down, and how it fits a framework-free PHP project.

## What is Open Code Review?

**In one sentence:** an open source command-line tool that reads your Git diff, uses code to decide which file is reviewed against which rule, hands the actual judgement to the language model you configure, and returns comments pinned to line numbers.

[According to the README](https://github.com/alibaba/open-code-review), it began as Alibaba Group's internal code review assistant and was open-sourced after two years of serving tens of thousands of developers. It is written in Go and licensed Apache-2.0. The first npm release was on 21 May 2026; as of 6 October 2026 the latest is 1.12.12 and the repository has roughly 43.8k stars. [gittrend.io's September 2026 list](https://gittrend.io/monthly/2026-09) puts it 13th among the month's fastest risers, with 21.2k new stars.

I have not run the tool for this piece. Commands and behaviour come from the README, the documentation sources and the npm registry.

## The idea: code keeps the list, the model gives the verdict

The project's own diagnosis is candid. Ask a general-purpose agent (the README's example is Claude Code) to review through a skill, and on large changes some files never get read, comments drift off the right line, and a small prompt tweak swings the quality. The whole process is steered by language, with no hard constraint at any step.

OCR splits the job in two:

- **Done in code (the list):** which files get reviewed, bundling related files together (each bundle runs as a sub-agent with its own context), picking a rule per file, and placing each comment on the right line.
- **Done by the model (the officer):** reading the file, searching the codebase, reaching the verdict.

[The filter has six gates](https://github.com/alibaba/open-code-review/blob/main/pages/src/content/docs/en/review-rules.md): binary files, secret paths (`.ssh`, `id_rsa`, `.env` and its variants, except `.env.example`), your `exclude` list, your `include` list, supported extensions, and built-in exclusion patterns. Every dropped file comes with a reason.

**Hidden gem:** `ocr review --preview` runs that filter without spending a single token. You see what the model will get before you see the bill.

## Setting it up on a PHP project

The real prerequisite is Git 2.41 or later. The rest is npm:

```bash
npm install -g @alibaba-group/open-code-review
export OCR_NO_UPDATE=1                         # turns off the npm build's silent self-update

cd project
ocr rules check src/Order/OrderService.php     # which rule applies to this file?
ocr review --preview                           # no model call: what goes in, what got dropped and why
ocr review --from main --to feature-branch     # review the branch since it left main
```

Rules live in three layers: the `--rule` flag, `.opencodereview/rule.json` in the repository, and `~/.opencodereview/rule.json` in your home directory. If none of them match, the system rules embedded in the binary apply. PHP gets a built-in `php.md` rule (for `.php` and `.phtml`) and `composer.json` has its own.

On a framework-free PHP + MariaDB + Vue project, this is the file I would start with (the directory layout is an example):

```json
{
  "exclude": ["public/build/**", "storage/**"],
  "rules": [
    {
      "path": "src/**/*.php",
      "rule": "Every query that reaches the database must use a PDO prepared statement (prepare + execute); flag any line that concatenates a variable into SQL text. Flag endpoints that modify data without an authorisation check.",
      "merge_system_rule": true
    },
    {
      "path": "database/migrations/**/*.sql",
      "rule": "MariaDB migration: flag ALTERs that will hold a long lock on a large table, irreversible DROPs, and NOT NULL columns without a default."
    },
    {
      "path": "resources/js/**/*.vue",
      "rule": "Flag user-supplied data rendered through v-html as XSS."
    }
  ]
}
```

**Technical detail:** without `merge_system_rule: true`, your `src/**/*.php` rule replaces the built-in PHP rule instead of adding to it. Order matters too, because only the first matching rule applies to each file.

In [Vibe Coder #4.1](https://halityesil.com/en/vibe-coder-4-1-mega-prompt-coding-agents/) I wrote that spec files load as context, not as enforced configuration. This is exactly where OCR differs: the model does not decide which rule goes with which file, code does the matching. The model can still misread a rule, but it can no longer miss it.

If you have no API key, or you would rather not send code to yet another endpoint, there are two routes. The first is **delegation mode**: `ocr delegate preview --format json` and `ocr delegate rule` only produce the file list and the rules, no model is called on the OCR side, and the agent you already use does the reviewing. The repository ships plugins for Claude Code, Codex, Cursor, Kimi Code and OpenCode. The second is a local model: register Ollama under `custom_providers` as an OpenAI-compatible endpoint (the docs use `qwen3:32b` as the example). The context-window trap from [Vibe Coder #3.3](https://halityesil.com/en/vibe-coder-3-3-local-llm-coding/) applies here too.

## When it helps, and when it doesn't

**Fact:** if what you want from a large PR is an answer to "did every file get looked at?", that is where the value is. Even the delegation instructions require every file to end up marked reviewed, or skipped with a reason, and a coverage rate in the report.

**Hard truth 1, it misses things:** on the project's own benchmark (50 open source repositories, 200 real PRs, 10 languages, 1,505 issues annotated by more than 80 senior engineers), OCR beats Claude Code on precision and F1 with the same model, using about a ninth of the tokens. But the README says it plainly: recall is lower, by design. It says less, and what it says is usually right. Make it your only gate and some things will slip through. These are the project's numbers, and I could not confirm whether PHP is among the 10 languages.

**Hard truth 2, it does not scrub secrets:** `.env` files never leave your machine, but a password hard-coded in the diff goes straight to the model. [The FAQ](https://github.com/alibaba/open-code-review/blob/main/pages/src/content/docs/en/faq.md) is explicit: no built-in redaction, it is on the roadmap.

**Hard truth 3, it updates itself:** by default the npm build checks the registry in the background as you use it (with an 18-minute cooldown between checks) and upgrades itself when it finds a new release. The security policy only supports the latest version. Pin the version in CI and set `OCR_NO_UPDATE`, or yesterday's review and today's may have run on different binaries.

**Watch out:** `.vue` and `.sql` files are reviewed, but neither has a built-in rule of its own; both fall back to the generic `default.md`. Rules for your MariaDB migrations and Vue components are yours to write. One more: Java's `*Test.java` files are excluded by default, but there is no such pattern for PHPUnit's `*Test.php`. Your tests get reviewed too; add them to `exclude` if you prefer.

## Maintenance and who is behind it

| Item | Status (6 October 2026) |
| --- | --- |
| Licence | Apache-2.0, copyright "2026 Alibaba" |
| Latest release | 1.12.12 (npm, 5 October 2026) |
| First npm release | 21 May 2026; 125 releases since |
| Stars | roughly 43.8k |
| Open issues / PRs | 115 / 161 |
| Security | No published advisories; [SECURITY.md](https://github.com/alibaba/open-code-review/blob/main/.github/SECURITY.md) promises acknowledgement within 3 and initial assessment within 7 business days, and aims to fix critical and high issues within 14 days; release binaries are signed with Sigstore |
| Telemetry | Off by default |
| OpenSSF Best Practices | Gold badge |

The project comes from the [Alibaba Group](https://github.com/alibaba) team. The benchmark data is public on Hugging Face as [AACR-Bench](https://huggingface.co/datasets/Alibaba-Aone/aacr-bench) under the Alibaba-Aone account. The tool is free; the cost is whatever model you connect it to.

## How it compares

| Tool | Approach | Licence | Good for |
| --- | --- | --- | --- |
| Open Code Review | File selection in code + LLM agent, CLI | Apache-2.0 | Full coverage on big diffs, line comments in CI |
| [PR-Agent](https://github.com/The-PR-Agent/pr-agent) | LLM-based PR reviewer; a community-maintained legacy project of Qodo | MIT | Summary and comments on the PR page |
| General agent + skill (Claude Code, Codex, Cursor) | Driven entirely by language | Codex CLI Apache-2.0; Claude Code and Cursor closed source | A quick second pair of eyes on small changes |
| PHPStan / Psalm | Deterministic static analysis, no model | MIT | Type errors and dead code, on every commit |

My recommendation: keep PHPStan or Psalm. They are cheap and they never make things up. OCR sits next to them, not in their place, for what a type system cannot see: logic errors, missing authorisation checks, SQL built by string concatenation.

## In the field: where it would sit in my day

My own blog platform runs on framework-free PHP with PHPStan at level 8, and that layer stays. If I added OCR, its place would be the gate between an agent's branch and main: `ocr review --from main --to <branch>` before merging. When you work with agents, the real question is often not badly written code but the file the agent touched without asking. A list of which files were reviewed and which were skipped, with reasons, answers exactly that.

Several of the 50 mistakes in [How Not to Write PHP (in Turkish)](https://halityesil.com/phpde-kod-nasil-yazilmaz-baslica-hatalar-ve-ipuclari/), string-built SQL first among them, could each become a single line in the rule file.

At customs, trust does not come from how sharp the officer is. It comes from no bag slipping off the list. The model may well be sharp. Don't leave the coverage to it.