Team Nebula
Schedule a call
Nebula Labs · source release coming· AI code review

A second look at every pull request. Never the last word.

Nebby reviews the code we ship with a read-only review identity. It reads the change and the context behind it, posts findings with a verdict, and leaves the decision with the people who own the repository.

Schedule a callHow we build

Nebula Labs · held to the same governance bar as client work

github.com · pull request
Validate tool arguments before execute #482
tm-nebbybotrequested changes
🤖 Nebby review
Needs changes: 1 blocking.
agent/src/turn.ts:95 — [HIGH] — A model can supply missing or mistyped arguments and the runner passes them straight to execute; validate them against the tool's schema first.
NEBBY_CLIENT_WORK: NO
NEBBY_VERDICT: BLOCK
Nebby — context via NebOS — changes requested: blocking findings above.
Review required
A person decides what merges. Nebby's review is advisory.
A Nebby review on a pull request, in Nebby's real format. Illustration, demo data.
Every PR
In the repositories it watches
file:line
Findings, each with a severity
PASS / BLOCK
One verdict per review
Advisory
People decide what merges

The job

Context gets lost between reviews.

As a codebase grows, important context can be missed between reviews. A fast reviewer helps, but only if it can inspect code without quietly gaining permission to ship it.

Review by people alone
  • Depth depends on who is free that afternoon
  • The reason for a change lives in a meeting nobody linked
  • Large diffs get skimmed
  • Findings arrive as loose comments with no verdict
With Nebby
  • Every pull request gets the same second look
  • The review reads the decisions and notes behind the change
  • Each finding names a file, a line and a severity
  • One verdict, and a person still makes the call

Context

It reviews the change and the reason for it.

Before it writes a finding, Nebby reads the pull request, the checked-out code, and the related decisions, meetings and notes it can reach through NebOS. When it finds none, it says so.

nebby · one review
review  agent-runtime#482  head 3f9a2c1
 
✓ pr description        read
✓ checked-out code      14 files
✓ nebos knowledge       no linked spec
✓ meetings · slack      no decision record
 
finding  turn.ts:95  [HIGH]  unvalidated tool args
cost     no infrastructure billing change
 
NEBBY_VERDICT: BLOCK
human approval still required
What Nebby reads before it posts. Illustration, demo data.

Where the team sees it

It reports in the channel, and opens its fixes as pull requests.

Nebby posts each verdict where the team already talks. A fix it proposes arrives as a separate pull request that goes through review like anyone else's, never as a push to your branch.

Slack · #eng-reviews
eng-reviewsPull request activity
NebbyAPP10:42
Reviewed agent-runtime#482. Verdict BLOCK: one high finding at turn.ts:95, tool arguments are not validated. I opened a proposed fix as its own pull request.
#483 fix(runtime): validate tool arguments before dispatchchecks passing · needs review
NebbyAPP11:05
billing-ui#501 is too large to review well in one pass. I split it into a stack, in merge order:
#502 refactor(invoices): extract the line-item table1 of 3
#503 feat(invoices): credit notes2 of 3
#504 test(invoices): credit note totals3 of 3
SA
Sam11:20
Approved #483. Thanks, merging after the second check.
NebbyAPP11:21
client-portal#77 touches client work, so I left a review and did not open a fix. It waits for a person.
Simulated Slack messages. Demo data, not a real workspace.

More than a reviewer

Review, repair, split, and know when to stop.

Review

Findings by file and line with a severity each, and one verdict per pull request.

Repair

A proposed fix opens as its own pull request, on a governed path separate from the read-only reviewer.

Split

A pull request too large to review well is split into a stack of smaller ones, in merge order.

Stop

Each review is marked client work or not. Client and website changes always wait for a person.

How it runs

Four steps on every pull request.

  1. 01

    A pull request opens

    Nebby picks it up in the repositories it watches.

  2. 02

    It reads

    The diff, the code around it, and the context behind it.

  3. 03

    It posts

    Findings by file and line, a severity each, and a verdict.

  4. 04

    A person decides

    Branch protection and your reviewers own the merge.

Head to head

How it compares.

Pick a reviewer to see where Nebby differs. Each row is drawn from that product's own public positioning.

CompareNebbyGreptileAI code review agent for pull requests
Review identityRead-onlyGitHub App; a self-hosted app needs contents read and pull-request write
Verdict per pull requestPASS or BLOCK, advisory0 to 5 confidence score; optional auto-approve (beta) on a clean 5/5 review
Reads context beyond the diffNebOS decisions, meetings and notes
Proposed fixesOpened as a separate pull request
Splits oversized pull requestsNot stated; its docs ask authors to split large pull requests
Stops on client workNot stated; filters by repo, label, author, branch and path
SourceNebula Labs, being open-sourcedNot stated; self-host charts are public

When Greptile is the better pick: You want a hosted or self-hosted reviewer that indexes the whole codebase across GitHub, GitLab, Bitbucket, Gitea and Perforce, and can auto-approve low-risk pull requests (a beta feature).

Competitor rows describe each product's own public positioning as of November 2026. Check their sites for current details.

The honest limit

Nebby can be wrong in both directions: it can flag a problem that is not one, and it can miss one that is. That is why its verdict is advisory and why proposed fixes go through a separate, governed path instead of being pushed by the reviewer itself.

Start here

Nebby runs alongside our delivery work. Ask us to walk through a real review on the call.