It might be time to say goodbye to HTML inputs

Empirium is an experiment-tracking system I built for ZAR, my company. It replaces Linear. Teams use it to manage assumptions, run experiments, record what they learn, track metrics. This is the kind of app that would normally normally be drowning in text-entry forms. Multi-step wizards for creating experiments. Nested evidence fields for updating assumption confidence levels. Comment dialogs. Learning capture modals.

I built none of that. I mean, my first version had that stuff. But along the way I figured out that the time I was spending on those parts of the app were pointless.

So in a fit of ebullient audacity, I deleted all the new and edit templates and replaced every “Create” and “Edit” button with a small prompt popup. You click it and it gives you a short prompt that you can paste into Claude Code to get you started adding or modifying whatever it is that you want to change. Claude calls the right MCP tool, the database gets updated, and then since this is a modern Ruby on Rails application, Turbo Streams update the web page in real time.

In other words, my web interface is now almost purely a read layer. Dashboards and detail pages and evidence timelines. The only interactive things left are navigation, filtering, and some status toggles. The search feature. Updating your profile and settings. Every other write operation goes through MCP.

Really?

Yeah. Everyone at ZAR uses Claude Code. Literally, all day, every day, for everything they work on. That’s the crux of why this works. I like to say that we’re living in 2028. The rest of you will get there eventually. Probably.

Laziness, Impatience, and Hubris

Complex webapps are expensive to build and get right. Lots of design time, good judment and taste. And iteration. Linear is like the pinnacle of the form, don’t you think? Must have taken tens of thousands of hours of effort to build the user experience for that beast.

But giving an agent harness like Claude Code MCP access to your API is easy and it handles complicated structured input perfectly. Master-detail evidence records, nested learnings, conditional fields, whatever. Several of the forms I was contemplating designing for Empirium were going to be a multi-section beast with radio groups, conditional visibility, and validation UX that takes a long time to get right.

But won’t my users get frustrated by not being able to enter data directly. What hubris!

Lazy, impatient, and hubristic. That’s what makes me a great programmer.

The prompt bubble

What makes the UX intuitive is the MCP PROMPT bubble. It renders a small icon that opens a native element with a pre-composed command. One click copies it to clipboard.

The icons follow a convention: plus for create, pencil for edit, terminal for general MCP actions, chat for comments, arrow-right for status transitions.

The prompts themselves are imperative with just enough context. Entity IDs, natural keys, names, URLs (if appropriate). Enough that Claude Code can always find the right resource without asking follow-up questions. The user copies the prompt then finishes it in their console. And if they don’t supply required attributes, Claude helps them figure that out. The conversation is a vital part of the user experience.

But what does it mean?

I’ve been building web apps for nearly 30 years. Forms with inputs, selects, radio buttons, checkboxes, and textareas were always the answer to “how does data get into the system.” You render forms, the user fills them in, you submit. It’s so ingrained that I must admit questioning that modus operandi felt kinda weird.

But when it comes down to it, a form is really just a translation layer between what the user wants and what the database needs. And my users already have a better translation layer open in their terminal. One that they converse with in plain English. So now the form is the slow path. The redundant path.

Caveats, since people will ask

This is not a pattern for consumer apps. It’s for teams where everyone runs Claude Code or something like it.

The prompt bubbles are kind of silly, and they won’t get used very much once users understand the modality, but I think their presence matters more than you’d might think. Without them, new users would be really confused. With them, it’s like immediately, “Oh, okay I see what you did there.”

You still need some forms for onboarding and for ceremony-type interactions where the clicking-through is the experience. I also left normal forms in for profile and settings.

Be kind, give them an MCP Setup page

Ideally you want instructions on how this newfangled user experience works very easy to spot in your main navigation. The setup page should have clear instructions and not make them go elsewhere to grab an API key.

Definitely make your views update in realtime

Turbo Streams are what make the read-only UI feel alive. Without broadcasts from model callbacks, you’d be telling people to refresh their browser, which would kill the whole thing.

Final thoughts

One of my favorite aspects of these interesting times we’re living in is just how innovative/brazenly cocky you can be with design decisions like the one I just described. Because the cost is minimal!

The entire transformation I just described was five commits on a low-key Friday night. The big rewrite, then prompt bubble polish, then z-index fixes (always z-index), then cleaning up dead form code. Testing. Deployed.

What a time to be alive!