Launching Tessl Code Review

Agents can write code faster than any team can review it, and most AI reviewers make that harder rather than easier. They skim the diff instead of reading the whole PR. They forget what you already fixed or explained, and raise it again on the next round. And they don't know how your team actually reviews code, so their findings rarely match your bar. What you get is noise, maybe twenty comments about naming with the one real functional issue buried in the middle, until the team stops reading the reviewer at all.

We built Tessl Code Review to fix that, since it’s built on your team's own standards, it reads the whole PR and knows what's still open by the next round.

It’s very easy to use:

1tessl code review --pr

With no flags it reviews the current PR. If you give it no PR, it reviews your local uncommitted changes, or hand it a git range. It publishes straight into GitHub, and it runs with whatever agent your team already uses. Tessl Agent is one option, not you can choose the agent if you have a preference.

Built for a world where agents write the code

Most review tools were designed to check human-written code and had AI added later. Tessl Code Review started from the assumption that agents write most of the code.

That changes what the tool needs to be. When agents are producing the volume, the standard you review against can't sit as a setting inside someone else's product, tuned by a vendor and hidden from you. It has to be something your team owns and can change, because you'll be changing it often as you learn how your agents behave. The rest of the product follows from that.

How does it work?

You write your team's review standards once, as a skill, and Tessl applies it to every pull request. We will read the whole PR rather than just the diff. This includes the surrounding codebase, your standards, and everything already said in the thread. And within a pull request, each re-review knows what's fixed, what's explained, what's declined, and what's still open, so you're never arguing a point you settled two rounds ago.

A review that you own

We're not trying to win a contest over who catches the most bugs out of the box. Plenty of tools have spent years tuning for that, and going head-to-head on raw out-of-the-box quality is a losing game, because it isn't what makes agentic development work at scale.

Our bet is different. Tessl Code Review is a review you own, that fits your team, that you can inspect and test, and that can become a trustworthy part of an autonomous pipeline instead of one more opinion shouting from the sidelines. It's a first step toward a software factory rather than the whole thing, but a foundational one. Trusted review is what eventually lets a change reach a settled end state, act as a blocking gate, and merge on its own without a human on every diff.

Why you should consider using Tessl Code Review

Your standards live in a skill you own, not a config screen

You write your review standards once, as a skill. This is simply a plain, readable artifact your team controls, versions, and can reuse elsewhere in your factory. Most tools keep your preferences in a settings page you can't inspect or take with you. A skill is something you can read, edit, version, and point at another repo tomorrow.

Reviews you can inspect

Every review is grounded in your codebase, your team's conventions, and the pull request thread, and you can see exactly what shaped it. You're not sending code into a vendor's system and waiting for a verdict you can't unpack. When the reviewer flags something, you can trace why. That grounding is also the real cure for noise. Irrelevant comments go away when the review understands your standards and your codebase, not when you nudge a sensitivity slider.

Prove your standards work, then govern them

Most teams have no way to check that their review standard is catching what it should, or holding steady as it changes. Since your criteria live in Tessl as a skill, you can run Tessl's own review and eval tooling against them and confirm they meet your org's bar, rather than assuming they do. Your standard becomes something you can test instead of something you hope is working.

One place to manage standards across every repo

Each repo can run its own review skill, tuned to that team. As you add repos, the skill registry is where you see and manage all of them, so your review configuration doesn't turn into a pile of scattered rules as you scale. Review standards become a first-class, versioned thing the whole org can see.

Re-review that remembers the conversation

Update a pull request and the next review already knows what was fixed, explained, or declined, and looks only at what's still open. No repeated findings, no re-arguing settled points, and none of the usual mess of a comment that disappears from the diff the moment the code changes and leaves you juggling tabs to follow one resolved thread.

Under the hood

There are four steps. It builds the context: the diff against main, the PR title and summary, the comment threads and how they were resolved, and the codebase. It runs each lens (a lens is just one of your review skills) over the change to produce findings. A stateful supervisor then takes everything that came before, together with the new findings, and works out which are valid, which aren't, and which have already been handled. Finally it publishes inline comments and a summary on the PR, and replies in the existing threads.

Today it's semi-agentic: it uses language models rather than a full autonomous agent driving everything. A natural next step is bringing in more deterministic, tool-based signal, such as abstract-syntax-tree analysis, so that a lens can eventually be a set of tools that should run and pass, not only a natural-language skill.

We've using it at Tessl, and loving it!

This isn't a concept demo by any means! Tessl Code Review runs across our own monorepo as our daily reviewer, on real changes, today. We're still tuning the edges: a full-context review takes a little longer than a shallow one that only glances at the last few commits, and there's always more nit-tuning to do. But it's real, it's in our own pipeline, and it's pulling its weight.

Try it

Get started by installing the Tessl CLI and following the quickstart, then fork the default lenses into something that sounds like your team. If you'd rather see it first, watch a single change go through two rounds: a first review, a fix, and a re-review that knows exactly what's fixed, explained, declined, and still open.

Review is one of the most important parts of a software factory, because it's what lets you trust the rest of it to run. This is our first step toward making it one you own, and eventually one you can let run on its own.