Most discussions of “AI-generated UI” still assume the AI is generating components — JSX trees, Vue templates, Svelte files, whatever the host framework expects. The model produces something that needs to be compiled, hydrated, and reconciled before the user sees pixels. The output is shaped by the framework’s mental model: a closed component tree, props passed downward, events handed back upward through callbacks, side effects fenced off into hooks or stores or signals.
That shape was designed for humans. Humans who knew the framework, who learned its idioms, who could be trusted to put analytics calls in the right hook and accessibility attributes on the right element. It was a pragmatic answer to a specific question: how do we make a complicated UI maintainable by a small team of developers who all agree to think the same way?
The next question is different. How do we make a complicated UI composable by code that doesn’t know our team or our framework — code that will be writing interfaces dynamically in response to product intent it discovered five seconds ago?
The honest answer is: probably not by teaching the model to emit JSX.
Kitsune is an early exploration of the other path.
A small bet on the platform
The browser has, very quietly, become a modern application development platform.
It has native components, scoped styling, declarative attributes, composable events, real forms, working dialogs, working popovers, working selects, accessibility semantics that the rest of the stack inherits for free, local storage, sync APIs, intersection observers, view transitions, container queries, container style queries, and a custom element lifecycle that does most of what a framework lifecycle does without any framework. None of this is new. Most of it has been shipping since 2020 or earlier. The discourse has not caught up.
Modern Frontend is the long version of that argument — a history of how the frontend stack got to where it is, what the original problems were that each abstraction layer was solving, which of those problems the platform now solves directly, and what’s left over that genuinely belongs in a framework. It’s also the rationale for why now is a sensible moment to revisit HTML, CSS, the DOM, events, forms, accessibility, storage, and custom elements as architectural foundations rather than implementation details we politely hide from view.
Kitsune is the application kit that takes that argument seriously enough to ship.
What Kitsune actually is
Kitsune is a thin application layer on top of browser primitives. The pieces are deliberately small:
- Components describe meaning, not vendor integrations. A button says what it is and what happened, not which analytics library should be notified.
- Boundaries describe context. A surface, a feature, an entity, a route — declared once and inherited by every interaction underneath.
- Modules own application capabilities. Analytics, observability, audit, storage, sync, permissions, feature flags, validation, command palette — each one is a separately installable, separately observable piece of product infrastructure.
- A runtime coordinates the loop. The DOM is the context graph; events are facts; commands are requests; modules listen and act. Nothing in the UI has to know about any particular module to participate.
The closest analogue to what this feels like to use is just writing HTML — except that the HTML is wired into an application runtime that understands what it means.
<kit-shell name="designer">
<kit-boundary
surface="token-editor"
feature="design-system"
entity-type="token"
entity-id="color.primary"
>
<kit-button meta-event="token.saved" meta-intent="primary-action">
Save token
</kit-button>
</kit-boundary>
</kit-shell>That button does not import an analytics SDK. It does not know about feature flags. It does not check permissions. It says: this is a primary-action button; the event “token.saved” happened when it was used. The boundary says: this happened inside the token editor, inside the design-system feature, on color.primary. The runtime turns that into a normalized event. The installed modules — analytics, observability, audit, storage — each decide independently whether they care.
The whole architecture is described in the Kitsune architecture brief. It’s the document I’d point a contributor or skeptic at before any of the package READMEs.
Why this shape matches AI-generated interfaces
The reason this matters for AI-shaped UIs is not “Kitsune is special.” It’s that the surface area an AI has to learn to generate a useful interface drops dramatically.
To generate a Kitsune view, the model needs to know:
- Semantic HTML it already knows extremely well.
- A small, stable set of custom element names with documented attributes.
- A small, stable set of
meta-*attributes that describe meaning. - A small, stable set of boundary attributes that describe context.
That’s it. The model isn’t asked to learn this team’s specific component library. It isn’t asked to predict which hook a side effect belongs in, or which provider it should be nested under. It emits markup that is meaningful on its own terms. The runtime supplies the application layer — validation, permissions, flags, storage, sync, analytics, audit, diagnostics, command handling — around whatever the model produced.
When the generated UI is wrong, the failure mode is legible. You can read the HTML. You can see the meta attributes. The diagnostics module can tell you which event fired and which boundary it inherited. You don’t have to reconstruct a virtual DOM in your head to figure out what the model meant.
This isn’t a complete answer to AI-driven UI. The model still has to choose the right semantic elements, attach the right meta attributes, declare boundaries that reflect actual product context. But it’s a substantially smaller, more inspectable, more progressively enhanced surface to get right than the alternatives.
The honest “early stage” disclaimer
Kitsune is an exploration. The pieces are usable today — there’s an umbrella package on npm, demo apps in the repo, a runtime, a UI element set, a React provider for incremental adoption, and ten or so capability modules. But the shape will change as we find out what the model is actually good at emitting, what survives contact with real product teams, and which abstractions earn their keep.
What’s working well so far:
- The runtime loop (semantic component → boundary context → event/command → module). This part has held up across the demos and our internal use.
- The “boundaries describe context, components describe meaning” split. It collapses a lot of incidental complexity that normally lives inside individual components.
- The capability-module model. Adding analytics or audit or permissions to an app turned out to be approximately as easy as adding a script tag.
What’s still open:
- The exact attribute vocabulary for
meta-*. We have a working set; it will probably get smaller and more opinionated. - How AI-generated views express layout intent vs. concrete structure. The browser has good primitives for this (
grid,flex, container queries) but choosing the right level for a model to target is unresolved. - Module composition under load. The single-page demos are not the same problem as a long-running multi-feature shell.
Calling it early-stage is not false modesty. It’s where it is.
If you want to look
- The Kitsune repo on GitHub — runtime, app, UI, modules, devtools, the React provider, the demos, the spec.
- The umbrella package on npm —
pnpm add @atheory-ai/kitsuneand the documented subpaths. - The architecture brief — the long version of why the runtime is shaped the way it is.
- Modern Frontend — the historical and design rationale for why we think the browser is the right substrate to build on right now, and why the abstractions most teams treat as table stakes are not as load-bearing as they look.
- The Kitsune documentation site at KITSUNE.ATHEORY.AI (deploying alongside this post).
The framing we keep coming back to: the browser quietly became a real application platform; the next generation of UI is going to be assembled by code; we want a kit that respects both of those facts at the same time. Kitsune is the attempt.
If the attempt is useful to your work, the issues are open. If it’s wrong somewhere, the issues are also open.