Fix a UI bug with AI by pointing at it

Why are UI bugs hard to describe to an agent?

Because what you see has no file name. “The save button looks wrong on my phone” gives an agent no route, no component and no sense of what “right” is. It will search the code, guess which file you meant and change something plausible.

A UI bug report that an agent can act on has four parts. Where: the page and the element. What: the actual behavior, with evidence. Expected: how it should look or act. Check: how you will both know it is fixed. The steps below get you each part in a few minutes.

Step 1: how do you find the element?

Use your browser’s developer tools. In Chrome, right-click the element and choose Inspect. The Elements panel opens with that node highlighted, and the Select an element tool lets you click anything on the page to find its node, as the Chrome DevTools docs explain.

From there, right-click the node in the DOM tree and choose Copy, then Copy JS path. That gives you a document.querySelector() expression that resolves to the node. Paste it into your bug report so the agent can find the exact element.

Also note the route (/settings), the viewport width and anything unusual about the state, such as being logged in as a user with no data. Class names generated by a build tool can change from one build to the next, so add the visible text or the component name when you know it.

Step 2: what evidence should you capture?

Pictures and errors. The same DevTools docs describe Capture node screenshot, available by right-clicking a node in the Elements panel, which saves an image of just that element. Take one full-page screenshot too, so the agent sees the element in context, and name the viewport width in the message.

Check the console and the network tab for errors at the moment the bug appears. A failed request or a thrown exception often explains a visual problem better than the layout does.

Then give the images to the agent. Claude Code accepts a dragged image, a pasted one (Ctrl+V) or a path to an image file, according to its common workflows docs. Codex’s CLI takes codex --image with the first prompt, or a pasted image, per its CLI docs. Gemini CLI’s README lists multimodal input, including images and sketches.

Step 3: how do you write the report?

Put the four parts in one message:

“Route: /settings, at 360 pixels wide. Element: [paste the JS path]. Actual: the Save button wraps onto two lines [screenshot]. Expected: one line, as at 768 pixels. I do not know the cause. Change only SettingsForm.tsx and the styles it uses. Do not change other pages. Done when the button stays on one line at 360, 768 and 1280 pixels, and npm run lint passes. Describe what you see at each size and show the lint output.”

Notice what it leaves out: a theory. If you guess at the cause and guess wrong, the agent may fix the guess. Describe the symptom and let it find the cause. Anthropic’s best practices make a related point for visual work: paste the screenshot, ask the agent to implement the fix, and have it take a screenshot of the result and compare it with the original.

Step 4: how do you check the fix?

Take the same screenshots after the change, at the same widths, and put them next to the first ones. Check the state you reported, then check a neighbor: a component fixed on one page is often used on three others.

Run your tests and linter, and look at the diff. A CSS bug should produce a small CSS diff. If it touched a dozen files, ask why.

For web apps, Claude Code can also work through Anthropic’s Chrome extension, which its docs say lets it read console errors and DOM state directly, then fix the code that caused them, and check a design against the running page. That removes some of the copying in steps one and two, if you use that setup.

What extra detail do different UI bugs need?

Layout bugs need the viewport width, the zoom level and the browser. State bugs need the exact data and account: the same page can look fine for one user and break for another with a long name or an empty list. Timing bugs need the steps in order, and what happened between them, such as a slow or failed request.

If the bug appears only after an action, write the steps as a numbered list. OpenAI’s prompting guide does the same in its bug example: a reproduction recipe, plus the files you suspect, plus the constraints.

What is the shortcut?

Point at the bug instead of describing it. SwarmPane’s Point and Fix starts in the Browser pane, which keeps your running app open in the sidebar. Click the broken element and say what to change. SwarmPane finds the source, makes the change in a copy, runs your checks and shows you before and after. You keep it, undo it or refine it.

The Browser pane gives a preview its own cookies and storage, separate from the app. And if you have SwarmPane Voice, which comes with Pro and is macOS only for now, the words you say arrive as a draft in the Point and Fix composer, to edit before you send.

SwarmPane runs the agent CLIs and accounts you already have. Start with a 7-day trial for $1 and fix your next layout bug by clicking it.