Paste a PR link, the Agent clones the repo, checks out the branch, runs your test suite, runs semgrep / clippy / ruff / eslint, and writes a Markdown review citing specific file:line locations. Every comment references actual code, not a pattern guess. Archive every review to Drive so the team builds institutional memory.
Every box below is a real shell call from a real run. The review comments at the bottom cite specific file:line locations the Agent saw in your code — not pattern matches on the diff.
Review github.com/acme/api-server/pull/1284 — full review please.
On it. I'll clone the repo, run your existing test suite, then run semgrep + the project's eslint config.
The Agent quotes the relevant 3–5 lines, explains why it matters in this codebase's context, and proposes a concrete fix as a unified diff.
The changed endpoint forwards `workspace_id` from the request body to the downstream service without checking ownership. Any authenticated user can pass someone else's `workspace_id` and exfiltrate their data — classic IDOR.
The other 5 `/exports*` endpoints in this repo already gate on `canAccessWorkspace`; the new one omits it.
Public GitHub / GitLab / Bitbucket repo URLs clone directly — paste the PR URL or a clone URL. For private repos, the simplest path today is to paste a unified `.patch` / `.diff` and the Agent reviews the diff without needing the whole repo. Full OAuth-based private-repo access is on the roadmap; for now, paste the diff.
Full review for routine PRs, security-only for changes touching auth / data, pre-merge checklist for ship-now PRs. Each path runs a different combination of tools — full review takes a few minutes, security-only is faster, pre-merge checklist is the fastest.
The review lands as Markdown in /code-reviews/{repo}/PR-{number}.md in Drive plus a PDF copy. Each comment cites file:line so the author can jump straight to it. After the team merges, the review stays in Drive — the next person who has to understand why something was done a particular way can read it.
Most AI code review tools regex over the diff and pattern-match generic suggestions. The Agent clones the repo, runs your build, runs your tests, runs your linters — same as a human reviewer would. When it says "this function changes the contract of caller X at /src/foo.ts:142", it knows because it grep'd the codebase, not because the diff happened to mention a name.
If your repo has .eslintrc, ruff.toml, clippy.toml, semgrep.yml — the Agent uses those configs. The findings agree with what the team already cares about, not a third-party tool's opinion. New violations in changed code rise above the noise of pre-existing ones; legacy noise is suppressed unless the PR makes it worse.
Every comment in the review names a specific file:line, quotes the relevant 3–5 lines, explains what's wrong in this codebase's context, and suggests a concrete fix. PR authors can click straight to the location — no "the model said something is off somewhere in your changes". Reviews read like a senior engineer who has context, not a list of generic platitudes.
After a PR merges, the review stays in /code-reviews/{repo}/. Six months later when someone asks "why is the rate limiter on this specific endpoint?", you grep the archive — "PR-1284, May 12: added because of incident IR-42". Onboarding new engineers becomes "read the last 30 code reviews in the auth folder". The chat conversation that led to each review is preserved too.
Strong: Python (ruff / mypy / pylint), TypeScript / JavaScript (eslint / tsc), Rust (clippy), Go (golangci-lint), Java (spotbugs / errorprone), Ruby (rubocop). For each, the sandbox has the canonical linter pre-installed and the Agent reads your project's config to align with house style. Less common languages (Zig, Elixir, OCaml, Erlang) work too but with fewer built-in static analyzers — the Agent leans more on test-suite outcomes and direct code reading in those cases.
Sign in, hand it over to the Agent — the finished file lands in your Drive.