The Eyes Have It: Closing the Agentic Design Loop
Source: Dev.to
The Power of Tight Feedback Loops for LLM‑Assisted Coding
The thing that makes LLMs actually work for coding—aside from reviewing the output carefully—is tight feedback loops.
- Unit‑testable code is easy for an LLM to complete.
- Describe the acceptance criteria, have the model write the tests, then follow TDD until the task is done.
- Review, look for vulnerabilities and edge cases, repeat as necessary.
- You can even automate parts of this loop with code‑review bots on PRs. Let the bots “fight it out” until they’re satisfied, then bring a human in to verify.
My Background
- Developer for almost 10 years.
- Worked across stacks and languages.
- Clients have patented my work.
I’m not bragging—I’m sharing this because front‑end design is the single most frustrating part of using language models for coding, and it’s not due to a lack of skill on my part.
Why Front‑End Feedback Loops Feel Broken
Typical Interaction
| You | AI |
|---|---|
| “Center the modal and add some padding.” | changes code |
| “It’s centered but now there’s way too much padding.” | “How much padding would you like?” |
| “Less. Like, half that. Also the close button is too close to the edge now.” | changes code |
| “The padding is better but you broke the close‑button positioning.” | “Can you describe what’s wrong with the close button?” |
| You give up, open the CSS file, and fix it in ~30 seconds. |
I rarely make it past step 5. Because I know CSS, it’s faster to edit the styles manually than to keep prompting the model, which often produces non‑modern or non‑holistic solutions.
(I’ve seen more
!importantflags from Claude and Cursor than from all the junior devs I’ve worked with combined. Reward‑hacking is a real problem with LLMs.)
Screenshots Help—But Not Enough
You can paste screenshots into the chat, which is better than a pure textual description, yet you still have to:
- Notice something looks off.
- Remember to take a screenshot.
- Paste it manually each time.
The human remains the bottleneck.
Claude Code + --chrome Flag: Closing the Loop
Claude Code’s --chrome flag connects the model to a browser extension, giving it tools to:
- Take screenshots.
- Resize the viewport.
- Click around and scroll.
- Record interactions as GIFs (great for docs or sharing progress).
New Workflow
You: "Make the contact form button more prominent."
AI: changes code, takes screenshot, notices a double‑border issue it just introduced.
AI: "Done. I also fixed the double‑border problem where the preview container meets the button area."Or, if you spot a problem:
You: "The preview tab has a double border."
AI: navigates to the page, clicks the preview button, takes a screenshot, and fixes it.Context is king—visual feedback is the most valuable UI context.
Getting Started
-
Install the Claude in Chrome extension.
-
Log into
claude.aiin Chrome. -
Start Claude Code with
claude --chrome
The browser tools become available automatically.
Note: You need a dev server running (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 the whole point.
Real‑World Example: Democracy Direct
Democracy Direct is a civic‑engagement tool I’m building. Users find their representatives and write letters. The main interface is the ContactFlow component, which needed a UI overhaul.
Old Layout
- Everything stacked vertically:
- User‑info fields (top) → editor → preview → “Send Your Letter” button → separate “Print & Mail” section (address fields, formatting checkboxes).
- Problems:
- Editor & preview stacked → excessive scrolling.
- Actions buried at the bottom.
- Print options always visible (most users use the digital flow).
- On mobile, you scroll past the entire letter to find “Send”.
New Layout
- Two‑column layout with a right‑hand sidebar.
- View‑mode buttons (Edit / Preview / Print Preview) replace stacked editor/preview.
- Actions always visible at the bottom (disabled when empty, not hidden).
- Print‑formatting options appear only in Print Preview mode.
- “Send via Contact Form” becomes the hero action—impossible to miss.
Mobile Adjustments
- Sidebar (“Your Information”) appears above the editor via CSS
orderutilities. - Users fill in info before scrolling to the letter.
- Action buttons stack into a 2‑column grid.
Moments Where Screenshots Made a Difference
| Situation | Why a Screenshot Helped |
|---|---|
| Mobile reordering – sidebar must appear above editor on mobile but beside it on desktop. | Claude resized the viewport to 375 px, took a screenshot, and confirmed the CSS order utilities worked. |
| Double border – wrapping “ in a container introduced a double border. | Claude noticed the issue on the screenshot, reported it, and fixed it in the same response. |
| Button layout on mobile – need a sensible 2‑column grid on mobile while keeping a row on desktop. | Resizing the viewport and screenshot after each change let Claude converge quickly, avoiding endless “the buttons look weird on mobile” back‑and‑forth. |
Takeaway
Tight, visual feedback loops—enabled by tools like Claude Code’s --chrome flag—turn a frustrating, human‑bottlenecked UI iteration process into a fast, mostly‑automated workflow. The human still guides the direction, but the model can see and act on the UI in real time, dramatically reducing the number of back‑and‑forth steps required to get a polished front‑end.
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.