The thing that makes LLMs actually work for coding, aside from reviewing the output carefully, is tight feedback loops.
Something that can be unit tested is easy to get an LLM to complete. You describe the acceptance criteria, have it write the tests, then follow TDD until the task is done. Review, look for vulnerabilities and edge cases, repeat as necessary. You can even take the human out of parts of this loop with automated code review on PRs. Let the bots fight it out until they're satisfied, then bring in the human to verify.
I've been a developer for almost 10 years. I've worked across stacks and languages. I've had clients patent my work. I'm not saying this to brag, I'm saying it because when I tell you that front-end design has been the single most frustrating part of using language models for coding, I want you to know it's not because I don't know what I'm doing.
The UI Feedback Loop is Broken
When it comes to user experience, the feedback loop has historically been really frustrating. It goes something like this:
- You: "Center the modal and add some padding"
- AI: changes code
- You: "It's centered but now there's way too much padding"
- AI: "How much padding would you like?"
- You: "Less. Like, half that. Also the close button is too close to the edge now"
- AI: changes code
- You: "The padding is better but you broke the close button positioning"
- AI: "Can you describe what's wrong with the close button?"
- You: gives up, opens the CSS file, fixes it in 30 seconds
I usually don't make it past step 5. It ends up being way faster for me to just make the styling edits manually because I know CSS and the robot often doesn't do things in a modern or holistic way.
(I've seen more !important flags from Claude and Cursor than from all of the junior devs I've worked with combined. Reward hacking is a real problem with LLMs.)
You can paste screenshots into the chat, and that helps. But then you're doing it manually every time, and you have to remember to do it, and you're still the one who has to notice something looks off before you think to take a screenshot. It's better than pure description, but it's still a lot of back and forth where you, the human, are the bottleneck.
Closing the Loop
Claude Code has a --chrome flag that connects it to a browser extension. This gives it tools to take screenshots, resize the viewport, click around, and generally interact with your browser. The workflow changes:
- You: "Make the contact form button more prominent"
- AI: changes code, takes screenshot, notices the double border it just introduced
- AI: "Done. I also noticed the border change created a double-border issue where the preview container meets the button area, so I fixed that too."
Or even better: you notice something wrong and say "the preview tab has a double border." Instead of guessing at why, the agent can go to the page, click the preview button, and take a screenshot. Context is king, and what it looks like is the most valuable UI context there is.
How to Set This Up
- Install the Claude in Chrome extension
- Log into claude.ai in Chrome
- Start Claude Code with
claude --chrome
The browser tools become available automatically. This gives Claude Code the ability to take screenshots, click and scroll around the page, resize the viewport to test responsive breakpoints, and record interactions as GIFs (useful for docs or sharing progress).
A few things worth knowing: you need a dev server running since Claude can't refresh the browser for you. Auth-gated pages work fine as long as you're already logged in when you start the session. Hot reload works great with this setup (that's kind of the whole point).
Real Example: Redesigning Democracy Direct's Contact Flow
Democracy Direct is a civic engagement tool I've been building. You find your representatives and write them letters. The main interface is the ContactFlow component, and it needed work.
The old layout:
Everything stacked vertically: user info fields at top, editor, preview, "Send Your Letter" button, then a whole separate "Print & Mail" section with address fields and formatting checkboxes. Problems were everywhere. Editor and Preview stacked vertically meant lots of scrolling. Actions buried at the bottom. Print options always visible even though most people use the digital flow. On mobile, you'd scroll past the entire letter to find "Send."
The new layout:
Two-column layout with the sidebar on the right. View mode buttons (Edit/Preview/Print Preview) replace the stacked editor and preview. Actions are always visible at the bottom (disabled when empty, not hidden). Print formatting options only appear in Print Preview mode. "Send via Contact Form" is now the hero action, impossible to miss.
On mobile:
The sidebar ("Your Information") appears above the editor via CSS order utilities. Users fill in their info before scrolling to the letter. Action buttons stack into a 2-column grid.
Where Visual Feedback Actually Helped
A few specific moments from the session where having screenshots made a real difference:
Mobile reordering. The sidebar needed to appear above the editor on mobile (so users fill in their info before scrolling to the letter) but beside it on desktop. I could have described this verbally and hoped Claude understood, but it was faster to just have it resize the viewport to 375px wide and verify the CSS order utilities worked correctly. Screenshot, confirm, move on.
The double border. When we wrapped the <LetterPreview /> in a container with its own border, we got a double border where it met the existing preview border. Claude caught this on the screenshot immediately ("I notice there's a double border issue") and fixed it in the same response. This is exactly the kind of thing I'd notice ten minutes later while testing something else.
Button layout on mobile. Getting the action buttons to form a sensible 2-column grid on mobile while staying in a row on desktop required iteration. Being able to resize the viewport and screenshot after each change made this converge quickly instead of becoming a back-and-forth about what "the buttons look weird on mobile" meant.
Closing Thoughts
This isn't revolutionary technology. It's just closing a feedback loop that was previously open. LLMs work well when they can verify their own output. For most code, that means tests. For UI, that means screenshots.
The result is fewer rounds of "what do you mean by weird spacing" and more rounds of actual iteration. For a civic engagement tool where the UI directly impacts whether someone successfully contacts their representative, that matters.
Democracy Direct is an open source project focused on making civic engagement more accessible. Check it out on GitHub.
Top comments (0)