Using AI coding agents? Your feedback format matters

Something inverted in software over the last couple of years. Implementation, the historically expensive half of building, got fast — an AI coding agent will refactor a component or restyle a page in the time it takes to make tea. Specification quietly became the bottleneck. If you build with Claude, Cursor, Copilot or any of their cousins, the limiting factor on your ship rate is no longer how quickly code gets written; it's how precisely you can tell the agent what you want changed. Which means your AI coding agent workflow deserves the same attention you used to give your build pipeline — starting with the format of your feedback.

Agents fail on ambiguity, not difficulty

Watch an agent handle “make the header look better” and you'll see the failure mode immediately: it does something — often several plausible somethings — and none of them is the thing you meant. The model isn't weak; the instruction is. Humans patch ambiguous instructions with shared context and a follow-up question. Agents mostly just pick an interpretation and commit.

Now give the same agent “point 1.3: reduce the heading's top margin so it sits closer to the nav — see the pinned region in box 1” alongside an image with a numbered box drawn on it, and it lands the fix first try. The difference isn't intelligence. It's location, intent and reference — the same three things human developers need, delivered in a form a model can consume without guessing.

What agents actually want

Modern agents are multimodal and structured input is their native food. Three properties do most of the work:

1. Numbered points

A numbered list turns one sprawling request into discrete, checkable tasks. Agents handle "1.1, 1.2, 1.3" dramatically better than a paragraph containing three implied tasks — and the box.point scheme keeps changes grouped by screen, with replies (1.1.1, 1.1.2) holding the discussion on the exact point it belongs to.

2. Pinned images

Text locates roughly; a numbered box on a screenshot locates exactly. When the markdown says “1.2 [Feedback] CTA hit area too small on mobile” and the attached image shows pin 1.2 drawn around that CTA, the agent maps instruction to pixels — and from pixels to the right component in your code.

3. Machine-friendly markdown

Markdown survives every paste into every tool. Statuses in the export tell the agent what's outstanding versus already done; consistent structure means you can reuse the same prompt preamble every session (“work through the numbered items; each maps to the pinned image of the same number”).

From review to prompt in one step

Here's the workflow shift: stop treating “reviewing the build” and “writing prompts” as two jobs. With the right capture format they're the same job.

In Fixa, you screenshot your build, pin every issue as you spot it — talking instead of typing when that's faster — and then hit export. Out comes a numbered markdown list, with the annotated images bundled beside it (or one combined document, if you prefer a single artefact). That export is the prompt. Paste it into Claude, attach the images, and the agent fixes exactly what you marked, in order, item by item.

A real export looks like this:

• 1.1 [Feedback] Headline hierarchy — refund number should sit above the fold. (box 1, pin 1.1)
• 1.1.1 SS: subhead down to one line while you're there.
• 1.2 [Testing] CTA hit area under 44px on iPhone SE. (box 1, pin 1.2)
• G.1 [Feedback] The whole flow feels one screen too long — merge steps two and three.

Notice what the agent gets for free: discrete tasks, locations, current state, replies nested under the point they answer, and general feedback (G-numbered) cleanly separated from pinned feedback. Nothing to interpret, nothing to guess.

The loop, run properly

The full cycle for a solo founder or a small team looks like:

1. Build — agent ships a version.
2. Review — you pin everything wrong with it, in minutes, on one board.
3. Export — numbered markdown + pinned images.
4. Prompt — paste into the agent; it works the list.
5. Verify — flip pins to Done as fixes land; anything not Done rolls into the next round.

The board gives the loop a memory. Sessions end, context windows reset, but pin 1.4 stays open until the fix is actually verified — which is exactly the discipline agent workflows tend to lose.

Common failure modes (and their fixes)

• The agent fixes the wrong instance. Your site has three similar cards and it restyled the wrong one. Fix: always export with the pinned images attached — the box on the screenshot disambiguates what prose can't.
• One giant prompt, half-done. Twenty items in one message and the agent quietly drops the tail. Fix: work in numbered batches of five to eight, and tell the agent to report per number (“1 done, 2 done, 3 skipped — needs the API change”).
• Fixes regress across sessions. Yesterday's fix undone by today's refactor. Fix: keep the board open across sessions and re-verify pins on the live build before flipping them to Done — the status is your regression net.
• Vague general feedback stalls. “G.1: flow feels long” isn't actionable yet. Fix: let general items spawn specific pins once you know the change, and close the general item when its children are Done.

Feedback used to be something you wrote for people and reformatted for tools. Now the best format for your agent is the best format for your developer and for future-you. Make your feedback numbered, pinned and exportable once, and every consumer of it — human or model — gets sharper. Start free, review your next build on a board, and paste the export into your agent. First-try fix rates are a persuasive argument.