Opus 4.8 agentic GUI work: cannot converge on a trivial UI fix; verifies against synthetic fixture not the live app; stale multi-instance confusion

Summary. Over 5+ attempts in one session, the model could not get a simple UI change (a per-row drop-down in an input table) to actually appear in the running application, and repeatedly reported progress that the live app did not show.

Failure modes

1. Verified against a synthetic fixture, not the live app. The model confirmed its logic with a self-built in-memory test and called it "verified," while the actual running application kept showing the old/wrong behavior. It did not drive the real app to confirm the user-visible result.

1. Stale-build / multi-instance confusion. The model launched the application ~10 times in the session. A code edit only takes effect in an instance started after the edit, so the user kept viewing older instances without the change. The model failed to manage this (stop old instances, run exactly one, or tell the user which window is current) until very late.

1. Oscillating implementations. It flipped the same UI element back and forth (all cells vs a subset) based on misread screenshots, instead of pinning the requirement once.

1. Modify -> test -> fail without convergence on a low-complexity UI task.

Impact

Many wasted cycles on a trivial UI element; the user could not tell whether any fix had actually landed.

Request

For agentic coding with a GUI: (a) verify by driving the actual running app, not a synthetic stand-in; (b) manage app lifecycle — run a single instance, restart it after edits, and state which build/window is current; (c) pin requirements before editing; (d) avoid oscillation between implementations.

Environment

Claude Code, model Opus 4.8.