Tessl 推出 Code Review：以 lens 技能定义上下文驱动的代码审查

Most AI code review tools promise the same thing: faster reviews, fewer bugs, and less time spent manually combing through pull requests. But tools that only handle PR review can only catch bugs at the last possible moment, increasing cost and implementation time. They have no way to shift findings left and make sure agents never make the same mistake twice.

At Tessl, we believe code review should not be an isolated, black-box layer bolted onto a human development workflow. It should be a native part of a context-driven software factory. This means it’s a part of a system where the standards, knowledge, and processes that improve review will also improve code generation, maintenance, and every other agentic workflow around the repository.

This is exactly what Tessl’s Code Review does, and why it’s built differently. It is context-driven, transparent, portable, and designed for the volume and specificity required when agents, not just humans, are building software.

TL;DR

• Most AI code review tools hide your standards inside vendor configuration, and what they learn stays trapped in review.
• Tessl Code Review defines review as skills in your repo called lenses, routed by file path, so your team can see, discuss and change its standards the same way it changes code.
• Because that context is portable, lessons from review feed back into code generation and maintenance, not just the next review.
• Context-driven code review is a core part of a context-driven software factory, and a practical stepping stone towards one. Start with review, and the context you build carries into everything else.
• It’s built for agentic volume. When our PR volume rose 5-10x, 80% of our previous review bill was overage.

Get started: install Tessl Code Review on a repository, then generate your first lens from your existing code and past PRs. Follow our guide here, and you’ll be up and running in a few minutes.

The problem with current code review tools

Many existing tools are useful at first. You install them, connect a repository, add your configuration, and immediately start receiving automated comments on pull requests. It feels good to start, but over time you realise that, in many cases, the actual review process becomes hidden inside the tool.

Howeverm agents make the same mistakes over and over. A coding agent that was never told your service needs a retry policy will leave it out on every PR, and review will flag it every time. Each catch happens at the most expensive point in the workflow: after the code is written, CI has run and someone has reviewed it.

Rules tend to live in a vendor’s UI, and preferences are buried deep in configuration. Your team cannot easily see which standards are being applied, why a particular comment was produced, or how the review process has evolved over time with your processes, or styles. When review is an unconfigurable black box that doesn't match your organisation's style and concerns, you stop trusting it. This leads to humans stepubg back in to check every PR, which defeats the point of automating review in the first place.

We experienced a version of this ourselves with an agentic review tool. Our engineering team that initially configured it had, often unintentionally, encoded its own preferences into the setup. Other contributors could not clearly see the standards in advance. They did not have a practical place to discuss or agree on them. Each pull request brought new feedback, and the review process became a deterrent rather than a confidence-building part of contribution. Fixing that problem was not as easy as simply turning a setting off.

Code review should be context-driven

The defining difference in Tessl’s code review is simple: The review process is defined in context.

Your team can define skills, standards, expectations, and review behavior in Markdown. Typically, agentic teams have much of this context already, in AGENTS.md or CLAUDE.md files, skills and docs, so review starts from what's there. Those instructions are visible and they can be discussed, reviewed in pull requests, and evolve in time along with the codebase. This means that a code review is no longer a vendor-managed black box that emits comments but rather a team-owned engineering process.

Here’s an example plugin of code review skills that you can use and extend.

With Tessl, reviews are built from lenses. A lens is a focused review perspective, packaged as a skill, that tells the reviewing agent what to look for in one area, such as security, resilience at scale or your frontend conventions. A repo-owned profile file routes each lens to the files it applies to, so it only sees the changes that matter to it. Developers can see what each lens checks for before they open a pull request, understand the expectations for a particular service, file path or type of change, and propose improvements using the same workflows they already use for code. Changes to a standard are reviewed alongside the code they affect, so the review process evolves as your architecture does.

That creates clarity and buy-in. Instead of saying “the tool thinks this is wrong”, teams can say “here is the review standard we agreed on, so should we update the code or the standard?” The review system stops being something that happens to your team and becomes something your team builds and improves together.

Code review must be customised and targeted to the review context

Different repositories, and different parts of the same repository, need different standards. A generic review policy may be adequate for broad style guidance, but a frontend page, an evaluation suite, a backend service and a deployment workflow don’t carry the same risks, so they shouldn’t receive the same review.

Because each lens is routed by file path (ref in the snippet below), you can layer the right level of scrutiny onto the right parts of the codebase. For example you might have a repository-level lens that enforces broad standards, or a backend service lens focused on integration, error handling and domain constraints, as well as security, reliability and performance lenses for the highest-risk paths.

1schemaVersion: 1
2effort: adaptive
3reviewMode: standard
4requestChangesAt: major
5ignore:
6  - '**/*.generated.ts'
7  - vendor/**
8lenses:
9  - ref: ./review-lenses/backend/SKILL.md
10    effort: high
11    globs:
12      - apps/backend/**
13      - '!apps/backend/**/*.generated.ts'
14  - ref: tessl/code-review@0.2.0#review-security-and-privacy
15    globs:
16      - infra/**
17  - ref: ./review-lenses/general/SKILL.md

If you want to reach a world where humans don't need to review every PR, general code review standards won't get you there. That takes accumulated, domain-specific knowledge applied where it matters.”

Why context-driven review is an advantage

Defining review in context isn't just a different place to store configuration. It fundamentally changes what the review agent can do, and what happens to the knowledge it builds up over time. Here are two problems we tried to solve with a context-first approach.

Problem 1: Knowledge doesn’t travel between tools

Most code review tools improve their own behaviour over time, learning from feedback, comments and repository-specific configuration. But that knowledge stays trapped inside the code review. It doesn’t help code generation, improve maintenance sweeps or inform the instructions used by other engineering agents, and it never becomes a reusable asset across the software lifecycle.

That creates a frustrating ceiling. Say your review tool learns that a service should always wrap external calls in a retry policy. It gets good at flagging the omission, but the agent writing the code has never seen that rule, so it keeps leaving it out. Every pull request gets the same comment, someone fixes it by hand and review becomes a permanent corrective layer rather than a source of improvement. As agents open more pull requests, that layer gets more expensive to run and more tedious to sit through.

Problem 2: Orchestration is locked into product code

Many agentic review tools hard-code their own orchestration logic, such as deciding which model handles which task, what context each step sees, or how actions are sequenced. A typical pipeline reads the diff, runs a set of prompts and posts comments. That felt like a reasonable design when models needed tight guardrails, but it makes the product brittle. The underlying agents are improving every few months, and the tool doesn’t necessarily become more capable, because its fixed decision-making becomes the constraint.

A context-driven approach puts process design in your team’s hands. You describe what matters, how reviews should be structured and what information should influence them. A lens for a payments service might tell the agent to check idempotency and read the related migration, while a lens for the docs site stays light. The agent has the flexibility to use that context intelligently rather than following a narrow, fixed workflow, so as agents become more capable your review process becomes more capable too, without waiting on anyone’s roadmap.

Knowledge and feedback loops that you own

At Tessl, review knowledge lives in portable context that you own. The same standards that help an agent review a pull request can help an agent write the code correctly in the first place, and inform maintenance work too. That retry rule becomes part of the context your coding agents load before they touch the service, so the mistake stops at source. The result is a feedback loop:

1. Your team defines the standards and checks that matter.
2. Those standards guide code review.
3. Review surfaces missing or weak context, such as a missing convention, a recurring failure mode or a useful standard.
4. Improves that context.
5. The improved context is reused in generation, maintenance and future reviews.

The goal here is to build a factory that produces code which already meets your team’s expectations. Each lesson from review raises the baseline for everything that comes after it, so human reviewers spend less time repeating themselves and more time on the judgement calls that genuinely need them.

Built for a software factory, not just human pull requests

Most code review products were designed around a conventional model: developers create pull requests, human reviewers inspect them, an automated tool adds helpful comments and pricing assumes a relatively stable number of human contributors. That model strains when agentic development increases pull request volume.

Tessl’s Code Review works alongside human review, but it’s designed for a future where agents produce a growing share of pull requests and teams need confidence those changes are reviewed with the right depth. This is what we mean by factory native, and it shows up in two ways.

Factory-native economics

A tool priced primarily per human seat becomes a poor fit when agents are opening the pull requests. Teams pay for licences that don’t match actual usage, then pay overage when agentic development creates more review activity than the pricing model anticipated.

Before Tessl’s engineering team switched to using our own code review, 80% of our usage bill came from overage rather than the base plan. This was due to the number of PRs we created increasing by 5-10x in places. That isn’t a sustainable foundation for high-volume agentic engineering. A factory-native review tool has to assume review volume will rise substantially as more software is written by agents.

Factory-native specificity

If the ambition is to assist human reviewers, a broad, general-purpose review can be valuable. But if the ambition is for agents to produce changes with enough confidence that humans don’t need to inspect every line, general review isn’t enough.

The reliable path is specificity. Identify the areas where mistakes are most costly or most likely, then add targeted, layered lenses for those paths. Instead of hoping a single generic agent catches everything, you systematically add the right expertise to the right parts of the repository and earn confidence path by path. Human review still brings judgement, product context and accountability, and specific lenses mean it’s spent on the changes that genuinely need it.

In Summary

We’re not saying existing tools are useless, far from it! In fact, it’s often fair to use multiple tools to get different perspectives, however we should be mindful that the assumptions behind many of these tools no longer match the direction of our current and future development practices. If code review is becoming a critical control point for agent-generated software, it can’t remain opaque, isolated, generic and priced around yesterday’s workflow.

Tessl Code Review doesn’t treat review knowledge as disposable output from a separate tool. It treats it as a shared asset which is visible in your repository, improved through the same collaborative workflows you use to build software and reused across generation, maintenance and future reviews.

The future of code review isn’t more automated comments. It’s a review process that is transparent enough to trust, specific enough to catch what matters and connected enough to make your entire software factory better.

Get started: Install Tessl Code Review on a repository, then generate your first lens from your existing code and past PRs. Follow our guide here, and you’ll be up and running in a few minutes.