The core loop of working with a coding agent is short: the agent produces a diff, a human decides whether it's right. For a long time, the weakest link in that loop wasn't the agent's code — it was the handoff right after review, the moment a reviewer's precise, line-anchored reaction to a diff had to be flattened into a paragraph and retyped into a chat box. Review Notes is our answer to that specific handoff: inline comments attached directly to the lines they're about, batched up while you finish reading, and delivered to the agent with their original anchors intact.
The Handoff Nobody Designed For
Ask any developer who reviews AI-generated diffs for a living what their feedback actually looks like in their head, and it's never a paragraph. It's a series of specific, located reactions: this check should happen before the early return. This variable name is misleading two lines down. This branch doesn't handle the empty-array case. Each of those thoughts arrives already anchored to a place — a file, a line, sometimes a single token — because that's how you read code. You don't review a diff as a block of prose; you review it line by line, and your objections form at the line where they occur.
The trouble starts when the only way to hand that feedback back to the agent is a chat prompt. A chat box doesn't know about lines. It knows about text. So the reviewer's naturally located thought — this, right here — gets translated into a description of where "this" was: also, on line 40-ish, the error handling looks off. That description then has to survive being read by the agent, which has to re-locate the actual line from a rough paraphrase, guess which function you meant, and infer what "looks off" was supposed to mean. Some of that translation is lossy every time. All of it is unnecessary.
"We watched people review a diff carefully and then lose half of that care typing the summary. The review was fine. The retyping was the bug."
— Sofia Reyes, Head of Product at ETAPX
That's the problem we built Review Notes to remove: not the quality of anyone's judgment, but the format that judgment was forced into on its way out the door.
How Review Notes Works
Review Notes starts where you're already looking: the diff. Click a specific line, or a specific block, in a diff an agent produced — or in a markdown preview it wrote — and an inline comment popover opens right there, tied to that exact location. You write the note the way you'd say it out loud: short, specific, addressed to the thing in front of you rather than a description of where the thing is.
You're not committing to anything the moment you do this. The comment sits in local state — your machine's private draft of a reaction — and several things follow from that:
- You can leave more than one before doing anything else: comment on line 12, keep reading, comment again at line 80, add a third note on the agent's markdown summary — they all accumulate in place while you finish reviewing the rest of the diff.
- You can change your mind: because each comment is held as an editable, optimistic local entry rather than fired off the instant you finish typing, you can revise the wording or delete it outright if something later in the diff changes your read on it.
- Nothing reaches the agent until you say so: writing a comment and sending a comment are different actions, not two names for the same one.
- Sending is explicit and batched: when you're done reviewing, you mark your notes ready and deliver them together, as one piece of review feedback rather than a stream of interruptions.
- Sent comments clear: once a batch goes out, those entries drop off the panel, leaving only whatever you've written since — so what's visible is always just the unsent, still-private half of your review.
We built it this way so reviewing and commenting can happen in whatever order actually matches how you read — scattered, non-linear, revised as you go — with sending as a distinct, deliberate last step instead of something that happens by accident.
What the Agent Actually Receives
The payoff of keeping the anchor is what shows up on the other side of "send." Instead of a human-transcribed paraphrase — also, on line 40-ish, the error handling looks off — the agent receives your actual annotations, each one still carrying the file it was left on, the line it was attached to, and the surrounding code that was visible when you wrote it. The batch you send is structurally closer to "here are my comments on your diff" than to "here is a message describing my comments on your diff."
That distinction sounds small until you consider what the agent would otherwise have to do with a vague location. "The error handling on the login flow" could mean three different functions in a diff that touches authentication. An agent guessing wrong doesn't just waste a turn — it produces a second diff that fixes the wrong thing, which then needs its own review. We didn't need to make the agent smarter at guessing locations. We just removed the guess.
Typed Isn't Sent: Why State Has Two Layers, Not One
The most deliberate design choice underneath Review Notes is one most reviewers will never think about directly: whether a comment has merely been typed is treated as a meaningfully different fact from whether it's been sent. It would have been simpler to collapse those into one status — a comment exists, or it doesn't — and fire each one off to the agent as soon as you finished writing it. We didn't do that, because it doesn't match how review actually happens.
Reading a diff is rarely a single pass with your mind made up line by line. You flag something on line 12, keep going, and by line 80 you've either confirmed the concern or talked yourself out of it. If every comment were sent the instant it was written, that second thought would arrive too late — as a correction to feedback the agent was already acting on, instead of a revision to a note that hadn't gone anywhere yet. So the underlying model keeps three things separate: the optimistic local edit (what you've typed and can still change), the rollback (the ability to delete a comment before it's ever delivered), and the delivery itself (the moment, and the order, in which a batch actually reached the agent). None of those three collapse into the others.
"'You wrote it' and 'you sent it' are two different facts about the world, and we track them as two different facts. That's the only reason you can leave a note on line 12, keep reading to line 80, and still go back and delete the first one before any of it leaves your machine."
— Daniel Kwon, Staff Engineer, Agent Orchestration at ETAPX
The practical effect is that a review session can look messy in progress and still arrive at the agent clean: half-formed reactions get revised or deleted before they ever count, and only the ones you actually stand behind get sent.
One Onboarding Shortcut, Deliberately Simple
There's one place in the app where this distinction is intentionally flattened: feature discovery. For the narrow purpose of tracking whether someone has found Review Notes at all, writing a first comment and sending a first comment count as the same signal. Operationally, the app still treats them as different things everywhere it matters — the review panel, the send action, and the agent's incoming feedback all still separate typed from sent. But onboarding only needs to know one thing: has this person tried the feature. It doesn't need the full state machine a reviewer actually lives inside, so we didn't build it to track one there. It's a simplification made in exactly one low-stakes place, not a sign that the distinction doesn't matter everywhere else — if anything, it's precise enough elsewhere that we could afford to blur it here.
Notes and Diffs, One Cockpit
Influxx starts from a simple premise: your CLIs and your notes belong in the same place — one sidebar, one tab strip, no separate app you alt-tab to for the thinking part of the work. Review Notes is that premise applied to the single moment where notes and code intersect most directly: the review itself. A comment on a diff is, mechanically, a note. It just happens to be anchored to a specific line instead of floating in a scratchpad, and instead of sitting in a document nobody opens again, it gets delivered straight to the agent that produced the code it's about.
That's also why sending is a distinct step rather than an afterthought. A cockpit built around keeping notes and agents together only works if the notes stay yours until you decide otherwise — right up until the point where deciding otherwise means handing them to the agent as feedback, intact, in one batch.
Annotation, Not Text Generation
Most chat-based agent tools treat "give feedback on a diff" as a text-generation problem: read the change, then generate a message describing what's wrong with it. That framing seems obvious right up until you notice what it throws away — the location. A message is a linear string of words; a diff is not linear, it's a grid of files and lines, and collapsing the second into the first is where the anchor gets lost.
We treat the same task as an annotation problem instead: attach the note to the exact place it's about, accumulate as many as you want while you finish reading, then deliver them all at once with their original anchors intact. It's a small mechanical difference — comments instead of a composed message — but the payoff is real. The agent doesn't have to guess which line "the error handling on the login flow" refers to, because it was never asked to guess in the first place. It was told.
"I used to keep a second scratch file open just to remember which lines I wanted to complain about before I wrote up feedback. I don't need it anymore — I just click the line and leave the note right there, and by the time I'm done reading I've already said everything I meant to say."
— Jordan Ashby, staff engineer at a logistics-software company and Influxx user
Where a Comment Still Isn't Enough
None of this replaces conversation. If a diff is wrong in a way that needs real discussion — a different approach entirely, not a fix to this one line — that's still a chat message, not a comment thread. Review Notes is built for the far more common case: a mostly-right diff with a dozen small, precise objections scattered through it, which is exactly the shape of feedback a line-anchored comment fits and a paragraph doesn't.
Frequently Asked Questions
How is this different from leaving comments on a pull request?
A pull-request comment happens after the fact, in a hosted review UI, usually once CI has run and the change is already framed as a request to merge. Review Notes happens mid-loop, while the agent that wrote the diff is still active in its own worktree — you're giving feedback directly to the thing that can act on it immediately, not opening a discussion thread for other humans to read later.
Does it work on markdown previews, or only on code diffs?
Both. The same inline, line-anchored comment popover works on a diff and on a markdown preview an agent produced, so notes on a written plan or a summary document get the same treatment as notes on code.
What if I write a comment and then decide I don't want to send it?
Delete it. Comments live in local state until you explicitly send them, so an unsent comment can be edited or removed at any point — it never reaches the agent unless you take the separate action of sending it.
Can I leave several comments before sending any of them?
Yes — that's the intended way to use it. Comments accumulate across a diff as you read, and you decide when you're done reviewing, not comment by comment.
Does the agent see each comment the moment I write it?
No. Comments are held locally until you mark them ready and send them, at which point they go to the agent together as one batch of review feedback, not as a stream of one-off interruptions.
What exactly does the agent get when I send my comments?
Each comment arrives with the file, the line, and the surrounding context it was attached to when you wrote it — the same anchor you had in front of you, not a paraphrase of it.
Review Notes doesn't change what a good review looks like — it's still a human reading code carefully and forming specific opinions about it. What it changes is what happens to those opinions between the moment you have them and the moment the agent sees them: nothing, instead of a retyped paraphrase. The anchor you noticed is the anchor the agent gets.
