AI coding agents are good at producing UI code and surprisingly bad at proving that the UI actually works. A compile pass is not the same as a rendered screen, a correct semantic tree, or a click that reaches the intended handler.
Compose Multiplatform 1.12.0 adds an experimental MCP server to Compose Hot Reload. It gives an AI coding agent a feedback path into a running Compose application: trigger a reload, take a screenshot, inspect the semantic tree, simulate clicks and text input, and read application logs.
That changes the useful question from “Can the agent write this composable?” to “Can the agent observe the result of its edit and detect a broken interaction?”
What the Compose Hot Reload MCP server exposes
According to JetBrains’ release announcement, the experimental server connects an agent to a running app and supports:
- triggering reloads after an edit
- taking screenshots of the rendered UI
- inspecting the semantic tree
- simulating clicks and text input
- reading application logs
The Compose Hot Reload documentation contains the connection details and the current tool list. The Compose Multiplatform 1.12.0 release notes are the versioned reference for the feature.
This is an observation loop, not an automatic correctness proof. A screenshot can show that a button is visible, while the semantic tree and logs can provide stronger evidence about labels, roles, and runtime failures. None of those alone proves that the feature satisfies the product requirement.
A practical agent verification loop
A useful harness should make the agent follow an explicit sequence rather than letting it stop after compilation:
- Edit one bounded change. Keep the diff small enough that a failed observation has a plausible cause.
- Reload the running app. Record whether reload completed or timed out.
- Check the semantic tree. Assert that required nodes exist with the expected labels or roles.
- Capture a screenshot. Use it to catch layout regressions, missing content, or an unexpected screen state.
- Exercise one critical interaction. Simulate the click or text entry that matters for the changed path.
- Read logs after the interaction. Treat new exceptions or error-level entries as a failed run.
- Store evidence with the change. Keep the reload result, assertions, screenshot reference, and relevant logs attached to the agent run.
The important design choice is to keep these as separate checks. “The screenshot looks right” should not silently substitute for “the semantic node exists,” and “the reload succeeded” should not substitute for “the interaction produced the expected state transition.”
Where this helps most
The MCP server is especially useful for UI changes with a short, deterministic path:
- a form field must accept input and update state
- a button must become enabled after validation
- a navigation action must render a specific destination
- a loading or error state must appear under a controlled condition
- a regression must be reproduced from a known starting state
For each path, define an observable contract. For example: after entering a valid email and clicking Continue, the semantic tree contains the next-screen heading, the log contains no new exception, and the screenshot shows the expected state.
The tradeoffs and the safety boundary
This is an experimental developer tool, so it should be treated as a test harness rather than a production control surface. An agent that can simulate input and inspect a running app has meaningful capabilities. Run it against a disposable or tightly scoped environment, avoid real credentials and production data, and keep the available actions limited to the application under test.
There is also a determinism problem. Screenshots and logs can vary with timing, platform, fonts, network state, and background work. Prefer assertions over stable semantic properties and explicit state transitions. Use screenshots as supporting evidence, not as the only oracle.
Finally, separate execution evidence from product correctness. The tool can show what happened in the running app; it cannot decide whether the feature is desirable, safe to ship, or compliant with a business requirement. Those remain separate review gates.
Bottom line
Compose Hot Reload’s experimental MCP server is valuable because it closes part of the loop between an AI coding agent and the UI it changes. The practical benefit is not that the agent becomes trustworthy by default. It is that the harness can require observable evidence before accepting a UI edit.
The strongest workflow is therefore: small diff, reload, semantic assertions, targeted interaction, log check, and persisted evidence. Give the agent a way to see the result, then make the acceptance contract stricter than “it compiled.”
Top comments (1)
The useful distinction here is between observing a screen and asserting a state transition. I would make the expected precondition and postcondition first-class evidence too: e.g., starting from a known form state, submit valid input, then assert both the destination node and the persisted domain change. That catches flows that look correct but never commit.