Most CSS bugs are easy to see and annoying to find. The button is 4px too short. The card grid wraps one column early at a certain width. A heading is grey on one page and black on another. You can spot all of these in a second. Finding the rule responsible, in the file that actually ships it, is what takes the time.
This post is about a different way to work through that: point at the element on your running site, say what it should look like, and let a coding agent find and change the source. It's not a replacement for knowing CSS. It moves the tedious part, the trip from pixel to file, onto something that is good at searching a codebase.
Why is CSS so slow to debug in DevTools?
DevTools is excellent at telling you what the browser did. Select an element and you get the computed value of every property, the rules that matched, the ones that were overridden, and the box model. For a single page of hand-written CSS, that is often all you need.
It gets slower once a build step sits between you and the browser. The stylesheet DevTools shows might be compiled from Sass, generated by Tailwind, scoped by a Vue or Svelte compiler, or injected by a CSS-in-JS library. The rule is right there, but the file it came from isn't. Source maps help when they're set up. Then you still have to work out whether the fix belongs in the component, a shared utility, a theme token or a global override, and you still have to switch to your editor, find the file and make the change you already tried in the Styles panel.
None of that is hard. It's just a lot of small steps for a change that's often one line.
What does "debugging CSS visually" mean here?
The phrase gets used for visual editors that let you drag margins around, and for browser extensions that overlay grids. In this post it means something narrower: you select the element in the browser and describe the fix in words, and an agent that can read and edit your project turns that into a code change you review.
The browser is where you notice the bug, so that's where you start. The agent does the search. You decide whether the result is right.
What does an agent need to know to fix a CSS bug?
A coding agent like Claude Code, Codex or Gemini CLI reads files. It has no idea what your page looks like unless you tell it. If you type "the pricing button is too short", it has to guess which button, on which page, and what "too short" means. Sometimes it guesses well. Often it edits the wrong component.
A useful request carries roughly what you would look at in DevTools yourself:
- Which element. A selector, plus its markup and visible text, so the agent can search the source for it.
- Where. The page URL, because the same component can look different on different routes.
- What the browser applied. Computed styles and the CSS rules that matched, so the agent knows whether a value comes from a utility class, a component style or a global rule.
- What it looks like. A screenshot of the element, for problems that are hard to put into words.
- What you want. The part only you can provide.
You can collect all of that by hand and paste it into a chat. Tools that sit in the browser can collect it for you when you click.
How do you describe a CSS bug so the agent gets it right?
Be specific about the result, not the property. "Make this button match the Start a project button in the nav" is better than "increase the height", because it tells the agent there is an existing style to reuse instead of a new value to invent. A few patterns that tend to work:
- Point to a reference. "Same spacing as the cards on /features." The agent can read the other component and copy its approach.
- Give the condition. "Below 768px the title wraps onto three lines." Mention the viewport if the bug only shows at some widths.
- Say what not to change. "Don't touch the global button styles." This keeps a local fix local.
- Select more than one element when the problem is alignment between them. A note attached to both the label and the input is clearer than a note on either.
Then read the diff. If the agent added an override with a higher specificity instead of fixing the original rule, reject it and say so. That kind of feedback is quick to give when the change is small and in front of you.
Which CSS bugs suit this approach, and which don't?
It works well for bugs where the expected result is easy to state and the fix is in your own source:
- spacing, sizing and alignment that's off compared with the rest of the design
- a component that doesn't match its siblings, like one card with the wrong padding
- text that overflows or wraps badly at a given width
- colours or font weights that drifted from the design tokens
- layout that breaks only on one route because of a page-specific wrapper
It's a weaker fit when the problem isn't really in your CSS. A rendering difference between Safari and Chrome needs you to test in both browsers. Animation jank is a performance question, and the Performance panel will tell you more than a screenshot. Styles that come from a third-party widget in an iframe aren't in your project at all. In those cases, DevTools and your own judgement are still the right tools.
How does this work in PulseDev?
PulseDev is a macOS app that runs a small local server for each project and serves a widget script. You add one script tag to your dev layout (the framework guides show where for each stack), start your dev server, and a PulseDev button appears on the page.
- Press the button and click the element. Cmd-click selects its parent if you landed on a child; Shift-click adds more elements to the same note.
- Type what you want and pick an agent. PulseDev runs Claude Code, Codex or Gemini CLI, whichever you have installed and signed in to.
- The widget sends the selector, page URL, markup, computed styles, matched CSS rules, recent console errors and a screenshot of the element. The agent reads your project and proposes a change.
- The diff appears under Changes to review. Approve writes it to your files and your dev server reloads. Reject throws it away. You can reply on the same note to iterate.
Review mode is the default: PulseDev asks the agent to propose changes rather than edit files. This is an instruction, not a read-only sandbox. There's an Auto-apply switch for when you trust the agent with a quick batch of small fixes, but review mode is the sensible place to start.
One limit worth knowing: today the widget sends DOM-level context, not your component tree. The agent finds the right file by searching for the classes, text and rules it was given. For most CSS work that's enough. For pages built from many identical utility-class elements, a word in your note about which component you mean saves it a guess.
Should you still learn DevTools?
Yes. You need to be able to read a diff and know whether it's right, and that comes from understanding the cascade, specificity, flexbox and grid. An agent can save you the trip from the screen to the file. It can't tell you whether min-height or padding is the better fix for your design system. You still decide that.
If you want to try the visual route, the docs cover setup in a few minutes, and the agent guide explains how PulseDev runs each one.
