Communicate Ideas Visually: Let AI Run the Feedback Loop

I wrote about htmldrop earlier — a small skill + CLI that makes sharing HTML from Claude Code a one-command thing. The premise was simple: AI lets us generate more than ever, so the least we can do is reduce the friction of letting someone actually open and read what we made.

I ended that post with half the equation: Sharing is only half the problem. The other half is discussion — the back-and-forth, the "I read this, and here's what I think about this specific part." Today that lives in chat threads that get buried, in comments nobody can find a week later, or worst of all, in competing documents that never actually respond to each other. Someone sends you a spec; you reply with your own AI-polished counter-spec; now there are two confident documents talking past each other. V1, V2, V3 — none of them converging.

I said I was still exploring. This post is the continuation of that exploration.

The first piece made a document easy to read. This one tries to make it easy to discuss — and, most importantly, to make the document evolve from the conversation instead of being replaced by the next person's copy.

Everything's still open source:

Think about how this usually goes. You've worked out an idea — a spec, a pitch, a direction for the next quarter — and you need the people who matter to weigh in: your cofounder, your boss, the two teammates who'll actually have to build it. So you generate a clean HTML write-up and send it over.

Then the familiar thing happens. A couple of people skim it. The real reactions show up later, scattered across chat threads and DMs, and some never come at all. By the time you sit down to make sense of it, the feedback is in five different places and you're reconstructing who objected to what from memory.

This one changes where that conversation happens. Let me ground it in the example I'll use for the rest of this post: a short proposal to add an offline mode to a product — the feature your field users keep asking for. You share one link, and whoever you send it to just opens it — no account, no app, no "can you give me access."

Instead of reacting somewhere else, they react on the document itself. Your reviewer highlights the success metric — "we'll know it worked if support complaints go down" — and notes it's too vague to act on. They highlight the rollout line and push back on shipping iOS before Android. They can drag a box around the diagram, or reply to each other, right at the point being argued. Every comment is pinned to the exact part it's about.

The benefit is simple: feedback stops getting lost. Instead of a pile of "re: the doc" messages you have to stitch together in your head, you open the same link and see the whole discussion in context, sitting right next to the words it's responding to.

(Mechanically it's one command — htmldrop push proposal.html --feedback — and the link is the same for your reviewers and for you. But that's plumbing. What matters is that the doc is now somewhere people actually talk.)

Earlier, password protection encrypted the content — share the link plus the password, and only people with the password could read it.

Now it extends that to the conversation. On a password-protected doc, the password now gates commenting too — so if the offline-mode proposal is sensitive, you'd share it like this:

What that means for you:

This is the part I care about most, and honestly the reason I built any of it.

Getting comments is the easy part. The hard part is what you do with them — and they're rarely all the same kind. On the offline-mode proposal, two comments come back: one says the success metric is too vague, the other pushes back on shipping iOS before Android. The first is a clean fix. The second isn't — it's a real fork in the road. The tempting move is to skim both, quietly fix the easy one, and ship a "v2" that dodges the hard question. Or to get defensive and answer with your own polished counter-doc, so now two documents are arguing and nobody's actually converging.

What you really want is to take it all in and work out which feedback is genuinely right and should change the doc, which is just a matter of taste, and where there's a real fork that you have to decide — not the machine.

So you bring the whole conversation back to your coding agent — Claude Code, Codex, whatever you work in. It reads every comment and reply in the context of the part each one is about, and helps you do three things:

In practice, you start by pulling the whole thread into your agent, so it's looking at the same comments you are:

From there you just talk to it — add your own take, push back on a comment, or ask it to bring in extra data or research before anything gets decided:

Then it converges: folding in the clear wins, and where it spots a real disagreement, surfacing it for you instead of quietly picking a side:

Once this round's settled, you push the update — and everyone reopens the same link (password and all) to find the synced version:

When the feedback is heavy, there's a better view too — the document on one side, the comments grouped by topic on the other — so you can see the shape of the disagreement before you decide anything.

(That whole flow runs through your coding agent — or, if you'd rather, one command (htmldrop converge) on your own LLM key. Either way it's your model, your cost, nothing stored on my end.)

The result: the next version is built from what everyone said, and the genuine judgment calls land in front of you instead of getting buried. You stop talking past the people reviewing your work and start folding them in — which, it turns out, is the step most of us skip.

Here's what makes it a conversation and not a one-shot:

Re-publishing reuses the same doc id, so the link never changes and the existing comments stay attached. You converge, re-push, and reviewers open the same URL to find the document has moved toward what they asked for — then they comment on the new version, and you converge again.

The document iterates in place. It evolves from the conversation, continuously — instead of forking into V1, V2, V3 copies that never answer each other. That was the whole promise at the end of the first post, and this is it.

Surge hosts the HTML (it stores nothing else). A small Cloudflare Worker + KV holds the comments — because a static page can't accept writes. You choose whose:

And either way, htmldrop feedback pull proposal.html --save writes the comments into spec.feedback.json in your repo — owned, versioned, yours. The Worker is just the live inbox; your repo is the system of record. (Comments stay readable so converge can work, so if you need true zero-knowledge, self-host. I'd rather say that plainly than pretend.)

Earlier post was about reading — make the thing easy to open, so maybe people actually read it. This continued exploration is about listening — make incorporating feedback a deliberate step, so maybe people actually absorb it.

I still don't think a tool fixes the deeper thing: that AI makes "being understood" so cheap we skip "understanding first." But I keep coming back to that Covey line, and converge is the closest I've gotten to encoding it — before you ship your next version, the document has to pass through everyone else's comments. You can't converge feedback you refuse to read.

It won't stop anyone from generating a counter-document. But if it nudges one doc toward evolving with its readers instead of being replaced by the loudest next draft — that's the win I was after.

That is why the earlier work was about making an idea easy to see — to visualize it and get it across cleanly. This one is about making it easy to discuss — to be read closely, questioned, and genuinely understood. The first got your idea out of your head; this is the part that makes the document listen on the way back.

Thanks for reading. If you've watched AI-assisted teams talk past each other — more docs, less understanding — I'd genuinely love to hear how it shows up for you. Reach out, leave a comment, tell me where this should go next.

Links: