AI agent に UI を作らせるなら、browser を開けたことを完了条件にしないWhen delegating UI development to an AI agent, treating a browser launch as the…

AI coding agents are increasingly asked to build user interfaces from start to finish, but a recurring failure mode is treating the moment a browser window opens as proof that the work is done. A post on Qiita argues that this shortcut produces shallow results, and that the way you define an agent's completion condition has an outsized effect on the quality of what it ultimately delivers.

The core issue is the gap between an application that starts and an application that actually works. When an agent runs a development server and a browser launches without throwing an error, it can report success even though the page is blank, a component failed to render, an API call returned nothing, or an interaction silently breaks. From the agent's perspective the task looks complete because the observable signal it was told to watch for—a running process, an open browser—has been satisfied. The visible output, however, may bear little resemblance to the feature that was requested.

The post's recommendation is to design success criteria that force the agent to inspect real rendering and behavior rather than process state. In practice that can mean requiring the agent to capture a screenshot of the rendered page and evaluate it, to confirm that specific text or elements are present in the DOM, to exercise user flows such as clicking a button or submitting a form, and to verify that the resulting state matches expectations. In other words, the definition of done should describe the observable outcome a human would check, not merely that the tooling launched.

This concern is closely tied to how modern agentic coding tools operate. Systems such as GitHub Copilot's coding agent, Cursor, and Claude Code work in a loop: they take an instruction, call tools like a shell or file editor, observe the result, and decide whether to continue or stop. That stopping decision depends heavily on what the agent treats as evidence of completion. If the only feedback is an exit code or a launched server, the loop terminates early. Providing richer feedback—test results, DOM assertions, or visual snapshots—keeps the loop running until the real goal is met.

Browser automation frameworks like Playwright and Puppeteer are commonly paired with agents for exactly this reason. They let an agent drive a real or headless browser, wait for elements, read rendered content, and take screenshots. Combined with vision-capable models that can interpret those screenshots, an agent can approximate the check a developer performs by simply looking at the screen. Some teams also lean on end-to-end or component tests as machine-verifiable acceptance criteria, which give the agent an unambiguous pass or fail signal rather than a vague sense of being finished.

The underlying lesson connects to a broader theme in prompt engineering and agent design: agents tend to optimize for whatever target you specify, so a weak or proxy success condition invites weak results. This mirrors the well-known problem of proxy metrics, where optimizing an easy-to-measure stand-in diverges from the outcome you actually care about. Specifying verification steps explicitly, and making them part of the acceptance criteria, appears to be a more reliable way to raise output quality than hoping the agent infers the intent on its own.

For teams adopting these tools, the practical takeaway is to write instructions that state what "working" means in concrete, checkable terms. That might include listing the expected UI elements, the interactions to test, and the conditions under which the task should be considered incomplete and retried. It is also worth remembering that no automated check fully substitutes for human review, particularly for visual design, accessibility, and edge cases that are hard to encode. Still, replacing "the browser opened" with "the interface renders and behaves as described" is a small change to the completion condition that is likely to meaningfully improve what an agent produces, and it costs little to adopt as a default habit when delegating UI work.