Google Research recently described generative UI as AI models generating a full custom interface for a prompt instead of plain text. explainx.ai's own Melo — the AI learning copilot built into /dashboard/learn — has been doing a version of this since launch, with a different architecture built specifically for teaching: instead of writing raw code per request, Melo's tutor model selects and populates a curated library of interactive visual components, live, in the middle of teaching a concept.

What this actually looks like in a lesson
When Melo is teaching a concept — how an agent loop works, what a context window is, how RAG retrieval grounds an answer — it doesn't just describe it in prose. Mid-response, it can emit a specific interactive illustration matched to exactly what's being taught, and that illustration streams into the conversation as part of the same answer, not as a separate loading step or a static image pasted in afterward.
The current library covers eight visual types, each a real, pre-built React component:
| Visual | What it teaches |
|---|---|
| AI Foundations | The AI/ML/DL relationship, or training vs. inference, or model/data/output |
| Agent Loop | A step-by-step walkthrough of an agent's goal → reason → tool → observe → decide cycle |
| Token Context | How text gets tokenized and fits inside a context window |
| RAG Pipeline | A query, retrieved documents (relevant and not), and a grounded answer |
| Prompt Anatomy | The sections of a prompt and which are essential vs. optional |
| Sampling | How a model samples among candidate next-tokens at a given temperature |
| Embedding Space | A 2D projection of how semantically related concepts cluster together |
| Concept Flow | A domain-agnostic fallback — a labeled node-flow diagram for any topic outside the AI-specific set |
That last one matters more than it might look: Concept Flow is what lets Melo illustrate literally any subject, not just AI and machine learning topics — the stages of a court case, the phases of cell respiration, the thrust stages of a rocket launch, all use the same underlying interaction pattern as the AI-specific visuals.
How it actually works — a spec, not raw code
This is the real architectural difference from Google's approach, and it's worth being precise about it. Melo's model doesn't generate HTML, CSS, or JavaScript for a visual. It emits a fenced, typed JSON block — a spec with a required component field (which of the eight visuals to render), a mode (watch, explore, or recall), a difficulty level, and then whatever topic-specific content that visual type needs: the steps of an agent loop, the documents in a RAG pipeline, the sections of a prompt.
A parsing layer handles the real-world messiness of streaming model output — a block that's still arriving with its closing fence not yet written, a model that mislabels the fence as ```json instead of the expected ```explainx-visual, or occasionally emits bare JSON with no fence at all. None of that is allowed to leak raw JSON into the chat the learner sees: a plausible structured block is always stripped from the displayed text, whether or not it turns out to be valid, and an invalid-but-attempted block renders a graceful fallback rather than an error or a wall of JSON.
Once a valid spec is extracted, a strict parser validates every field against the component's actual shape — an agent-loop spec needs 3-8 well-formed steps, an ai-foundations spec needs a valid focus value, and so on — before any of the eight pre-built React components ever render it. That validation step is what makes the "curated library" approach meaningfully different from raw code generation: a malformed spec fails to render cleanly, rather than executing broken or unsafe generated code in a learner's browser.
What happens when Melo gets it wrong
This matters more than it sounds like, because model output is never perfectly reliable, and a learning product has to handle that gracefully rather than breaking the lesson. If Melo's model emits a spec missing a required field, or with a value outside what a component expects — an agent-loop with only two steps, say, where the minimum is three — the strict validator rejects it before it ever reaches a rendering component. The system doesn't then show the learner a JSON error or a broken half-rendered diagram; it falls back to a plain-text explanation instead, and strips the failed structured block from the visible markdown so the learner never sees the raw attempt at all. The failure mode, in other words, degrades to "this concept got explained in words instead of a diagram this one time" rather than "the lesson visibly broke." That's a deliberate design choice that only makes sense because the component library is small, fixed, and fully known in advance — it's exactly the kind of graceful degradation that's much harder to guarantee when the model is generating arbitrary code that could fail in effectively unlimited ways.
Watch, explore, recall — the same visual, three jobs
Every visual in the library supports three interaction modes, and the same component can appear in any of them depending on where a learner is in a lesson:
- Watch — the learner observes a worked example, seeing the concept demonstrated rather than driving it themselves.
- Explore — the learner interacts with the concept directly, manipulating the visual to build intuition.
- Recall — the learner gets tested on the concept, with the system tracking outcome data (attempts, hints used, and whether the result was a strong, partial, or weak recall) per concept.
That evidence-tracking layer is what turns a one-off illustration into part of an actual learning loop rather than a decorative diagram — Melo can use recall outcomes to judge whether a concept actually landed, not just whether a visual was shown.
A concrete walkthrough of what this looks like in practice: a learner asks Melo to explain how RAG (retrieval-augmented generation) works. Rather than describing it purely in prose, Melo can emit a rag-pipeline spec in watch mode — a specific query, a handful of documents (some genuinely relevant to that query, some plausible-looking distractors), and the grounded answer that results from combining them, all populated with content specific to the exact example Melo chose to illustrate the concept with. If the learner then asks to try it themselves, Melo can re-emit the same component type in explore mode, letting them swap which documents get marked relevant and watch how that changes the grounded answer. Later in the same conversation, testing comprehension might trigger the same component again in recall mode — this time asking the learner to identify which documents should be marked relevant before revealing the answer, with the outcome (strong, partial, or weak) logged against that learner's understanding of RAG specifically, not just "did they see this once."
That's the practical payoff of building on a fixed component library rather than generating a bespoke interface each time: the same well-tested rag-pipeline component gets reused across all three pedagogical moments in a single lesson, each time populated with fresh content but never with fresh, unvalidated code — which is exactly the reliability tradeoff a real-time, mid-conversation teaching tool needs to make.
Why a component library instead of raw code generation
Google's generative UI research makes an explicit, honest tradeoff: generating arbitrary HTML/CSS/JS per prompt is maximally flexible — genuinely any interface shape is possible — but Google's own writeup acknowledges generation can take "a minute or more" and produces "occasional inaccuracies." For a learning product specifically, where a visual needs to render instantly as part of a flowing, real-time teaching conversation, that latency and error profile is a hard constraint, not a minor tradeoff.
Melo's design optimizes for the opposite end of that same tradeoff: a smaller, fixed set of visual types means each one can be genuinely well-built, accessible, and fast to render — the model's job shrinks from "write correct, working code" to "pick the right visual and fill in the right content," which is a much easier, faster, and more reliable task for an LLM to get right on the first try, every time, mid-conversation. The cost is real: Melo can't generate a never-seen-before interface shape the way Gemini's implementation can. For a teaching product where the same handful of pedagogical patterns (a process walkthrough, a labeled diagram, a comparison, a recall quiz) cover the overwhelming majority of what actually needs illustrating, that's a trade explainx.ai has made deliberately, not a limitation of getting there eventually.
Related on explainx.ai
- Google's Generative UI: Gemini 3 Explained
- Introducing Melo: The AI Learning Copilot Built Into explainx.ai
- Introducing Interactive AI Learning Pathways
- What Is an Agent Harness? Complete Guide
- AI Tutor Effect Size: Dartmouth Phosphor Study
- Try it: explainx.ai/dashboard/learn
Describes Melo's generative UI implementation as of August 17, 2026. The visual component library and interaction modes described here reflect the current production system and may expand over time.
