tomasz-tomczyk/crit — Crit — Code Review for AI Workflows
Transcript
QuickFacts
Welcome! Today we're exploring Crit, a code review tool built for the age of AI-assisted development. Let's dive in and see how it works.
PlainEnglish
At its core, Crit gives you that familiar pull-request experience — inline comments, threaded replies, diff views — but everything runs locally in your terminal and browser. No cloud required.
QuickFacts
The stack is refreshingly simple. A single Go binary handles the backend — CLI, HTTP server, diff engine. The frontend is vanilla JavaScript with markdown parsing and syntax highlighting. It talks to GitHub and GitLab through their official command-line tools.
PlainEnglish
Here's how it fits into an AI workflow. You ask your coding agent for a feature. The agent writes a plan and runs crit. You review in your browser, leaving inline comments. The agent sees your feedback, revises the plan, and runs crit again. This cycle repeats — review, revise, review — until you approve and the agent moves to implementation.
Architecture
Under the hood, the first crit command spawns a background daemon. The daemon binds to a random port, loads your files, and tells the CLI it's ready. The CLI opens your browser to that localhost URL. If you run crit again in a different terminal window, it finds the same daemon and reuses it — no duplicate servers, your session stays intact.
Architecture
Let's zoom out and see the architecture. The CLI dispatches commands to a daemon that manages the HTTP server. The server holds session state — your file list, diffs, and comments. Sessions talk to a VCS abstraction layer that works with git, Sapling, or Jujutsu. They also sync with GitHub and GitLab through forge providers. Everything persists to local review files in your home directory.
Architecture
Crit has three modes. Code review mode shows git diffs with dual gutters and inline comments. Live mode lets you review a running web application — you click elements in the app and Crit pins comments to specific DOM locations using CSS selectors and tag chains. There's also a preview mode for static HTML. All three use the same commenting interface.
Architecture
One of the clever design choices here is the VCS abstraction. The UI calls generic methods like get changed files or compute diff, and the VCS layer translates those into the right shell commands for git, Sapling, or Jujutsu. Adding support for a new version control system is just implementing the same interface.
Architecture
Let's trace a GitHub sync. You run crit pull. Under the hood, it calls the GitHub API via the gh CLI to fetch review comments. Those comments get deduplicated against your local state using a fingerprint of author, line number, and body. Then everything gets written to your local review file. Later, when you run crit push, your new comments go back to GitHub as a single review.
Architecture
Here's a detail worth highlighting. Crit generates a session key by hashing your current directory plus the branch name. That gives you a stable twelve-character ID. Every time you review the same branch, you get the same session, so your comments and history stay connected. Switch to a different branch and you get a fresh session automatically.
Community
A quick note on the repository itself. We're looking at a tarball snapshot without git history, so we can't see commit activity or contributor stats. That said, the codebase is well-structured and the feature set is comprehensive — this is clearly production-grade work.
PlainEnglish
So that's Crit. It's a local-first code review tool designed for the fast feedback loops of AI-assisted development. Clean architecture, smart abstractions, and a focus on making review cycles as frictionless as possible. Thanks for watching!
How this was made
Lenzon read tomasz-tomczyk/crit and generated this walkthrough automatically. The narration above is the transcript of what it says.
Explain a pull request from your own repo
Point Lenzon at a repo or a pull request and get a narrated walkthrough like this one.
Try it