{"slug": "add-agentic-code-review-to-your-repos-in-5-minutes", "title": "Add agentic code review to your repos in 5 minutes", "summary": "Tessl published a five-minute walkthrough by Simon Maple for adding its Tessl Code Review agent to GitHub repositories, with setup steps covering a free Tessl account, a GitHub App installation scoped to selected repositories, and per-repository code review toggles. The reviewer reads the full pull request rather than an isolated diff, scores it against team-defined standards stored in the repo as skills, and can either comment or block a merge, with review triggers set to \"When opened or requested\" by default or \"After every update\" for agent-heavy repos. The walkthrough positions automated review as a gate for code written by AI agents faster than humans can read it.", "body_md": "ARTICLE\n\n# Add agentic code review to your repos in 5 minutes\n\nLearn to add agentic code review to your repos in 5 minutes. Enhance code quality with automated reviews that identify issues before merging.\n\nSimon Maple\n\nYou may be at the stage where you have a suite of agents working hard to write code faster than any human could ever hope to meaningfully read it. These minions are great when they work well, but there’s always the chance that somewhere in that pile of PRs is the bug that takes down production on a Friday afternoon. This blog shows how you can stand up an automated reviewer that reads full pull requests, identifies and tells you exactly what is wrong, and either nudges you politely or slams the door on the merge, and you can have the whole thing running in about the less time it takes to make a coffee.\n\n## Why do I need this?\n\nYour agents are shipping code at a rate that your review process was quietly designed for a world that no longer exists. The old diff-by-diff human review worked beautifully back when a person agonised over every line, but that falls apart the moment half your team is made of silicon and never gets tired.\n\nTessl Code Review reads the whole pull request rather than squinting at the diff in isolation, scores it against the standards your team defines and actually cares about, and publishes one clean review. You decide whether it plays the role of the helpful colleague who leaves a comment or the bouncer who refuses entry.\n\nIf you're wondering why we lean so heavily on context, we've written about that [in a previous post](https://tessl.io/blog/a-context-driven-code-review-that-learns-and-improves-on-every-run). The short version is that your review standards live in your repo as skills you own, rather than being locked away in somebody else's black box, so every lesson the reviewer learns can flow back into how your agents write and maintain code too. That makes code review a natural first step towards a Context-Driven Factory, where the same context steers everything your agents do rather than just the final check.\n\nThis is a proper zero to hero walkthrough, which means by the time you reach the bottom you will have it running on a real repository and gating a real pull request, not just nodding along to a diagram.\n\n## Step one, get yourself a free Tessl account\n\nHead over to Tessl and sign in. Once you are in, pick the right organisation on the left hand sidebar, click Reviewer, and then Manage installation on the right hand side.\n\n## Step two, install the app and give access to GitHub\n\nThis is likely the familiar GitHub App dance you have done a hundred times. You grant Tessl access to the organisation and you choose which repositories it is allowed to peer into. It’s reasonable to grant a single repo to begin with, because you can always widen the net later.\n\n## Step three, switch on code review for a repository\n\nOver in your organisation's Reviewer page you will find a table of repositories that you have granted access to, and this is where you can enable code review to run on each repo. Go ahead and do that by clicking Turn on for your newly added repo.\n\n## Step four, tell it how you want to be reviewed\n\nThe moment you click Turn on, Tessl opens up the Code Review settings for that repo, and this is where you decide how much of a say the reviewer gets. There are only two decisions to make, which is refreshing for a settings screen, and you can come back and change your mind whenever you like.\n\nThe first decision is when the review runs. The default, `When opened or requested`, kicks off a review when a pull request is opened or marked ready, and again whenever someone explicitly asks for one. If you want a reviewer that keeps watch over every change, pick `After every update` instead and it will also review each new push to the pull request, which is great for agent-heavy repos where the code changes faster than anyone can keep track of.\n\nThe second decision is what the reviewer is allowed to do with its findings. `Comment only` is the default and the gentle option, publishing findings without approving or blocking anything, so the reviewer is the colleague who leaves a thoughtful note and wanders off. `Approve or request changes` gives it teeth, approving the pull request when it is happy and requesting changes when it is not, which is the bouncer at the door we promised you earlier.\n\nThere is also a handy little checkbox at the bottom, `Auto-approve after all Tessl threads are resolved`, which does exactly what it says. Once every thread the reviewer opened has been dealt with, it approves the pull request for you, so nobody has to remember to come back and give it the go ahead.\n\nBe sure to click `Save settings` if you make changes to the defaults, and you are done. It is worth knowing that changes only apply to new review runs, so anything already reviewed stays exactly as it was rather than getting retrospectively rewritten.\n\n## Step five, open a pull request and see what comes back\n\nOpen a PR against the repo and the Action gets to work. It resolves the pull request, checks out the exact head, runs the review and publishes a review complete with findings and severities, all without you hovering over it.\n\nWhen you push a fix, the next round goes through and resolves the threads whose findings the current head has actually fixed, replying on them first, so what is left open on the pull request is only the stuff that still requires a human to look at and think about. A finding that got refuted or declined stays open for the author to close, which is exactly as it should be, because the machine does not get to unilaterally decide it was wrong. And every published round signs off with the same friendly line, which is that you can mention `@tessl-code-review` to run another review.\n\n## Step six, fix the findings\n\nOnce the findings are in front of you there are two routes and both are entirely respectable. You can fix them yourself, push, and watch the next round quietly close out everything you have resolved. Or you can hand the whole review straight back to your agent, particularly if you’re running in a factory. The findings are structured and specific enough that an agent can work through them, push the fixes and leave you to re-review the result. One of those involves you typing and the other involves you supervising, and I will let you guess which one I reach for first.\n\n## Step seven, running a review again on demand\n\nYou are not stuck waiting for a new commit just to get another look. Drop a comment saying `@tessl-code-review` anywhere on the pull request and it kicks off a fresh round there and then. This is handy after a discussion has moved things on, or when you have changed something the reviewer really ought to see again before anyone merges anything.\n\n## What's next\n\nThis post gets you from zero to a working reviewer, but it's really just the opening act. In a follow-up post we'll dig into what else code review can do once it's in place, including Tessl Verifiers, security vulnerability remediation and feedback loops that iterate on your context and make the reviewer sharper with every run. Keep an eye on the blog, or better still, get your first repo set up now so you're ready to pick up where we leave off.\n\n## Try it yourself\n\n**Create your free account and run this flow on your own repositories.** Once you have a Tessl account, connect a repo, let your agent handle the setup and open a pull request, and you will have a working reviewer before your coffee has gone cold. If it finds something nasty on the very first PR, and it often does, you will wonder how you ever shipped without it.\n\nCheck out the Set up Tessl Code Review docs for more information.\n\nCOPY & SHARE\n\nSimon Maple\n\nSimon Maple is the Head of Developer Relations at Tessl, and AI Native Dev co-host. Previously, Simon was the Field CTO, and VP Developer Relations at Snyk, ZeroTurnaround, and IBM. He became a Java Champion in 2014, JavaOne Rockstar speaker in 2014 and 2017, Duke’s Choice award winner, Virtual JUG founder and organiser, and London Java Community co-leader.\n\nREADING\n\n·\n\n0%\n\nCOPY & SHARE\n\nSimon Maple\n\nSimon Maple is the Head of Developer Relations at Tessl, and AI Native Dev co-host. Previously, Simon was the Field CTO, and VP Developer Relations at Snyk, ZeroTurnaround, and IBM. He became a Java Champion in 2014, JavaOne Rockstar speaker in 2014 and 2017, Duke’s Choice award winner, Virtual JUG founder and organiser, and London Java Community co-leader.\n\nYOUR NEXT READ\n\n## Verifiers: enforce your repo's rules on every agent change\n\nTessl Verifiers are JSON-based rules in your repo that enforce coding standards on every code change, ensuring consistent rule checks beyond what linters can provide.\n\nAmy Heineike, Simon Maple\n\n### More articles by Simon Maple\n\n[See all articles](https://tessl.io/blog)", "url": "https://wpnews.pro/news/add-agentic-code-review-to-your-repos-in-5-minutes", "canonical_source": "https://tessl.io/blog/add-agentic-code-review-to-your-repos-in-5-minutes", "published_at": "2026-10-18 20:21:06+00:00", "updated_at": "2026-10-18 21:49:46.063566+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Tessl", "Tessl Code Review", "Simon Maple", "GitHub"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/add-agentic-code-review-to-your-repos-in-5-minutes", "markdown": "https://wpnews.pro/news/add-agentic-code-review-to-your-repos-in-5-minutes.md", "text": "https://wpnews.pro/news/add-agentic-code-review-to-your-repos-in-5-minutes.txt", "jsonld": "https://wpnews.pro/news/add-agentic-code-review-to-your-repos-in-5-minutes.jsonld"}}