Every team's favorite
AI code reviewer
Moonray AI reviews and tests every pull request with complete context and impact, so your team merges with confidence.
GitHub-native. Start with one repository.
Add idempotency keys to the refund endpoint
7 files, +214 / -38, linked to billing-web #1902
Position
Safe to merge
It does what the ticket asked, it holds under the tests that touch it, and it behaves correctly in a browser. Nothing found rises to a reason to hold it.
How it got there
- Review Two findings raised, eleven suppressed as duplicates.
- Tests 214 affected tests run. All passed. Two written for gaps.
- Browser Refund and retry walked in staging. Nothing broke.
- Intent Matches PAY-1183.
Not checked
The webhook replay path, which your suite does not cover. Two tests written and attached. The payment provider sandbox was unreachable, so live retry behaviour is unverified.
The review gap
A clean diff is not evidence.
Every pull request ends with a decision: is this safe to release? That decision is where the risk sits.
-
A reviewer reads a list of changed files, forms an impression, and approves.
-
There is rarely time to trace what else the change might affect.
-
There is almost never time to check that it actually works.
-
It merges because it looks fine, and because the queue is long.
AI produces more changes, larger changes, and code reviewers did not write. The merge queue grew. The basis for deciding what is safe did not.
Review pipeline
The review is a pipeline, not a prompt.
Pass 01
It reads the change against your codebase
Separate passes look for logic errors, security weaknesses, performance problems and clarity, on top of a map of how your code actually fits together. A coordinating layer removes the duplicates and decides what is worth raising.
Four passes, one decision
- Logic 6 raised
- Security 3 raised
- Performance 2 raised
- Clarity 2 raised
13 raised, 11 suppressed
9 were the same problem reported more than once. 2 fell below the confidence bar you set. 2 reached the pull request.
Pass 02
It runs the change
Your own tests, scoped to the part of the suite this change affects rather than everything. Then the parts your suite never touches, which is usually where the risk is, get tests written for them.
Ran
214 passed, 0 failed, 1,388 skipped as unaffected
Not covered by your suite
refunds.go: webhook replay branch
idempotency.go: expiry boundary
Two tests written for those branches and attached to the pull request. They are a proposal. Nothing enters your repository without a person accepting it.
Pass 03
It works through the product in a browser
Where you have a staging or preview environment, we start the change up and use the affected parts of the product the way a person would. Anything that breaks comes back as a recording, with the steps, and with a judgement on whether this change caused it.
charge.duplicate
Retry created a second charge of $412.00 on order 40219.
- 1 Open refunds
- 2 Select order 40219
- 3 Retry payment
- ! Duplicate charge created
reproduced 3 of 3, not present on the commit before this change
Evaluation passes
Seven checks before a position.
- Runtime evidence Starts the change up in your own staging environment and works through the affected flows, returning recordings of what broke.
- Specialised passes Separate passes for logic, security, performance and clarity, with a coordinating layer that dedupes and decides what is worth raising.
- Codebase map A map of what calls what and what depends on what, so feedback is specific to your system rather than generic advice.
- Your standards Learns your written conventions and the rules already in your repository, and names the rule behind each finding.
- Intent check Reads the linked ticket and reports where the implementation and the request do not line up.
- Blast radius Traces outwards from the change to everything that depends on it, across files and across services.
- Test execution Runs the affected part of your suite, then writes tests for the parts of the change nothing covers.
Hard limits
Where we draw the line.
Some limits are permanent, because the product only works if teams trust it. They are stated here because they are part of what this company is, not fine print in a contract.
- We do not merge, and we do not block.
- Moonray AI gives a view and your team decides. Your branch protections, approval rules and merge permissions remain entirely yours, and nothing we do can hold a change up.
- We do not change code without being asked.
- Every suggestion is a proposal that a person accepts or rejects.
- We run tests in isolation.
- Testing happens in a separate environment with test data, never against anything live. Actions that reach outside the system, such as sending emails or taking payments, are blocked.
- We never treat quiet as safe.
- If we did not check something, we say we did not check it. Finding nothing is not the same as there being nothing to find, and we do not let the two be confused.
- We do not claim more certainty than we have.
- Telling a team something is fine when it is not is the one failure this product cannot afford, and we design against it harder than against anything else.
More detail on how we handle your code is on the security page.
Pricing
Pay for active pull-request authors.
Free
Free
Open source, and trying it on one private repository
Team
$24 / engineer / month
The team adopting it through one engineer who is tired of the queue
Enterprise
Talk to us
Organisations with procurement, and a security team with questions
Team is $30 monthly, or $24 per engineer per month billed annually. See what is in each tier.
Questions
The ones we get asked.
Does Moonray AI merge or block anything?
No, and it never will. It gives a view and your team decides. Branch protections, approval rules and merge permissions stay exactly as they are, and nothing we do can hold a change up.
Do we have to move our review off GitHub?
No. Everything lands on the pull request as comments and one written assessment, which is where your team already works. Branch protections, approvals and the merge workflow stay in GitHub.
What does setup involve?
Installing the app on your code host and connecting the tool you track work in. There is nothing to host and nothing to configure. We read the repository, build a map of it, and reviews begin on the next change opened. One engineer can turn it on without a team decision.
Where do you run our tests?
In an isolated environment with test data, never against anything live. Actions that reach outside the system, such as sending emails or taking payments, are blocked.
Do we need a staging environment?
Only for the browser evidence. With one, we start the change up and work through the affected parts of the product. Without one you still get the review, the codebase map, the standards check, the ticket check, the blast radius and the test runs, and the assessment states that runtime evidence was unavailable.
How does Moonray AI handle uncertainty?
We say so. Every finding carries a confidence level, the overall assessment carries one, and anything not checked is listed as a gap. Finding nothing is not the same as there being nothing to find.
How is this different from the reviewer we already use?
Existing tools produce findings, which is the more straightforward half of the job. Deciding what a set of observations means, and whether it is enough to merge on, still lands on a person. We take on that half, and we gather evidence from actually running the change rather than only reading it.
Which code hosts do you support?
GitHub today. GitLab is next, along with work spread across many repositories rather than two, and the access controls larger organisations ask for.
See it on your own pull requests.
We install on one repository, let Moonray AI assess the next changes your team opens, and go through what it found with you. If the position is not better than what you have now, you will know within a week.
Nothing to host. Reviews begin on the next pull request opened.