Skip to main content
Change Review · Early access

Review the change, not just the code.

Change Review starts from the ticket and gathers everything behind it. Hyrax then writes one short, plain-language review of the whole change.

Linear issue · every linked PR · review discussion · live flag state · never blocks a merge

The gap

No one sees the whole change.

Modern changes rarely live in one pull request. A single feature now spans a backend service, a web app, a mobile client and an infrastructure repo. It's written partly by AI coding agents, and it ships behind feature flags that decide who actually sees it.

Code review still happens one diff at a time. Reviewers check that each PR is well written, but no one checks that the PRs together deliver what was asked.

Code review · one diff at a time
  • acme/billing-api #2217Approved
  • acme/web-app #1482Approved
  • acme/billing-api #2203Approved
  • acme/infra #318Approved

No one checks that the PRs together deliver what was asked.

Change Review · ACME-412
4 pull requests · 3 repositories · 1 flag
  • What's changing3 sentences
  • Asked vs. built1 not met
  • Before and after4 changes
  • How it shipsInternal only
What it gathers

Change Review fills that gap. It starts from the ticket.

It gathers everything behind the ticket, then Hyrax writes one short, plain-language review of the whole change.

01

The ticket

The Linear issue, every requirement in it, and any acceptance criteria the team adds in plain words.

02

Every linked pull request

Across every repository, including the PR that hasn't merged yet.

03

The review discussion

The review discussion on each pull request.

04

The feature flags

The live state of the flags those PRs use, and where each is switched on today.

What a team gets on one page

One short, plain-language review of the whole change.

  1. What's changingTwo or three sentences anyone on the team can read, not just the engineer who wrote it.
  2. Asked vs. builtEvery requirement in the ticket, checked against the code as met, partly met, not met or needs a person. Teams can add their own acceptance criteria in plain words.
  3. Before and afterWhat a user or admin will notice, written as a diff in plain English, with sketches of affected screens or system diagrams for backend changes.
  4. How it shipsWhich flags gate the change and where each is switched on today, including flags the code reads that were never created.
  5. Sources for every sentenceEach statement links to the PR, ticket or flag it came from, so nothing has to be taken on trust.
Change Review · ACME-412
LinearACME-412 · Add usage-based billing to checkout across the web app and billing API
billing-api #2217 Openweb-app #1482 Openbilling-api #2203 Mergedinfra #318 Mergedbilling-usage-metering
Gathering the change
What's changing

Usage-based billing, with a proration gap on downgrades. Checkout now charges a base price plus metered API calls. #2217 The billing API records usage daily and the web app shows it on the invoice preview, but downgrading mid-cycle still bills the full new price. #1482

#2217acme/billing-api · Meter API calls and bill overage
Asked vs. built Add criteria
Met 7Partly met 1Not met 1Needs a person 0
  • Proration is correct when a customer changes plan mid-cycleUpgrade credits unused time, but downgrades bill the full new price. #2217
    Checking
  • Usage appears on the invoice preview before the period closesPreview shows metered usage on web; the mobile invoice view isn't updated. #1482#2217
    Checking
  • Show met (7)
ACME-412 · Before and after · How it ships
Before and after
Plan price #2217Flat monthly price onlyBase price plus metered API calls
Invoice preview #1482Shows the plan priceShows usage so far this period
Usage over the limit #2217Silently capped at the plan limitBilled per 1,000 calls above the limit
Billing webhooks #318One event at period endDaily usage events to finance
How it ships
billing-usage-meteringDevStageProdInternal only today
Why it matters now

A feature is only done when every part of it is.

01

AI writes more of the code.

Line-by-line review doesn't scale when changes arrive faster than people can read them. Change Review raises the question to “is this the change we meant to make?”

02

Work spans repositories.

A feature is only done when every part of it is. Change Review sees all the parts at once, including the PR that hasn't merged yet.

03

Shipping is decoupled from merging.

With flags, “merged” doesn't mean “live”. Change Review shows who can see the change today, not just whether the code went in.

04

More people need to understand the change.

Product managers, QA, support and leadership get a readable account of what's shipping, without reading diffs.

Early access

It helps without getting in the way.

Change Review is advisory: it never blocks a merge. It sits alongside existing code review and gives the team a shared picture of the change before it reaches customers.

Book a demo

Change Review is in early access.