The product
From a pull request to a position.
Moonray AI runs several specialised reviews over the change on top of a map of your codebase, checks it against the ticket, traces what it affects, runs the part of your test suite it touches, and where you have a staging environment, starts it up and works through the product in a real browser. All of it lands as one assessment.
What you receive
Four things, for every change.
Today's tools produce findings and leave the team to work out what it all adds up to. That is the more straightforward half of the job. This is the other half.
- A position
- Whether the change is safe to merge, in plain language. Not a list of observations for someone else to interpret.
- The reasoning
- What we found, what we ran, what passed and what failed, and how each of those shaped the view. Anyone can read through it and disagree, and that is by design.
- The gaps
- What we could not check, and why. Parts of the change nothing tested. Areas where we lacked context. We say we are unsure when we are unsure, because a team can work with that and cannot work with false comfort.
- What would make it safer
- The specific things that would improve the view: a missing test, a question for the author, or a fix.
Confidence is stated, and you set the bar.
Every finding carries its own confidence level, and those feed the overall position along with the test results and anything we were unable to check. Teams set how much they want to see, so a team that only wants high certainty findings gets exactly that.
The number of findings suppressed is reported rather than hidden, so a quiet review is visibly quiet by choice.
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.
What happens to every change
Seven checks, before we are willing to say anything.
- 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.
How teams use it
We are not moving anyone off GitHub.
GitHub stays the place where changes are discussed, approved and merged. Moonray AI adds one consolidated assessment without changing the workflow around it.
-
01
Install it
Install the app on your code host and connect the tool your team tracks work in. There is nothing to host and nothing to configure. We read the repository, build the map, and reviews begin on the next change opened. Branches, permissions, approval rules and existing checks are untouched.
-
02
The assessment lands on the pull request
Everything appears where your team already works, as comments and a written description on the pull request itself. Nobody has to learn a new tool, and nobody needs the whole team to agree before trying it.
-
03
Set the confidence bar
Choose how certain a finding has to be before it reaches the pull request. Moonray AI reports what it withheld, so a quiet review is visibly quiet by choice.
Questions about the product.
How long does a review take?
Minutes for a typical change. Longer when the change is large enough to need the deeper pass, or when the browser session has a lot of the product to work through. The assessment reports how long it took.
Does it review every pull request?
Yes, but not identically. Effort is matched to what is at stake, so a one line configuration change gets a proportionate pass and a rewrite of the payment path gets a deep one.
What does it do with our feedback?
Every time you agree with a position, overrule it, or ignore it, we learn whether our confidence was justified. That record is what the assessment is tuned against, and it is the part of this product that compounds.
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.