On this page
I started building nittle in June 2026 because of one loop I couldn’t stand anymore. An agent would finish a change, I’d open a PR so I had somewhere decent to read it, leave my comments there, and then copy every single one of those comments back into the agent by hand. File, line, what I wanted different. Again for the next comment. Again for the next round.
What I actually wanted was smaller than a PR. Find the line, highlight it, put my review on it, and have a reliable way to send all of that back to the agent that wrote it.
The Loop
The first version was called loupe, and it did one thing. It opened your local diff in the browser, let you comment on lines, and compiled those comments into a prompt you pasted into the agent. I had Opus 4.8 build it in a single unattended session and wrote that up at the time. In that post I called it a throwaway I’d never maintain. That aged poorly.
Copying comments as a prompt was the seed. Once I had it, I kept running into the next annoyance and fixing it. Pasting got old, so the agent got a local MCP server and could pull the review itself. Then I wanted it to answer me on the comment instead of in the terminal, so it got threads. Then I wanted to know which comments it thought it had handled, so it could mark them addressed and ask me to look again.
It changed when I review, too. I see and comment on agent changes before the PR process even starts now. By the time a teammate opens the PR, I’ve already been through several rounds with the agent, and they’re reading something I’ve already pushed back on instead of the first draft.
What It Does Now
As of v0.34.0, the core is still the PR shape. You comment on a line, a range or a whole file, and tag it nit, issue, question or praise. A comment can carry a suggested change, and the agent gets the original and suggested text as structured data rather than prose it has to interpret.
Return Feedback sends the review back three ways: over the local MCP server, by paste, or on stdout with nittle --wait, which works with any agent that can run a shell command. The agent replies in the thread, marks comments addressed and requests a re-review. Only I resolve. Comments from earlier rounds carry over, and the ones whose code moved out from under them show up as orphaned instead of silently vanishing.
For a big change, the triage tells me where to start. The scorecard bands size, tests, public API, dependencies and hotspots from fixed rules, so the same diff gets the same score every time. There’s no model involved, and that’s on purpose. I want the thing telling me where to look to be boring and predictable.
Review order puts dependencies first and each source file right before its test. Lockfiles and generated files collapse, and moved code gets linked to where it came from, even when it moved to another file.
Go to definition, references and hover work inside the diff for TypeScript, JavaScript, C#, Python, Go, Rust, Vue and Svelte, as long as you’ve installed the language server.
The rest is the stuff that makes it a daily tool. Vim keys with counts and chords, so 10j and gd do what you’d hope. nittle browse reviews a whole tree instead of a diff. nittle setup wires it into Claude Code, Codex, Cursor, Gemini CLI, VS Code, Windsurf, OpenCode, Zed and Copilot CLI. Reviews are plain JSON in ~/.nittle. It’s one MIT licensed binary for macOS, Linux and Windows, and the only thing it needs is git.
On macOS and Linux:
curl -fsSL https://nittle.dev/install | shOn Windows, with PowerShell 7:
pwsh -c "irm https://nittle.dev/install.ps1 | iex"Where Review Is Going
I firmly believe we should still review the code agents write. How we review it, though, my opinion on that is changing fast, and I think review itself is going to change with it.
What I want is to drop into a codebase and quickly find the pieces that matter: the workflows, the inputs, the outputs, the transformations in between. Then put my own style on what the agent did. Line comments are where nittle started, but they’re not where I think review ends up.
I don’t know what that tool looks like yet. The scorecard, the review order and code navigation are my first guesses at it, and I hope nittle keeps moving in that direction.
The Names
It’s had three names in five months, which is kinda a lot for something this small.
loupe was the first, and it collided with too much. The npm name belongs to chaijs/loupe, another agent-review CLI already uses it, and GNOME’s image viewer is called Loupe.
diffle came next, diff plus -le. It held up until moritzwilksch/diffle launched on Show HN with the same name, and every search turned into “which diffle?”
nittle is nit plus -le, a tool for nitpicking diffs. The rename doesn’t leave anything behind. The first run of nittle moves an old diffle install over in one pass: reviews, the install dir, PATH, agent plugins and MCP configs.
Coming from diffle?
Run any nittle command once and it migrates your old install. The migration guide covers what moves and how to retry.
The Changelog
The highlights, pulled from the full changelog.
-
First release. Comment on a local diff in the browser and compile the comments into a prompt to paste. Built by Opus 4.8 in one session.
-
Comment tags (nit, issue, question, praise), word-level diff highlights and the first keyboard shortcuts.
-
Browse mode, for reviewing a whole codebase instead of a diff.
-
Durable review records and a local MCP server. The agent can read the review itself, so no more pasting.
-
Threaded replies, live review sync while the agent works, and reopening a review after approval.
-
Renamed to diffle. Rebuilt on Svelte and shipped as a single self-contained binary with install scripts and self-update.
-
setup wires it into your coding agents and asks before it writes anything.
-
The deterministic scorecard, review order, moved-code detection and a since-last-review diff.
-
Renamed to nittle, with a one-pass migration. Vim keymap with counts and chords, --wait, show for single commits, and go to definition through language servers.
-
Suggested changes in comments, search across every changed file, and Python, Go, Rust, Vue and Svelte language servers.
-
Current release. Mostly accuracy fixes and launch prep, including the walkthrough above.
It’s on GitHub, the docs are at nittle.dev, and I’d genuinely like to hear how other people are reviewing what their agents write, because I haven’t figured it out yet.
