A reviewer that has read the codebase.
Most automated review is pattern-matching on a patch with no idea what the rest of the system does. This one has the repository checked out and the tests running, so it can go and look.
Findings you can check, not opinions.
Because Nova can build and test your code, its comments come with proof. If it says a change breaks something, it can name what. If it says a case is untested, it can write the test that fails.
Findings stay with the files, tests and selected tool results used to reach them. Your configured rules decide whether Nova can post a GitHub comment or must ask first.
Where your rules allow it, the fix can be published as its own branch and pull request. That approval covers one specific action rather than granting standing repository access.
- · Run your test suite against the change, and against what it replaces
- · Follow the change out to the callers it affects, beyond the files in the diff
- · Check it against decisions your team made before, and say which one
- · Write the failing test for a case the change does not handle
- · Run a changed browser journey and attach the evidence
- · Prepare a fix on a local branch and request approval before publishing it
It gets better at your codebase specifically.
It reads explicit project knowledge
Architecture notes, conventions and prior decisions live in an inspectable project tree, so a review can cite the source rather than inventing team memory.
Corrections are attributable
A reviewer can correct Nova or the underlying project guidance, preserving who changed the guidance and why.
It stays tenant-scoped
Stored guidance and context are not shared across customers. Relevant review context may still go to the configured AI provider.
A reviewer that comments on everything gets muted.
The way automated review fails is volume. Fourteen comments on every pull request and your team stops reading it within a fortnight, at which point it is worse than nothing, because people have learned to scroll past.
So what it comments on is something you set and change, and you can see whether a change made reviews more useful or just louder. Most teams start narrow, one kind of finding on one repository, and widen when the signal earns it.
Point it at a pull request you already reviewed.
Ideally one a person has been through, so you can compare. That comparison is the fastest honest read on whether this is useful for your codebase.