AI and feedback
Get client feedback into your agent's context, not your inbox
You already trust an agent with the diff. The bottleneck moved upstream: the change request arrives as a screenshot in Slack with a red arrow on it, and nobody can say which element the arrow means. This page is about what that ambiguity costs once a model is the one writing the code, and about closing it at the moment the client points instead of two days later.
No credit card. Your client doesn’t need an account.
01
The round trip is the expensive part
Writing the code stopped being the slow step. The slow step is the sequence where a client says "the spacing is wrong here", you cannot tell which element "here" is, you ask, they answer the next morning, and by then you have context-switched twice. Every ambiguous item is a potential day, and almost none of that day is typing.
Nothing about that sequence is visible in your tooling. It does not appear as a failing test, a blocked ticket or a line on a timesheet. It looks like a project that takes three weeks when the work in it is four days, and everyone involved assumes the other side is the slow one.
02
Why an agent makes an ambiguous item worse before it makes it better
A junior developer who does not understand a ticket asks. A model does not. Give Cursor or Claude Code "more space around the button" with no page and no element and it will pick the most probable button, apply the most conventional spacing, and hand you a diff written in your own style with a tidy commit message attached. Everything about it looks right except the part that mattered.
The failure is quiet, and quiet is what costs money. A wrong interpretation does not fail a test. It passes review if you are skimming, it ships, and it returns a week later as "this still isn't fixed" — now two rounds of client patience spent on one sentence that five seconds of pointing would have settled. The value of a well-formed feedback item is not that it saves typing. It is that it deletes the branch where the agent guesses.
There is a mechanical version of the same point. Paste a raw client thread into an agent and most of the context window is greetings, scheduling and "sorry, one more thing". What you want in there is twenty numbered items grouped by page and element, each already unambiguous, with the two that are not clearly marked so the agent skips them instead of inventing an answer.
03
What one ambiguous item actually costs
Not the fix. The fix is ten minutes. This is everything around it.
- The message you write to ask, which is never one line, because you have to describe both things it might mean.
- The wait, set by the client's calendar and not yours. Same-day is a good day.
- The context switch back, after which you re-read a component you had fully in your head yesterday.
- The diff the agent produced while you were waiting, if you let it run: reviewed, discarded, sometimes half-kept, which is the worst of the three.
- The second review round, where the client repeats something they are certain they already told you.
- The cost that shows up nowhere: the client learns that pointing at things does not work, so the next round arrives vaguer than this one.
04
The same request, two shapes
As it usually arrives
- "The button looks wrong on mobile." Sent at 11pm, with a cropped screenshot.
- Three buttons on that page could be the one, and one of them is a shared component used on eleven other pages.
- "Mobile" could be a phone at 390 pixels wide or a tablet in portrait. The crop does not say.
- Nobody knows whether this was already raised in the last round, because that round lived in a different thread.
- The agent picks an interpretation and writes a confident diff. You find out which one it picked on the next call.
As a pinned comment
- The pin sits on one element, on one URL, recorded at the width the client was actually using.
- The device class is a field — desktop, tablet or mobile — not something inferred from a screenshot crop.
- A screenshot of that exact spot is attached automatically, at the moment the comment is written.
- The thread lives on the item, so previous discussion travels with it instead of being remembered.
- There is nothing left for the agent to interpolate, which is the entire point of the exercise.
05
The questions your agent would otherwise ask you
On the left, what an agent has to resolve before it can safely touch the code. On the right, where the answer already sits in a Writhink item.
| The agent needs to know | Where it already is |
|---|---|
| Which page this is about | The page URL recorded when the pin was placed |
| Which element on that page | The element anchor, plus the pin position inside it |
| Whether this is a bug or a preference | The client's own wording, rewritten for clarity but not reinterpreted |
| At what screen width it happens | The viewport size and device class captured with the comment |
| What it looked like | The screenshot attached to that item |
| Whether it has already been discussed | The public thread replies, carried along with the item |
| Whether anyone else asked for the same thing | Exact duplicates merged, with the count kept |
| Whether it is safe to act on at all | The status field, and an explicit flag on items that stayed ambiguous |
06
Close the gap where it opens, not afterwards
Every fix for this is a version of the same move: capture the context at the moment the person points, because that is the only moment it is free. Ten seconds later they have closed the tab, and from then on it costs a round trip, every single time.
There are three ways a client gets a comment into Writhink, and all three produce the same item with the same fields. A review link, which they open with no account and no signup and pin directly on the running page. The Chrome extension, for pages behind your app's login or a dev server a shared link cannot reach — Chrome only, there is no Firefox, Safari or Edge build. And an embeddable script on a staging build, so feedback lands in place whenever they notice something rather than in a batch at the end.
From there your agent reads them one of two ways. You generate a Markdown prompt and paste it into whatever you use — that route works in any chat box and is described on /feedback-to-prompt. Or you connect our MCP server and the agent queries the feedback itself, which is written out in full, tools and authorization model included, on /visual-feedback-for-ai-agents. If you want the editor-shaped version instead, /for/cursor and /for/claude-code walk through each one.
None of this makes an agent better at writing code. It removes the input that makes a good agent produce confidently wrong work, which turns out to be the part of the workflow nobody had automated.
Before you count on it
Writhink is in open beta: everything described here is available and free, no credit card. Paid plans are announced but not purchasable yet. The one limit that applies today is five AI prompt generations a month per organization.
FAQ
Questions people actually ask
- How does the feedback reach Writhink in the first place?
- Three ways. A review link your client opens with no account and no signup, a Chrome extension for pages behind a login or on a staging URL, and an embeddable script for permanent in-place feedback on a live site. The extension is Chrome only. All three produce the same item, with the same fields attached.
- Does Writhink rewrite what my client said?
- The AI pass cleans up wording so a vague sentence reads clearly, and it merges exact duplicates. It does not invent a requirement that was not there, and the client's original text stays on the item so you can check. Anything that is still genuinely ambiguous comes back marked "unclear — ask the client" rather than resolved by guesswork.
- Will this work with an agent that is not Claude or Cursor?
- The generated prompt is plain Markdown and does not care what reads it, so it works with Copilot, ChatGPT, a builder's chat box, or a colleague. If your tool speaks MCP over HTTP it can also connect directly — that side is on /visual-feedback-for-ai-agents.
- Is there an integration with Linear, Jira or GitHub?
- No. Writhink has no native integration, plugin or connector with any third-party tool, and pretending otherwise would waste your afternoon. You can export the feedback, or ask an agent that already has access to your tracker to file the issue from what it read.
- What if the client is wrong about the cause?
- They usually are, and it does not matter. A client reports a symptom on a specific element at a specific width, which is exactly the evidence you need to work out the cause yourself. The item is a well-anchored observation, not a diagnosis you are expected to implement.
- Is this not just a bug tracker with extra steps?
- A tracker starts after someone has already translated what they saw into a written ticket, and that translation is where the context is lost. Writhink starts one step earlier: the person looking at the page creates the item by pointing at it, and the translation never has to happen.
Start
Send one link. Get feedback you can build from.
Your clients comment right on the page — no account, no screenshots, no voice notes. Writhink sorts the comments and writes the prompt for your AI.