Skip to content

Build1 publisher2 min readPublished

Alibaba's Open Code Review hands file picking and line positioning back to deterministic code

Alibaba ran the reviewer internally for two years across tens of thousands of developers before releasing it. The write-up is specific about how files get selected and comments get positioned, and it stops short of publishing the benchmark scores.

The Engineer · Build desk

What happened

  • Alibaba has open-sourced Open Code Review, which the dev.to write-up says has run inside the group for two years across tens of thousands of developers and detected millions of real code defects.
  • The post blames general-purpose agents such as Claude Code and Cursor for three review failures: reviewing three or four files out of a large changeset, misreporting line numbers, and burning tokens on irrelevant files.
  • Deterministic code decides which files get audited, filtering lockfiles, generated assets and test fixtures, then groups related files into bundles that each run in an isolated sub-agent context.
  • A separate positioning module maps AST coordinates back to Git diff lines before any comment is emitted, which the post says mathematically guarantees zero line drift.

Compiled by The EngineerSomething wrong?How this is made

Why it matters

  • cost Rule matching keyed to file extensions is one more config surface a platform team owns, because somebody has to decide which checks apply to which file types before the model is ever called.
  • constraint The zero-drift guarantee only reaches files the tool can parse, so parser coverage sets the boundary of the strongest claim in the design.
  • decision Teams already routing pull requests through a general coding agent now have to decide whether review deserves a separate pipeline with a fixed toolset, or stays one more prompt in the agent they run for everything else.

Splitting a diff into bundles moves the token bill in two directions at once. Each bundle gets its own sub-agent context [3], so a fifty-file changeset becomes several model calls, and each call carries its own instructions plus the rules matched to those file types [10]. The saving is in what never reaches the model: lockfiles, generated assets and test fixtures dropped by deterministic selection [3], and a fixed toolset in place of an agent given bash and told to go looking [5].

The 90 percent sits in the post's headline [7]. For that to transfer, your current setup has to be the thing it beats, which means a general agent searching freely, on repositories where a large share of changed bytes is generated or vendored. A team already sending a filtered diff and nothing else has much less to hand back.

AACR-Bench is described as 50 popular open-source repositories, 200 real pull requests across 10 languages and 1,505 ground-truth items [6]. That averages about 7.5 labeled findings per pull request [8] and 20 pull requests per language [9]. Seven and a half real defects in one pull request is not the distribution of a mainline anybody has been maintaining, so the set has been selected for pull requests that contain findings. On that population, a reviewer that reads four files out of forty loses recall fast [2]. The published description stops at the test set; the scores are not in it [6].

Position drift is the failure that gets inline AI comments muted, because a defect reported on an unrelated line costs the reviewer more time than the finding saves [2]. Mapping AST coordinates back to diff line numbers is a deterministic lookup, so it either matches the diff or it does not [4]. "Mathematically guarantee zero line drift" is a large phrase for a line-number lookup [4], and a line-number lookup is what this job wants. Positioning that way needs a parser for every language you point it at [11].

The division of labour the post argues for is the old one: deterministic code does the bookkeeping and the coordinates, the model does the semantic reasoning, because context pressure is what makes a model drop files and invent line locations [12]. Two years of internal use across tens of thousands of developers [1] means somebody else found the failure modes first. If your repositories are mostly hand-written source with few generated files, the filter has less to remove, and the saving shrinks with it.

What to watch

  • Whether the project publishes AACR-Bench scores and the token counts behind the 90 percent headline figure.
  • Which languages the positioning module ships parsers for, since the zero-drift claim only holds where a file can be parsed.
  • Whether the CI integration reports per-bundle token usage, so a team can measure the saving on its own diff mix.
Loading claim ledger
Loading source directory links
Loading share composer
Loading topic controls
Loading related stories