Fuaranfuaran

The source for generative UI

Two authors, one language

Last reviewed: July 2026.

Ask a coding assistant to "add a fourth metric to the dashboard," and watch what else happens: a data grid's sort order resets, a mid-flight animation restarts, a loading skeleton flashes. The new metric works; the rest of the dashboard quietly degrades. Over a twelve-turn session, each turn locally correct and a little lossy, the interface accumulates drift nobody asked for and nobody can trace.

This is the cost of a specific architectural choice, shared by essentially every generative-UI tool: the UI language was designed for human authors, and the model is treated as a text generator emitting strings in that language. JSX, HTML, component registries, schema-validated cards – the surface varies, the choice doesn't. Four failure modes follow and compound under iterative editing: regenerated fragments carry no identity guarantee for unchanged children; type errors surface only after emission, as compiler strings; the model has no structural way to inspect what its UI is doing; and an invalid emission earns a diagnostic written for humans, with no machine-usable hint about what would have been valid.

There is a well-known observation about passwords: decades of policy trained everyone to choose passwords that are hard for humans to remember and easy for computers to guess. Generative UI is the mirror image – languages easy for humans to write and hard for AI to maintain. Both are accidents of a design space nobody thought to question; the remedy in both cases is to redesign for the actual users.

Fuaran's answer is twin-surface projection: one typed record contract produces two equal surfaces. Humans author against an ergonomic typed surface (records, lists, pipes – in F#, TypeScript, Python, and the other host languages, with deliberately matching constructor names). Models emit the flat JSON wire surface directly against the same contract. Neither surface is a translation of the other; neither is subordinate. Everything else on these pages hangs off that decision:

The claim is not that models can't write JSX – they demonstrably can. It is that designing for both author classes turns AI authoring from approximation (emit text, hope it compiles, hope it preserved what mattered) into engineering: a construction the author, human or machine, can verify rather than merely attempt.