Reading the whole repo, not just the diff
A diff is a poor unit of understanding. Three changed lines can be perfectly correct in isolation and still break an invariant that lives in a file the diff never touches. Review tools that read only the patch are structurally blind to that class of bug.
One brain per repo
Before GitZoid reviews anything, it builds a private brain for the repository. That brain learns the conventions, the module boundaries, the dependency graph, and the auth surface. It is per tenant and per repo, so the context never leaks across customers.
When a pull request opens, the diff is read against that model rather than on its own. A new call to an internal service is checked against how the rest of the codebase reaches that service. A changed query is read against the schema and the indexes it depends on.
| A diff-only reviewer sees | GitZoid sees |
|---|---|
| The lines that changed | The lines, plus the architecture they land in |
| The patch in isolation | The conventions, module boundaries, and auth surface |
| Syntax and local logic | Whether the change breaks an invariant elsewhere |
A concrete example
Consider a change that adds a fetch() to a request handler:
return fetch(req.query.url)
On its own, this is just a network call. Read against the repo, GitZoid knows this handler is reachable from an unauthenticated route and that every other outbound request in the codebase passes through an allowlist. That context is what turns three benign-looking lines into a flagged SSRF with a suggested fix.
Why context beats cleverness
The hard part of review is not generating prose. It is knowing which of a thousand possible comments actually matters here, in this codebase, on this change. Architecture is the filter. Reading the whole repo is how GitZoid earns the right to stay quiet on the noise and speak up on the one finding that counts.