Frontend agents can write the code. What they usually cannot do is tell you when the interface is actually done.
Ask one to "make this page feel polished" and it will usually do something. It may add cards, soften the colors, round a few corners, and declare victory. The result can look plausibly designed while missing the actual job: preserving the hierarchy, fixing the broken interaction, handling the empty state, and proving the page still works at a narrow viewport.
The model never had a usable target. "Polished" could mean almost anything.
Teams keep trying to solve this by giving agents more context, more tools, and more permission to act. But broader authority does not repair a vague success condition. It only lets the agent be wrong across a larger surface.
What is missing is a feedback contract: a shared, testable definition of what good looks like, what evidence counts, and where a human still makes the call.
Taste has to become a constraint
Most design feedback is written for another human.
"This feels generic."
"The hierarchy is off."
"Can you make it cleaner?"
A designer can unpack those comments because they carry a lot of learned context. An agent sees an open-ended invitation to rearrange CSS.
Turn that taste into checks. Hallmark is an interesting example of this direction. It separates activities such as building, auditing, redesigning, and studying, then encodes design anti-patterns as explicit gates. I care less about whether one instruction set has "solved" design. The useful pattern is that an agent can now fail a check instead of vaguely missing the vibe.
The same applies to behavior. A production interface needs more than a visual target. It needs acceptance criteria for inputs, outputs, failure states, recovery, and observable events.
Compare these two instructions:
Make the settings panel feel polished and responsive.
And:
target: account settings panel
design_constraints:
- preserve the existing heading hierarchy
- do not introduce gradients or decorative cards
- keep the primary action visible at 320px width
behavior:
- disable Save until a field changes
- show the server error beside the failed field
- preserve edits after a failed request
- return focus to the first invalid field
verification:
- capture desktop and 320px screenshots
- test one successful save and one rejected save
- record console errors from both flows
The second version is less magical. Good. Magic is hard to review.
You probably do not need a small specification language for every UI task. A Markdown checklist is often enough. The reviewer and the agent just need to judge the same thing.
The browser shows only half the bug
Code-only inspection is a bad way to understand many frontend failures.
A component can be locally reasonable and still render badly because of inherited styles, unexpected content, runtime state, a container width, or another component higher in the tree. The visible bug lives in the browser. The cause may live three abstractions away.
Frontend agents need sight. Giving them unlimited browser control is a separate decision.
peek-cli documents a deliberately narrow setup: an agent can receive screenshots from an already-open browser tab without getting click or script-injection authority. That boundary is useful because observation and action are different capabilities. A team can improve the agent's diagnosis without immediately letting it operate the whole browser session.
But a screenshot is only one layer of context. It tells the agent what the pixels look like. It may not tell it which component produced them, which state branch is active, or where the relevant source lives.
Tools such as Domscribe point at the other half of the problem: map the rendered element back toward component state and source location. Visual evidence answers "what is wrong?" Structured runtime context helps answer "where should I look?"
Neither replaces the other.
This is where a lot of agent demos quietly cheat. They show a model looking at a screenshot, changing code, and producing a nicer screenshot. The loop appears closed because the last image looks better. We still do not know whether the interaction works, whether the console is clean, whether the empty state survived, or whether the agent fixed the right component instead of painting over the symptom.
Sight helps. Traceability helps. A definition of done needs both.
Proof should be an artifact
"Done" is not a status message from the agent. It is evidence a reviewer can inspect without replaying the entire run.
For a frontend change, that bundle might include:
- before and after views at the relevant viewport sizes
- the exact user flow that was exercised
- console errors and failed network requests
- the acceptance checks that passed or failed
- a pointer from the visible element to the changed source
- any verification the agent could not complete
The ProofShot discussion on Hacker News is useful here because the comments push beyond screenshots. People ask about video, console output, server logs, action timelines, and overlap with existing Playwright workflows. That is the right argument to have. A screenshot is evidence, but it is not proof of behavior.
This distinction matters most when the final screen looks fine.
A broken save flow can produce a perfect screenshot. So can a page with an accessibility regression. So can a component that only works with the seeded demo data.
The evidence should match the risk. A spacing change may need a before-and-after capture at two widths. A checkout change needs behavioral tests, failure-state evidence, and a human approval boundary. Treating both as "the browser looks good" is how polished prototypes become expensive production bugs.
A practical frontend feedback contract
You do not need a new platform to try this. Add six questions to the task you already give the agent:
- What visual or behavioral constraint must remain true?
- Which route, viewport, data state, or user state exposes the problem?
- How can the visible element be traced to runtime state and code?
- What exact interaction or check should run?
- What evidence should the agent return for review?
- What can the agent decide, and what still needs a human?
Then make failure explicit.
If the agent cannot reach the route, cannot reproduce the state, or cannot run the verification, the task is not complete. That is useful information. It should stop and report the missing evidence instead of guessing its way to a green summary.
This also makes tool selection easier.
If the contract requires only a rendered check, read-only browser visibility may be enough. If it requires a multi-step form flow, use a controlled browser test. If the bug depends on component state, add a DOM-to-source mapping. If the risk is accessibility, run the accessibility checks and capture the failures.
Start with the proof you need. Grant the capability required to produce it. Do not begin with maximum autonomy and hope the agent discovers what matters.
More authority comes last
The current agent conversation is obsessed with action: more tools, longer runs, fewer approvals, bigger tasks.
Frontend quality depends on something much less exciting. The agent and reviewer need to agree on what success means before the agent starts changing the page.
Once that contract exists, better models and richer runtime context can help. Browser tools can too. More autonomy may even earn its way into the workflow.
Without it, those upgrades mostly make the demo move faster.
Judge the frontend agent by the evidence it leaves behind: can a human review the result and see that the interface met the agreed definition of done?
That promise is smaller than autonomy. I will take it every time.
Source notes
Top comments (0)