An AI coding agent reads a bug report literally. Hand it "the button is off," and it guesses which button, which page, and what "off" means. Guess wrong three times and you have spent more time correcting the agent than you would have spent fixing the code yourself. The fix is not more words. It is removing the ambiguity that makes the agent guess. Here are the mistakes that cause the most rework, and how to correct each one.
Describing the element by how it looks instead of where it is
"The blue submit button" is tempting because that is how you see it. But the agent reads the codebase, not your screen, and there may be four buttons that look similar. It has no way to map "blue" to a line of code.
Correct it by pointing at the exact spot. Drop a numbered pin on the element in the screenshot and reference the pin in your comment: "Pin 2, the Save button in the top toolbar." The pin gives the agent a fixed coordinate on a real image, and the label gives it words to match against the code. If you are unsure how pins carry into the export, see how a pin marks the exact spot a reviewer means.
Stacking three bugs into one item
You are on the checkout page, you see a misaligned total, a broken coupon field, and a typo, so you write it all in one comment. It feels efficient. It is not. The agent treats the item as one task, fixes the first thing, and moves on. The coupon bug never gets touched, and now you cannot tell from the resolved status which parts are actually done.
Give each bug its own item. Capture the screen once, then add separate comments, or capture three stills if the problems live in different spots. One item, one problem, one thing the receiver can mark resolved. This also makes the resolve status on each comment mean something, instead of a half-truth.
Writing the symptom but not the expected result
"The date shows wrong." Wrong how? The agent cannot infer that a US date should read 03/14/2025 and not 14/03/2025 unless you say so. Symptom without expectation is half a bug report.
State both sides plainly. "Order date reads 14/03/2025. It should read 03/14/2025 to match the format used everywhere else in the account view." Now the agent has a target, not a complaint. This is the core of what an agent-readable bug report actually contains: current state, expected state, and where to look.
Skipping the screenshot and relying on prose alone
You know exactly what the screen looked like, so you describe it from memory and skip the capture. The agent gets a paragraph with no image. If your description is off by one detail, the agent works from your error instead of the real screen.
Capture the still. In Cobalt Capture you click Capture screen in the browser tab, the browser shares the window, and the current frame is drawn to a canvas you can crop. The screenshot travels alongside your comment in the export, so the agent reads both. The whole point of a markdown bug report an agent can read is that the picture and the words arrive together in one clean file.
Cropping so tight the agent loses context
Cropping is the only image edit Cobalt Capture offers, and it is easy to overdo. Crop down to a single input field and the agent sees a floating box with no page around it. It cannot tell whether that field is in a modal, a sidebar, or the main form.
Keep enough of the surrounding layout that the location is obvious: the section heading above the field, or the nearby label. A crop should remove noise, not context. When in doubt, use the full frame and let the pin do the pointing.
Sending a video walkthrough instead of markdown
Recording your screen and talking through the bug feels faster than typing. For a person, sometimes it is. For an agent, a video is opaque. It cannot read frames, it cannot skim, and it cannot pull a selector out of your narration. The reasons are laid out in why a video does not work as agent input.
You do not have to give up talking. Dictate your comment with the browser's built-in speech recognition in Chrome or Edge, and it lands as text next to the screenshot. You get the speed of talking and the agent gets text it can parse. See how dictating review comments works.
Not telling the agent which page or route the bug is on
A screenshot shows the rendered UI, not the URL that produced it. If your report says "the profile card is broken" with no route, the agent has to search the whole project for anything resembling a profile card.
Name the route in the comment: "On /settings/profile, the avatar overflows its container." One line saves the agent a search and cuts the chance it edits a similar component on a different page. For the broader habit, read how to frame a report so the agent edits the right element.
Publishing without checking the markdown export
You write the report, publish, and paste the link to your agent without ever looking at what the agent will actually read. If a comment was ambiguous on the review page, it is ambiguous in the markdown too.
Open the markdown version at /r/<slug>/markdown once before you hand it off. Read it the way the agent will: cold, with no memory of the screen. If any item makes you pause, rewrite it now. To see the output side by side with the review, look at the step-by-step capture to markdown flow.
The pattern across all of these is the same: write for a reader who was not there and cannot see your screen. Start a review, capture the still, pin the spot, and say what should happen instead. The agent does the rest without guessing.