Tessl moves review standards into the repo, and hands teams the homework

Tessl this week launched Tessl Code Review, a pull request reviewer it is offering free during beta ^[1]. The design choice worth arguing about is not the model doing the reading, it is where the rules live: Tessl stores review standards as versioned files in the repository, written once and held as a skill the team owns and controls ^[2].

The problem it is aimed at is arithmetic, not sentiment. "Agents open more pull requests in a morning than a reviewer clears in a day, so review quality drifts with whoever is on the hook," said Mitch Ashley, an analyst at The Futurum Group who tracks agentic software development. "No one hires their way out of that." ^[4] Ashley's proposed fix is the same one Tessl is selling, standards written once, versioned in the repo and owned by the team, on the grounds that reviewers cannot enforce criteria they cannot see ^[5]. According to devops.com, agentic coding tools are now writing meaningful shares of the code merged into production repositories ^[6], and the alternative to building review capacity that scales is merging code nobody looked at closely ^[7].

Two mechanics matter more than the positioning. First, Tessl reads the whole pull request, the surrounding codebase, the team's standards and the existing thread discussion, rather than the latest diff and little else, which is what the source says most AI reviewers do ^[8][9]; every finding is meant to trace back to something concrete rather than an inference from a handful of changed lines ^[10]. Second, that context carries between rounds: after a pull request is updated, the next pass knows what was fixed, what was explained and what was declined, and concentrates on what is still open instead of re-flagging the same issues on every push ^[11]. Anyone who has argued with a bot that forgets the argument will recognise the difference between that and a convenience feature.

The ownership claim is the real bet, and it cuts both ways. Because the criteria are files, teams can start from Tessl's default review skills, fork them, edit them and point their own agent at their own repo, and if they change tools later the standards go with them, which lowers the switching cost that usually locks teams into whatever reviewer they configured first ^[12][13]. That only pays off if the team writes something down. A team that adopts the defaults and never edits them has vendor-authored criteria that happen to be readable, which is an improvement in auditability and nothing at all in standards ^[14]. Most engineering organisations do not have their review standards written anywhere; they have them distributed across three senior engineers and a Slack channel. Turning that into a file is work, and it is the kind of work that surfaces disagreements teams have been comfortably avoiding.

Tessl is not alone here. AI code review has become a crowded category over the past year, with CodeRabbit and Qodo pushing into the same territory ^[15].

Watch whether beta teams actually fork the default skills or ship them untouched, and whether the second-pass memory holds when a pull request goes four or five rounds. Portability is only real if a second tool can read the same files, which is a claim to test rather than accept ^[13].