ohmakohq[bot]Deep and quiet
It reads across files and runs the code when that settles a question. Each finding is tracked until it's resolved or dismissed, so it never repeats itself.
Code Review
Coming (phase 4)More code is written than people can review
AI code review for GitHub and GitLab: a senior engineer's review on every pull request, answers to your replies, and an Autofix button for what it finds.
Let your reviewer fix what it findsIllustrative. The pull requests, findings and replies in it are examples.
From a new pull request to a fixed one.
A pull request opens
Someone on your team, or their coding agent, opens a pull request. The review starts on its own, or when someone asks for one in a comment.
Findings land on the lines they're about
Each finding sits inline, on the code it's about, with its severity. A summary opens the review, with screenshots and logs where they help.
You reply, and it answers in the thread
Reply to a finding to ask why, push back or give context, or ask it to fix that one finding. The reviewer answers in the same thread.
Someone presses Autofix
The Autofix button on the review fixes everything it found. Anyone with write access to the repository can press it, OhMako member or not.
A commit lands
It pushes the fixes to the pull request's branch, then says in the pull request what it changed and what it couldn't fix.
The review updates
The new commit gets an incremental review. Fixed findings are marked resolved, and no finding is raised twice.
In the pull request
GitHub is where you talk to it.
People talk to the reviewer in pull request comments and replies, and press Autofix there. That's the whole interface: the conversation stays beside the code, where the whole team can see it.
Your rules
Organization and repository rules, path rules, which branches and draft pull requests to review, and whether it starts on its own or when asked.
Your whole team
Anyone with write access to the repository can reply to it and press Autofix. Costs go to your organization, and its spend limits apply.
GitHub first
Code Review starts with GitHub pull requests. GitLab merge requests come as the last milestone of phase 4.
In the web app
See every review, and start or stop one.
Code Review has its own section of the web app. The web app starts and stops reviews, and the conversation stays in GitHub.
Illustrative. A sketch of the section; its pull requests and figures are examples.
Reviewing now
- #482 Add rate limiting to uploads reviewing
- #479 Move invoices to the new ledger findings posted
- #477 Bump the image library queued
- #476 Split the settings page autofixing
- #471 Retry webhook deliveries done
- #468 Rebuild the search index stopped at the spend limit
- #465 Add the audit log failed
Open PRs
- #484 Cache the price table
- #483 Add the export page
- #482 Add rate limiting to uploads
Dashboard
- Pull requests open, in review, waiting on their author, ready to merge 14 · 3 · 5 · 6
- Findings by severity, high to low 2 · 9 · 17
- Fixed, by Autofix and by hand 15 · 6
- Time to first review, and to merge 4 min · 3.2 h
- CI pass rate, and duration per pull request 92% · 11 min
- CI cost per pull request the lower of the two
- Review cost the higher of the two
Setup
- Environment
- Memories and project context
- Repositories
- Rules
- Triggers
Price
Pay for what each review uses.
The AI usage behind a review at cost plus 20%, plus the time of the machine it runs your code on, whose per-minute price is published with the product. A review stopped at your spend limit says on the pull request that it's incomplete, never that the pull request passed.
Join the invite list
Tell us which products you want first. Invites go out in waves, product by product.
Let your reviewer fix what it finds