Code review

Code review without the comment spam.

Most AI reviewers announce themselves in your pull request. This one writes nothing to GitHub at all. Several reviewers read the change from different angles, a checking pass throws out what it cannot stand behind, and what is left is a short list in the app.

  • Findings live in Talyn — your pull request stays clean
  • Read from several angles at once, then swept again for what they missed
  • A checking pass drops the weak ones and records why it dropped them
  • Tick what is worth fixing and Talyn pushes one commit, not a thread per finding

Free plan: one review cycle. Reviewing a pull request by hand is available on any plan; reviewing every new one automatically is part of Unlimited.

Talyn — Code review

fix: retry the flaky checkout webhook

sundial/api#418 · reviewed at 4a91c02

Ready

Blockers1

getUser can return undefined

src/session.ts:41 · Logic · Reliability

Worth fixing2

This query runs once per row

src/dashboard.ts:112 · Reliability

The retry swallows the original error

src/client.ts:88 · Logic

Fix 2 selectedDropped by the checker (5)

The thing it does not do is the point

An AI reviewer that comments on your pull request has made a decision on your behalf: that its output is worth your teammates' attention. Most of the time it is not. The finding that turns out to be wrong is still there in the thread, and somebody has to reply to it, and the next reviewer scrolls past forty collapsed comments to reach the two that a human wrote.

Talyn's review writes nothing to GitHub. No comments, no approval, no requested changes. That is enforced in the reviewing agent's own system prompt, not left to its judgement. The findings appear in Talyn, and the pull request looks exactly as it did before you asked.

There is one thing it can put on GitHub, and only after you have asked it to fix something: a single short summary comment saying what it changed and what it left. That is off unless you turn it on.

Talyn

fix: retry the flaky checkout webhook

sundial/api#418 · reviewed at 4a91c02

Ready

Blockers1

getUser can return undefined

src/session.ts:41 · Logic · Reliability

Worth fixing2

This query runs once per row

src/dashboard.ts:112 · Reliability

The retry swallows the original error

src/client.ts:88 · Logic

Fix 2 selectedDropped by the checker (5)

Several readers, then somebody checking their work

A single pass over a diff finds the obvious things and misses the rest, because one reader with one prompt has one set of concerns. So a review runs several reviewers over the same change, each looking for something different — logic, security, reliability, tests, operability — and none of them aware of what the others found.

Then two more passes. A sweep reads every reviewer's output together and looks for what they all missed, which is the largest amount of context the pipeline ever assembles. And a judging pass goes through the candidate findings and throws out everything it cannot stand behind.

The judge is the part that decides whether the feature is useful. On the first real review it ran, it kept one finding out of six. A reviewer that surfaces six things when one is real has not saved you any time.

  • Reviewers who disagree are shown as reviewers who disagree — you see which lenses raised a finding
  • Two reviewers reaching the same conclusion is recorded as agreement, not duplicated as two findings
  • A rejected finding keeps the judge's reason, so the pass that drops most of them is auditable

How long it takes, honestly

Depth is a choice you make per review, and it is a real trade rather than a slider with no meaning behind it. Quick runs one reviewer and skips the sweep and the judge. Standard — the default — runs several reviewers plus both passes. Deep adds more reviewers, reads a large pull request in chunks, and uses the strongest model your connected subscription has.

The numbers are measured, not aspirational. Quick is usually under ten minutes. Standard typically takes about half an hour. Deep can take an hour or more on a large pull request. We publish those because promising 'a few minutes' is how a feature that is working comes to feel broken.

Fixing is one commit, not a thread

Tick the findings that are worth acting on and Talyn sends an agent to make those changes and push a single commit to the branch. Not a suggestion per finding for you to click through — one commit, with the work done.

There is an automatic version, and it is off by default and deliberately narrow. It will only act on a finding the judge confirmed, at or above a severity floor that defaults to blockers only, and whose quoted anchor was verified against the actual file. Each of those bounds comes from the first real review we ran, where the one finding that survived judging quoted code that was not at the line it named.

It can block a merge, if you want it to

If a review turns up a blocker — blocker severity, confirmed by the judging pass, on a review of the current head, not dismissed — the merge queue parks the pull request rather than landing it. Dismiss the finding, land a fix, or push a new commit and the queue picks it up again.

Nothing about this touches your branch protection rules. It is Talyn declining to press merge, not Talyn overriding GitHub.

Questions, answered.

No. A review writes nothing to your pull request — no comments, no approval, no requested changes. The findings appear in Talyn, grouped by how much they matter, each one saying which reviewers raised it and what it is about. You tick the ones worth fixing and Talyn pushes a single commit. The only thing it can put on GitHub is one short summary comment after a fix, saying what it changed and what it left, and that is off unless you turn it on.

It depends how deeply you ask it to look. Quick is usually under ten minutes. Standard — the default — typically takes about half an hour, because several reviewers read the change in parallel and then a further pass goes back over the whole thing. Deep can take an hour or more on a large pull request. You pick the depth per review, so a small change does not have to wait for the thorough treatment.

The review continues with what the others found. Refusing to show four good findings because a fifth agent timed out would be worse than useless. A review only fails outright when a whole phase produced nothing.

No. Two reviewers finding the same problem is recorded as agreement on one finding, with both reviewers named. Cross-lens agreement is the strongest confidence signal the pipeline produces, so it is shown rather than collapsed.

The free plan includes one review cycle. Reviewing a pull request on demand is available on any plan; having every new pull request reviewed automatically is part of Unlimited. Either way the run happens on the agent subscription you connect, so there is no separate token bill from us.