A UI Task Is Not Done When the Agent Says It Is

A coding agent can produce a plausible UI change and still miss the behavior a person sees. That gap is one of the problems I am exploring while building Spexop UI.

A small example

Imagine a task: add a settings control and explain its state clearly. A useful check might include three layers:

• Deterministic checks: Does the code build, and do focused tests cover the intended state change?
• Browser observation: At the exact revision under review, can a real browser reach the control, operate it, and display the expected state on the relevant screen sizes?
• Human decision: Does the behavior actually meet the product intent and fit the user's workflow?

Passing one layer does not silently pass the next. A test double can exercise coordination logic, but it cannot prove that a live provider API works. A screenshot can show one browser state, but it cannot prove every interaction. A successful implementation does not grant product acceptance.

What Spexop is aiming to coordinate

The intended Spexop UI companion will keep the developer's existing coding agent responsible for planning, design, risk, and oversight. Bounded, user-connected API workers would handle routine UI tasks.

Spexop would track a minimal milestone, gate, and task flow; attach checks to the revision being evaluated; and show progress, blocked, or needs-user-action in plain language.

Today the evidence is narrower: a private local coordination prototype with test doubles and a loopback browser status view. There is no packaged desktop app or verified live provider worker, and external product acceptance is still open.

I am interested in the boundary between automated evidence and a human go/no-go decision. For a small UI task in your project, which browser behavior would you insist on checking before you trusted a worker's result?

Current Spexop direction and status · Product overview