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.
fix: retry the flaky checkout webhook
sundial/api#418 · reviewed at 4a91c02
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
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.
fix: retry the flaky checkout webhook
sundial/api#418 · reviewed at 4a91c02
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
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.
Talyn does this for you.
Mission control for your GitHub pull requests, running on the Claude or ChatGPT subscription you already pay for. Free for three tasks at a time.
Keep reading
Feature
Fix a PR with an agent
Failing tests, conflicts, review comments
Read moreFeature
Merge queue
Fixes it, then lands it
Read moreFeature
Skills
Your playbooks, on any PR
Read moreCompare
Talyn vs CodeRabbit
CodeRabbit reviews your pull request by commenting on it. Talyn reviews it without writing anything to GitHub, then fixes what you tick in one commit. Here is where each one is the better answer.
Read the comparisonCompare
Talyn vs Graphite
Graphite is built around stacked pull requests, with a merge queue and AI review on top. Talyn is built around getting the pull requests you already have to green and merged. They overlap less than the feature lists suggest.
Read the comparisonCompare
Talyn vs Greptile
Greptile reviews a pull request against a graph of your whole codebase and comments inline. Talyn reviews it with several agents that never touch GitHub, throws out what a judge cannot stand behind, and fixes the rest in one commit.
Read the comparison