A local-first notes manager and issue tracker for agents and humans entered the author's workflow at a critical moment. Emm's core promise: users can start building with local agents without ever connecting to the cloud. That promise introduced unexpected complexity. A project exists before it backs up to the cloud. A user might maintain many projects. When syncing to Emm's server, a signed-in user is required. The user might later want to change that signed-in user. And for a young company, first-time user experience is existentially important. These constraints meant that designing agent workflows could not be an afterthought. The author needed to prototype multi-step processes with more than twenty screens. The question was how to get from concept to testable flow without losing weeks to iteration.

First attempt: trust the agent to design the workflow

The author asked an agent to ask questions, identify key decisions, generate options, then create a specification. After that, the agent would implement the spec. To the agent's credit, it handled the plumbing that years prior would have taken several days. However, the flow it selected required the user to make seven clicks when four would suffice. The agent also navigated the user to pages where no decision was being made, when the flow could have been consolidated into fewer pages. The result was a workflow that felt bloated and forced the user through unnecessary steps.

Second attempt: build one screen at a time

The next strategy was to build the full experience, one screen at a time. Start with creating a project, then move to putting it on the cloud, then inviting a user, then accepting a user, and so on. The author gave up on the agent having taste. Instead, the author specified exactly what was wanted, waited for the agent to implement, gave feedback, and asked for the next screen. This also failed for two reasons. The application is pure Rust with no framework. Even simple changes take the agent ten to twenty minutes to make. Adding a single branch of a login could take hours. The second problem is that design is iterative. The author built something that basically worked, but was confusing to the user and did not handle all edge cases well. Rebuilding it the old way would take another eight or more hours.

Third attempt: ChatGPT Desktop HTML prototype

Finally, the author switched from a hosted code agent to ChatGPT Desktop. The agent was asked to build out the entire mock application. The author saw windows spanning different surfaces: web browser, the app, pop-ups from macOS passkey, email, and also pages not tied to any surface. The agent opted for a dropdown to test different starting configurations. The process still took about three hours — the task was iterative and required many decisions and testing. By 11:30 the author was not at sharpest. Nevertheless, the end result was a full prototype that made the desired behavior crystal clear and covered all use cases. The author let it run all night to complete the work.

What the pattern means for teams

When the back-end machinery is complex, having the AI agent produce a working HTML prototype first offers a concrete thing to test against. The prototype surfaces edge cases, clarifies the intended behavior, and reduces the mental overhead of imagining abstract flows. Once the prototype is validated, the agent can implement the real implementation in one pass, rather than cycling through screens iteratively. This approach is especially valuable when the real implementation language or framework adds compilation or rebuild overhead, as was the case with the pure Rust application.

  • Start with an HTML prototype when the workflow has more than twenty steps.
  • Let the agent generate the full mock, spanning all surfaces the final product will touch.
  • Test every situation through the prototype before asking the agent to implement the real code.
  • Use the validated prototype as the single implementation path, avoiding iterative screen-by-screen rebuilding.

Why this matters for local-first tools

Tools like Emm that prioritize local agent operation must get the user experience right from the first run. A cloud-dependent workflow can mask issues that appear only when offline or when data stays on device. An HTML prototype revealed the full shape of the workflow before any real code was written. That early clarity saved time that would otherwise be spent reworking screens after the fact. For a small team, that time saving is the difference between shipping on schedule and missing a window.

The author's experience shows that prototyping is not a luxury when working with AI agents on complex, multi-step workflows. It is a disciplined step that prevents costly rework and keeps the user journey clear from the first interaction.