Agents can write code faster than any team can review it, and the reviewer that keeps up has to hold your team's bar rather than a generic one. That standard can't sit in a settings screen inside someone else's product. It has to be yours, and you'll keep changing it as you learn how your agents behave.
So we built Tessl Code Review on your team's own standards. You write them once, as a skill you own, version, and can point at another repo tomorrow. From there it reads the whole PR rather than just the diff, and it knows what's still open by the next round.
It’s very easy to use:
tessl 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, but 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
Our bet is different to other code review tools. 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 over the change to produce findings. A lens is just one of your review skills, and each one brings a different perspective: an architectural lens, a code quality lens, a security lens. 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.
We're using it at Tessl, and loving it!
While Tessl Code Review is only recently publicly available in Beta, we've been running it internally across our own monorepo as our daily reviewer, on real changes, for several months. 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.
We monitor the precision of everything the reviewer flags and how much is a real defect. We took every finding it raised on our own pull requests and had a second, more capable model judge each one against the code on whether it was a real defect, or not. 74% were confirmed as real defects, compared to ~50% we saw in comparable tools.
Try it
Pick whichever fits how you work.
Let your agent set it up. Install the setup skill, then hand it to the agent you already use:
tessl install tessl/code-review-setup
Ask your agent to set up Tessl Code Review in your repository. It reads your existing workflows, asks two questions, when reviews run and whether findings block the merge, then writes the caller workflow and explains the permissions and secret it needs.
Or ask Tessl Agent. If you're running Tessl Agent, ask it to set up code review and it does the same job without you installing anything first.
Then shape the review to your team. Fork the default lenses into something that sounds like your team, or install the lens creator and write your own:
tessl install tessl/code-review-lens-creator
It settles the review question and the bar a finding has to clear, drafts the lens, then backtests it against pull requests that already carry review feedback, so you can see what it catches before you turn it on.
Prefer to do it yourself? Install the Tessl CLI and follow the quickstart.
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.
Top comments (1)
Glad to be a part of it!