Your IDE is built for writing code. But you spend most of your day reading it.

Every IDE I have ever used optimizes for the moment your fingers are on the keys. Autocomplete, snippets, refactor menus, generate-a-test. All of it aimed at producing new lines.

But look at how a day actually goes. You open a repo you did not write. You read. You follow a call chain three files deep. You find the thing that looks wrong. You think "someone should fix this," and then you… what? Write a TODO nobody grep's. Open a scratch file. Message yourself on Slack. Try to hold it in your head until you get back to it.

And that was before agents. Now Claude Code or Codex writes a large chunk of the code, and the human job shifts even further toward reading, judging, and directing. Yet the tools still assume the human is the one typing.

So I built Reado — a desktop code IDE where reading is the primary experience and the primary action is leaving a comment anchored to a precise point in the code.

The mental model: an inverted code review

You are the reviewer: you read and annotate. The AI is the committer: it implements the fixes.

The loop is three steps:

1. Read and annotate. Hover a line, hit the shortcut, leave a comment on a line range. A comment has a type (bug, refactor, performance, question, note) and is either a task (actionable work) or a note (an observation that stays out of the agent's way).

2. Send review. Open the integrated terminal, launch claude, codex or copilot with one click, then press Send review. Reado injects a prompt pointing the agent at your open tasks.

3. The agent resolves. It fetches your tasks, makes the changes, and marks each one reado task done <id> (or reado task fail <id> "<reason>" when it is blocked). A file watcher reflects the result live in the UI, and resolved comments move to history.

That is it. Read, annotate, hand off, watch it land.

Comments are files, not database rows

This is the design decision I care most about.

Every comment is a .md file under .reado/ in your project. Not a row in a hidden SQLite blob, not a cloud service. That matters for three reasons:

• They survive external edits. The agent rewrites the file you commented on, the line numbers all shift, and the comment still points at the right code. Re-anchoring is fuzzy and diff-free, and when a comment genuinely can no longer be placed it becomes an orphan rather than silently pointing at the wrong line. A comment that lies about its location is worse than no comment.
• They are yours. Plain markdown, in your repo (or gitignored, your call). Readable without Reado. Diffable. Greppable.
• They accumulate. Reading notes are not throwaway. Over time they become a knowledge base about the codebase, which Reado unifies with the project's own docs and specs, full-text searchable, with a knowledge graph linking comments, files, specs and docs.

How the agent actually reaches Reado

There is one reado binary, and it wears two hats:

• An MCP server (auto-wired into each agent's config when you open a project) exposes reado://tasks, reado://comments, reado://reading-progress and reado://bookmarks as read-only context — plus browser_* tools to drive the in-app browser preview.
• A CLI is how the agent acts: reado task list|show|done|fail, reado comment add|reply|search, reado kb search to consult the docs and specs before touching anything.

The binary is the stable contract, which means the on-disk format can evolve without breaking every agent. There is also a Claude Code plugin (and an AGENTS.md for Codex/Copilot) that teaches the agent the contract properly.

The rest of what is in there

It is a real IDE underneath, not a note-taking toy:

• CodeMirror 6 viewer tuned for reading: broad syntax highlighting, large-file virtualization, comfortable reading width, sticky scope headers, a file outline, go-to-definition, LSP support, and dedicated rendering for markdown, images, PDFs and foldable JSON.
• Reading progress. Reado knows which files you have read. When an agent changes a file you already read, you can diff it against your last-read snapshot — review only what is new to you, not the whole git diff.
• Guided pair review. The agent proposes a review route through a diff, a branch or a PR, reviews file by file and drafts artifacts; you accept or reject each one. It round-trips with GitHub and GitLab through gh/glab.
• Semantic search. Ask "where do we handle retries?" — a local SQLite/FTS5 index answers in milliseconds, and you can escalate to the agent when a keyword index is not enough. Answers from the agent are labelled as such, because you should know which kind of answer you are holding.
• Four themes grounded in actual research (dark, light, high-contrast, sepia), all held to a WCAG AA contrast floor. The research doc is in the repo, including the part where it admits there is no controlled study proving any palette reduces fatigue.
• Extensions from Open VSX — themes, icon themes, snippets, grammars. Reado reads what an extension declares and never runs its code, so the catalogue only lists extensions that will genuinely work.
• Reado Anywhere, an opt-in LAN server that lets your phone read and comment on the project over HTTPS, paired by QR with per-device revocable credentials.

Try it

Reado is MIT licensed, built with Tauri 2, React 19 and a Rust backend, and runs on macOS, Linux and Windows. Signed builds are on the releases page and the app updates itself from there.

• 🌍 Site: reado.watermelon-studio.it
• 💻 Repo: github.com/WatermelonBros/reado
• 📦 Download: latest release

It is at v1.13 and under very active development — the read → annotate → AI-resolve loop is the thing I want to get right, and honest feedback on where it breaks is more useful to me than politeness. Issues and PRs are open.

And if the idea resonates, a ⭐ on the repo genuinely helps — it is how a project like this gets found by the people it was built for.

What does your read-then-fix workflow look like today? I would like to know what I am missing.