Code review is one of the highest-leverage activities in software development and one of the most commonly done poorly. The problem is usually not effort — reviewers try — it is context. Understanding why a change was made, what it affects downstream, and whether a pattern is consistent with the rest of the codebase takes time that most reviewers do not have.
Lens is built to supply that context automatically. This guide walks through getting started, reading your first AI-assisted review, and tuning what Lens focuses on.
Connecting your repository
Lens supports GitHub, GitLab, and Bitbucket. To connect a repository, open the Lens dashboard at piqadot.com/app/lens, click "Add Repository," and follow the OAuth flow for your provider. You will be asked to grant read access to the repository and pull request events — Lens does not need write access to your repository.
Once connected, Lens indexes your repository history. For repositories under about 5,000 commits this takes two to three minutes. Larger repositories may take up to 30 minutes on first index. You will receive an email when indexing is complete and the repository is ready to review.
Lens listens for new pull requests via webhook. When a PR is opened or updated, Lens begins analysis automatically — there is no step where a reviewer needs to trigger it.
Reading a Lens review
When you open a pull request that Lens has analyzed, you will see a Lens comment at the top of the PR timeline. The comment is structured in three sections.
The first section is the change summary: a plain-language description of what the PR does, derived from the diff and the commit messages. This is useful even for reviewers who know the codebase well — it provides a stable reference point before diving into individual files.
The second section is the context panel. This is where Lens earns its name. For each significant change, Lens identifies related code in the repository — functions that call the modified code, tests that cover it, documentation that references it, and recent changes in the same area. Reviewers commonly miss these connections because finding them requires manual grep work. Lens surfaces them automatically.
The third section is the pattern analysis. Lens compares the patterns in the PR against the patterns in the surrounding codebase and flags divergences. This is not a linter — it does not check style rules. It looks for higher-level patterns: whether error handling is consistent with the module's existing approach, whether a new API follows the conventions established by similar APIs, whether the PR introduces a new abstraction that duplicates something that already exists.
Customizing what Lens surfaces
Lens has sensible defaults, but different teams care about different things. You can tune the focus areas in the repository settings.
The most commonly adjusted setting is the context window depth — how far back in history Lens looks for related changes. The default is 90 days, which is appropriate for active codebases. Teams working on longer-lived features may benefit from extending this.
You can also configure which directories Lens treats as high-signal for pattern analysis. If your project has a lib/ or core/ directory that establishes the canonical patterns, marking it as high-signal tells Lens to weight consistency with those patterns more heavily.
Finally, if certain paths generate noise — generated files, vendored code, large data assets — add them to the ignore list in repository settings. Lens excludes them from analysis and from the context panel, which keeps the review focused on the changes that matter.