Every editor now reviews your agent's code. Where do your comments go?

The big editors all have an agent built in now, and each of them has added a way to look at what the agent did before you keep it.

I build Reado, the IDE for reading the code your agent writes, so I have an obvious interest in this question. That's exactly why I went through each tool's own documentation instead of my memory of it. Everything below links to the vendor's page. The full side-by-side, with every source, is on a comparison page. It's free and open source, if you want to try it as you read.

Accepting a diff is the easy part

All four big editors let you look at the agent's changes and keep or throw them away. They differ in granularity:

• VS Code lets you keep or undo each inline change in a local session. Agent Host sessions don't have that per-edit workflow; you mark files as reviewed instead.
• Zed opens a Review Changes tab with every edit, where you accept or reject each hunk or the whole set.
• Cursor shows the agent's edits in a diff view where you reject what you don't want, with checkpoints to roll back.
• JetBrains lets you open each file Junie modified and roll back per file, or everything at once.

That covers the moment the change lands. It doesn't cover what happens when you read it and have something to say.

The real question is the comment

When a colleague's pull request has a problem, you don't reject the whole file. You leave a comment on line 42 that says "this will double-charge on retry", and they fix it. With an agent, that comment has to go somewhere the agent can read it, and it has to still mean something after the agent has moved the code around.

Here the editors split.

VS Code has it in the Agents window: select a range in a changed file, choose Add Feedback, and "the agent reads your comments, makes the requested edits, and resolves each comment". Resolved comments disappear from the diff. Since 1.126, in June, they're stored on the agent host, so they survive the client disconnecting. They live with the agent, though, not in your repository.

Zed's editor docs don't describe line comments for the agent. Zed is building them in Delta, a separate product in private beta, where you can comment on any line of the worktree and the comment stays "anchored to the code as it evolves".

Cursor has Agent Review to find issues in your local changes, and Bugbot for pull requests, whose findings can be handed to a cloud agent to fix. Line comments you write yourself for the local agent aren't in the docs.

JetBrains' Junie docs don't mention line comments at all.

So in the editors, line comments you write for the agent to resolve exist in one shipped place (VS Code) and one beta (Zed Delta). Cursor's Bugbot findings can be fixed by an agent too, but those are the reviewer's comments on a pull request, not yours.

The tools built for review

A second group of tools isn't trying to be your editor. They exist for this exact step.

• Orca runs several CLI agents side by side, each in its own worktree. You comment on lines of the diff and "Send to agent" turns them into one prompt; comments "follow the line if the diff shifts". It's open source under MIT, and runs on macOS, Windows and Linux. Of everything here, it's the closest to Reado.
• Warp has an interactive code review panel in the terminal: comments anchored to file and line, sent to the agent in one batch, for Warp's agent or Claude Code, Codex and others running in it. Whether comments survive edits isn't documented.
• Diffsmith is a native Mac app for local changes. The agent can read your comments through a local MCP server, and "comments whose code has changed move to Past Comments rather than vanishing".
• GitHub lets you delegate review comments on a pull request, one or a batch, to the Copilot cloud agent. That works at the pull request, after the push, not on your machine before it.

Where the comment lives decides what it's for

Line them up and the pattern is that every tool has an answer for sending a comment to the agent. The answers differ on what the comment is afterwards:

• stored with the agent, and gone from the diff once resolved (VS Code),
• sent to the agent in a batch, with nothing documented about what happens to it next (Warp),
• following its line while you review in the app, with unresolved ones carried into the next batch (Orca),
• moved to Past Comments when the code under it changes (Diffsmith),
• a conversation on the pull request (GitHub).

If you only ever need the agent to fix the thing, any of these works. If you want to come back next week and see why line 42 looks the way it does, or hand the file to someone who wasn't there, the comment has to outlive the session.

That's the bet Reado makes, and the part I'll describe as it is today. Reado comments are typed (bug, question, note…), threaded, and either a task for the agent or a note for the next reader. They're Markdown files in .reado/ inside your repository, they re-anchor when the code moves, and they turn orphan instead of pointing at the wrong line when the code is gone. "Send review" hands the open tasks to Claude Code, Codex, Copilot, Gemini, OpenCode or Cursor in Reado's terminal. It's MIT and free to use, with an optional paid Pro plan for teams coming later.

What I'd actually use

Reado isn't only the place you read. It's a full IDE: an editor with language servers (completion, go-to-definition, rename, code actions, formatting), a terminal, Git, and the agent you already run. So my honest answer is one tool for most of the day, with a few exceptions:

• To write with an agent and read what it wrote, in one place: Reado. Of everything here, it's the only one whose docs say your comments both stay in your repository and follow the code.
• If your day is mostly debugging or a specific extension: VS Code and JetBrains have large extension marketplaces, and they and Zed ship a debugger. Reado has no debugger, and installs only data extensions (themes, icons, snippets, grammars) from Open VSX, so keep that editor for those jobs.
• To run many agents in parallel: Orca is designed for that.
• For an AI reviewer on every pull request: GitHub Copilot code review or Cursor's Bugbot, which run on the pull request itself.

The side-by-side table is on the comparison page.

These products change fast, and I checked all of this on 13 October 2026. The comparison page lists every source; if something there is already out of date, tell me and I'll fix it.