Find the code your pull request affects, outside the diff.
A diff shows what changed. It does not show what depends on it: the subclass that overrides the method you now call, the caller still passing the old arguments, the doc page describing the old default. Those are where a reasonable-looking change breaks, and a review that reads only the diff never sees them.
Veridu is code review that knows what depends on your change. It finds the affected code first, then has two independent AI reviewers from different vendors check the change with that code in front of them.
- Subclasses that replace a method. The diff adds a call to a method; a subclass somewhere overrides it with assumptions the new call breaks.
- Callers of a changed signature. A parameter or visibility changes; code elsewhere still calls it the old way.
- Implementations of a changed contract. An interface or abstract method changes; the classes implementing it no longer fit.
- References to removed code. A method or class is removed or renamed; something still calls it.
- Documented behaviour. A default changes; the docs, and the apps relying on them, still expect the old one.
For PHP, the first four are traced automatically before review. Everything else, including documented behaviour and every other language, is left to agent reviewers that search the repository themselves.
Repository::clear() started firing two new events through $this->event(). TaggedCache, a subclass the PR never touched, overrides event() and calls setTags() on every event. The new events have no setTags(), so clearing a tagged cache threw. It shipped in v12.4.0 and was fixed in v12.10.0.
Veridu's PHP tracing found the TaggedCache override before review and handed its code to both reviewers. Both reported the fatal error at high severity.
A feature PR made over-long URL parameters return 414 instead of 404 for every app, including apps whose own not-found handler used to answer them. The server docs, unchanged by the PR, still said the not-found route is invoked.
This one is JavaScript, so no automatic tracing ran. One of the two agent reviewers searched the repository, found the docs line, and flagged the change. It called it a regression; the new status was intentional, and what the PR missed was the docs and a release note.
The PHP tracing is a capped text search, not a call graph, so it can miss dynamic calls and framework indirection. The agent reviewers search with bounded tools and decide for themselves where to look; in the Fastify review, one found the docs line and the other did not. Two examples show what the output looks like, not how often it catches something.
How is this different from a reviewer reading the diff?
A diff shows the lines that changed. The code that breaks is often somewhere else: a subclass, a caller, a doc page. Veridu goes looking for that code before review, and drops any finding it cannot ground in the repository.
Which languages get the automatic tracing?
PHP, on pull requests that change only PHP. Any pull request with other code, including JavaScript, TypeScript, Blade or Vue, goes to agent reviewers that read and search the checkout themselves, as in the Fastify example.
Is it a call graph?
No. It is a bounded text search, capped so a large repository cannot flood the review. It can miss dynamic calls, and it does not follow framework indirection such as Laravel facades, container bindings or event listeners.
Will it block my merges?
Only when both reviewers independently report the same defect and both rate it at or above your blocking threshold. Neither example on this page was blocked; both went to a human.
What does it cost?
20 reviews a month on public GitHub repos are free, no card. Solo and Team plans add private repos and a monthly allowance, with top-ups.
Public repos need only the PR URL and a free account. Private repos: connect them through the GitHub App, or run the CLI locally.
npm install -g veridu · veridu review <pr-url>