How to give feedback to an AI coding agent

This guide is the canonical playbook for the broader guides hub. It walks through the format, the workflow, and the failure modes, regardless of which agent you ship with.

What you'll learn

• The five elements that make feedback agent-ready
• A walkthrough from staging issue to agent fix
• Why the same review works for giving visual feedback to a human developer, not just an agent
• Common mistakes that turn good feedback into clarifying-question hell
• How CobaltCapture produces this format with no manual structure work

The five elements of agent-ready feedback

1. Markdown text. Every modern coding agent reads markdown. Slack threads, Notion docs, Linear comments, and Loom transcripts do not survive the trip into a Cursor composer or a Claude Code session. Markdown does. It is plain text with structure, headings, bullets, code blocks, and the structure is what the agent uses to orient.

2. Stable embedded screenshots. A screenshot needs to live at a public URL the agent can resolve. A bitmap pasted into a chat window has no URL the agent can follow if it loses context. A screenshot at https://cobaltcapture.com/r/abc12345/img/1.png is a stable reference that any agent in any session can fetch.

3. Source URLs. Every finding should be stamped with the URL of the page it came from. Without it, the agent has to grep the repo for which component is on which route. With it, the agent navigates directly to the file most likely to need the fix.

4. Dictated context, not typed. Voice captures the why and the when. "This happens on iOS Safari at viewport widths under 380px, only when the user has scrolled past the fold", in a way that one-line typed feedback skips. The agent uses that context to write a real fix, not a shallow patch.

5. Discrete findings. One issue per section. The wall-of-prose alternative buries the third and fourth findings; the agent fixes the obvious ones and ignores the rest.

A walkthrough: from staging issue to agent fix

Open the staging URL you want feedback on. In a new tab, open CobaltCapture. Hit Capture screen. Pick the staging window. Drag a box around the broken component. Hit Dictate and talk through the problem: "The submit button overflows its container at viewport widths under 380px on iOS Safari. Should respect the existing max-width:100% rule from .btn-primary."

Repeat for each finding. Three to five issues take a couple of minutes. Hit Publish. You get a URL.

In Cursor: paste the URL into the composer with a one-line prompt. "Address the items at this review in order: cobaltcapture.com/r/abc12345." The composer follows the URL, pulls the embedded screenshots inline, and starts producing patches against the components named in the captions.

In Claude Code: drop the markdown export into your repo as feedback.md with curl -fsSL https://cobaltcapture.com/r/<slug>/markdown > feedback.md. Then prompt "Read feedback.md and address items in order. Confirm each fix before moving on."

In Lovable, Bolt, or v0: paste the URL into the chat. The agent follows the URL and the screenshots arrive as part of the next iteration.

There's also a version of this with no paste step at all. Connect the Cobalt MCP server to Claude Code, Cursor, or another MCP-aware agent, and instead of copying a URL into a prompt, the agent calls get_review directly and receives your notes as text plus each annotated screenshot as an actual image, the pixels you marked up, not a link it has to fetch and hope resolves.

Giving the same feedback to a human developer

Everything above works for a person, not just an agent, because the format doesn't change. A developer reading cobaltcapture.com/r/<slug> sees the same cropped screenshots, the same pins and arrows, and your dictated notes as captions, rendered as a normal web page instead of raw markdown. There's no separate "human mode" to remember to use.

That matters because most feedback goes to a mixed audience: a developer picks up the review first, maybe hands the same URL to an agent for the mechanical parts, or vice versa. A screen recording forces you to choose your audience up front, a human watches it, an agent can't. A markdown-plus-screenshots review works for both without any extra step. Paste the review link in a Slack message or a PR comment for the developer; paste the same link, or the markdown export, into the agent's prompt. Nothing about the artifact changes between the two.

The one thing worth doing deliberately either way: say what you expected, not just what's wrong. "The total shows $0 after applying the promo code, expected the subtotal to persist" gives a human enough to start fixing immediately, and gives an agent the same acceptance criteria it would otherwise have to infer.

How to give feedback to developers

Effective feedback to developers includes a source URL, a screenshot of the problem, what you expected versus what actually happened, and steps to reproduce, delivered in written form rather than a Loom or a verbal-only comment. A developer, or an AI coding agent, can act on that immediately; anything vaguer buys you a round of clarifying questions. The checklist for a single piece of developer feedback:

1. Source URL. The exact page or route the issue is on, so the developer can reach the same place without guessing.
2. A screenshot of the problem, cropped to the broken area and annotated so the issue is unmissable.
3. Expected vs actual. State what should happen and what happens instead. "The total should keep the subtotal after the promo code applies; it resets to $0" is a spec; "the total is broken" is not.
4. Steps to reproduce, in order, including the browser, OS, and viewport when they matter.
5. One issue per item. Bundle three problems into a single paragraph and the mechanical ones get fixed while the rest are missed.

Written beats verbal for the same reason it beats a screen recording: the developer can scan it, copy the repro, and follow the URL, and an AI coding agent can read every part of it, where it can neither watch a Loom nor hear a hallway comment. The same review URL works for both audiences, as the section above describes.

Common mistakes

Pasting bitmaps without source URLs. A screenshot in a chat window with no URL gives the agent a single image and no idea where it came from. The agent fixes the symptom and breaks something three components over.

Typing one-line findings. "The button is broken" produces a different patch than "the submit button overflows at 380px on iOS Safari and the soft-validate animation is too aggressive." The first is a guess. The second is a spec.

Sending Looms. Agents cannot watch videos. A Loom URL pasted into a coding agent is read as a string. The recording you made is invisible to the model.

Filing tickets without visual context. A Linear ticket with a paragraph and no screenshot makes the agent ask for the screen. That ask costs an iteration.

Mixing findings together. Reviewers who write paragraphs covering three issues at once force the agent to choose which one to fix first. Discrete H2-per-finding structure removes that ambiguity.

How CobaltCapture fits in

CobaltCapture is the dedicated tool for producing this format. It runs in the browser, no install. The capture flow stamps a source URL on every screenshot automatically. Voice dictation transcribes inline. The output is markdown with embedded image URLs, hosted at a public review URL that any agent can follow.

The same review URL drops cleanly into Cursor's composer, Claude Code's terminal as a downloadable .md, Lovable's chat, and any other modern coding agent that follows pasted URLs. For the per-agent walkthrough, see the dedicated workflow for Cursor. The full hub of agents and workflows lives at agent feedback.

Frequently asked questions

What format works best for feedback to an AI coding agent?

Markdown with embedded screenshots and explicit source URLs works best. Markdown is readable by every modern coding agent, embedded images render inline, and source URLs give the agent the page each issue belongs to.

Should I include screenshots?

Yes. Coding agents like Cursor and Claude Code can process embedded images inline. Without a screenshot, the agent has to guess what the issue looks like, which produces shallower fixes and more clarifying questions.

What about source URLs?

Always include the source URL of the page each finding came from. Without it, the agent cannot locate the component, route, or template the finding refers to. With it, the agent can navigate directly to the file most likely responsible.

How long should each finding be?

Two to four sentences. Long enough to capture the why and any browser or viewport context, short enough that the agent can take it as a single unit of work. Voice dictation tends to hit this length naturally.

Can I send a Loom or video?

Not effectively. AI coding agents cannot watch videos. A Loom URL pasted into Cursor or Claude Code is read as a string the agent cannot process. The narration is lost, and the visual context is invisible.

What is the difference between giving feedback to Cursor vs Claude Code vs Lovable?

The format is the same: markdown with screenshots and source URLs. The delivery differs. Cursor takes pasted markdown directly in the composer. Claude Code reads files in the repo. Lovable accepts a pasted URL in chat. The artifact does not change, only the paste destination.

Does this also work for giving visual feedback to a human developer?

Yes, the same review works for both. A developer opens the review URL and sees the cropped screenshots, pins, and dictated notes rendered as a normal page. An agent reads the identical content as markdown or, over MCP, as text plus real screenshot images. Nothing about how you capture or publish the feedback changes based on who reads it.

Frequently asked questions

What format works best for feedback to an AI coding agent?

Markdown with embedded screenshots and explicit source URLs works best. Markdown is readable by every modern coding agent, embedded images render inline, and source URLs give the agent the page each issue belongs to.

Should I include screenshots?

Yes. Coding agents like Cursor and Claude Code can process embedded images inline. Without a screenshot, the agent has to guess what the issue looks like, which produces shallower fixes and more clarifying questions.

What about source URLs?

Always include the source URL of the page each finding came from. Without it, the agent cannot locate the component, route, or template the finding refers to. With it, the agent can navigate directly to the file most likely responsible.

How long should each finding be?

Two to four sentences. Long enough to capture the why and any browser or viewport context, short enough that the agent can take it as a single unit of work. Voice dictation tends to hit this length naturally.

Can I send a Loom or video?

Not effectively. AI coding agents cannot watch videos. A Loom URL pasted into Cursor or Claude Code is read as a string the agent cannot process. The narration is lost, and the visual context is invisible.

What is the difference between giving feedback to Cursor vs Claude Code vs Lovable?

The format is the same: markdown with screenshots and source URLs. The delivery differs. Cursor takes pasted markdown directly in the composer. Claude Code reads files in the repo. Lovable accepts a pasted URL in chat. The artifact does not change, only the paste destination.

Does this also work for giving visual feedback to a human developer?

Yes, the same review works for both. A developer opens the review URL and sees the cropped screenshots, pins, and dictated notes rendered as a normal page. An agent reads the identical content as markdown or, over MCP, as text plus real screenshot images. Nothing about how you capture or publish the feedback changes based on who reads it.