Review tuned to how generated code fails
Generated code fails differently, and your linter was built for the other kind
Invented APIs, helpers rewritten three directories from the original, errors swallowed to make a test pass, files nobody asked it to touch. Second Pass looks for those four things and stays quiet about everything else.
The problem
Review became the bottleneck and the tools did not follow
A reviewer facing two thousand generated lines a day skims, and skimming is exactly the wrong response to code that is confidently plausible everywhere and wrong in four specific places. Generic linters flag style. A general-purpose AI reviewer produces forty comments per pull request, which is the same as producing none.
The insight
Precision is the product. Recall is what everyone else optimises
A reviewer will read four findings and act on them. They will not read forty, and after the second pull request of forty they stop reading entirely — which means a high-recall reviewer with poor precision is worse than nothing, because it consumes the attention that would have caught the real bug. Second Pass detects four specific failure modes with concrete evidence for each, and reports nothing it cannot point at a line for.
Four targeted detectors: call-site symbols absent from the defined and imported set, normalised token-signature matching for duplicated helpers across files, catch blocks that neither rethrow nor log, and files outside the task-declared scope.
How it works
Four steps, no data science team
What changed, and what the task said it would change.
Each produces a line, a span and a reason, or produces nothing.
No taste, no style, no restating the diff.
High-severity findings can fail the build. Low-severity ones never do.
Who it is for
The engineer reviewing code they did not write
Teams where agents write most of the code and humans review it. The pain arrives when generated volume outruns review attention, which is most teams past the first quarter of adoption.
Pricing
- –All detectors
- –PR comments
- –Evidence spans
- –Private repos
- –Cross-repo symbol table
- –Custom declared-scope rules
- –Severity gating
- –Self-hosted
- –Custom detectors
- –SSO
- –Finding analytics
Competition
What exists, and what it does not do
| Who | What they do | The gap |
|---|---|---|
| CodeRabbit, Greptile, Graphite | AI review that comments on pull requests. | They optimise coverage and produce volume. The complaint about all of them is the same and it is about noise, not about missing things. |
| ESLint, Ruff, SonarQube | Static analysis for style and known bug patterns. | Excellent at what they do and blind to the generated-code failure modes, which are semantic rather than syntactic. |
| Type checkers | Catch invented symbols in typed languages, for free. | Genuinely overlapping, and the reason the invented-symbol detector matters most in dynamic languages and across module boundaries a checker does not follow. |
| Reading it properly | What the reviewer intends to do. | Works, does not scale, and is precisely what stopped happening when volume multiplied. |
The category is loud, well funded and shipping fast, and "fewer, better comments" is a positioning claim that any incumbent can adopt in a release note. The type checker also eats one of the four detectors outright in typed codebases, which is most of the ones worth selling to. This is the weakest standalone product of the five in this group and the strongest feature — it belongs inside Provenance, where knowing which lines a model wrote is exactly what tells you where to point it.
Market
Priced against the code-review budget, next to the tools already charging per seat
Enormous and contested. Winning requires a precision reputation rather than a feature list, which is earned slowly and lost in one noisy release.