Google Lets Teachers Generate Interactive Simulations from a Single Prompt: Gemini Builds the UI, Four Automated Checks Provide Guardrails, and Teachers Hold the Final Gate

From online textbooks to video repositories, digital educational tools have transformed how students access information, yet digital learning often remains a passive experience. Students sitting in front of screens clicking "Next" may appear to be learning, but their cognition remains in a state of passive reception.

In cognitive science, the well-known ICAP framework—which categorizes learning behaviors in increasing depth as Passive, Active, Constructive, and Interactive—has long demonstrated that interactive learning, where learners manipulate variables and observe immediate feedback, is far more effective at fostering conceptual models and long-term retention than passive listening. Previously, interactive tools such as physics simulations typically required dedicated development teams writing custom code. This process was lengthy and expensive, and teachers could rarely fine-tune variables to match their daily lesson plans.

Google Research recently unveiled an experimental project called "learning interactives" that aims to change this paradigm using large models: a teacher simply inputs a subject, grade level, and instructional topic, and the system uses Gemini to automatically generate a web-based interactive simulation complete with staged challenges, sliders, telemetry charts, and scaffolded feedback.

Directly introducing generative UI—a technique emerging in front-end development where AI dynamically constructs interface components based on conversational intent rather than invoking pre-written static code—into educational settings was not as seamless as one might expect. The accompanying technical report highlights a sobering metric: even when pedagogical planning is already complete, only 3.5% of first-attempt interface generations pass all automated checks.

Why Off-the-Shelf Generative UI Cannot Be Used Directly for Teaching

According to the report, off-the-shelf generative UI excels primarily at producing one-off widget-like components, but struggles with multi-stage, structured instructional simulations.

When deployed in a classroom, prompting a large model directly to "write a physics experiment interface" runs into two major barriers:

The first barrier is cognitive offloading. Large language models are fundamentally designed to minimize effort for users by providing answers through the path of least resistance. However, learning requires productive cognitive friction—students must derive solutions, test hypotheses, make errors, and adjust parameters themselves to truly grasp the mechanisms behind concepts. If an AI-generated interface is overly helpful and hands over shortcuts, students will offload their thinking to the machine, superficially completing tasks without genuine knowledge construction. At the same time, cognitive research shows that unguided, pure discovery learning is largely ineffective (Kirschner, Sweller, Clark 2006); active learning requires explicit scaffolding and guidance, roles traditionally fulfilled by teachers in the classroom.

The second barrier is the physical and pedagogical rigor of dynamic simulations. A viable educational interactive must ensure that its underlying logic obeys accurate scientific laws, that numerical sliders update plots in real time, and that level goals are mathematically and physically solvable. Standard generative models writing code are prone to subtle flaws: for instance, the report documents a chemistry interactive where the overall setup was sound, but the table holding flasks overflowed the viewport and a telemetry panel obscured simulation objects; more critically, level goals were sometimes mathematically impossible to achieve.

Relying solely on a single prompt to let the model generate freely inevitably reduces instructional software to uncontrollable, half-baked prototypes.

Deconstructing into Four Stages: Turning Curricula into Staged Games

To ensure generated interfaces carry instructional value, the research team structured the generation pipeline into four sequential stages, establishing guardrails between text planning, level design, code implementation, and pedagogical guidance.

Throughout this pipeline, teachers remain central decision-makers: the workflow begins with a teacher's request (specifying subject, grade, topic, and optional requirements); AI then generates concrete learning goals for the teacher to review and modify; for approved goals, the system generates 5 candidate simulations per request, designed for teachers to select the one best aligned with their instructional intent (in the empirical study with 12 teachers, internal review selected the top candidate before presenting it); finally, newly generated interactives must receive teacher approval before entering the public library.

Stage 1: Simulation idea. This stage is entirely text-based. The teacher inputs the subject, grade band, and specific topic (such as complex DC and AC circuits in high school physics). Gemini first outlines precise, measurable learning goals for teacher review and confirmation. Once the target cognitive outcomes are established, the model conceptualizes the simulation scenario: identifying entities (such as pulse shapers or resonators), governing scientific laws, required telemetry readings and plots, student-adjustable knobs, and the final trigger actions.

Stage 2: Scaffolding. Given an experimental scenario, students cannot simply be dropped into an unguided sandbox. The system prompts the model to decompose core concepts into 5 progressive levels of increasing difficulty. To avoid abrupt difficulty spikes or ambiguous goals, these 5 level goals are generated sequentially rather than all at once: each level is validated before the next is generated, ensuring that each step demands deeper inquiry while remaining grounded in preceding concepts.

Stage 3: Gen-UI. With pedagogical goals locked in from the first two stages, Gemini generates HTML and JavaScript code, translating abstract levels and control logic into interactive interfaces executable in a browser. This stage represents the most fragile and error-prone engineering bottleneck.

Stage 4: Guidance. Once the interface functions properly, the system layers on peripheral instructional supports. This suite includes an introductory Tour to familiarize students with controls, formulas and theoretical references tucked into a right-hand toolbox, on-demand scaffolded hints when students struggle, and targeted feedback modals upon success or failure.

Within this interface, the system embeds two critical learning support mechanisms:

Scaffolded hints: Progressive clues delivered incrementally based on where a student is stuck. For example, hints may direct students toward relevant formulas or clarify specific terminology; hints are tiered, offering worked solutions only after students have explored independently, avoiding premature answers that disrupt active thinking.

Formative feedback: Explanations grounded in underlying principles triggered when students make errors or achieve goals, explaining why a given parameter configuration works or fails. For instance, upon completing a level in the number line symmetry interactive, the modal confirms success and explains: the blue car is at +6, so its symmetric counterpart is at -6, placing both cars 6 units from zero. Based on teacher feedback, explanatory feedback for incorrect attempts was added later in the study (Section 3.1 of the report) to help students remediate misconceptions during trial and error.

From 3.5% to 69.3%: Automated Adversarial Testing and Self-Refinement in Code Generation

In Stage 3 (front-end code generation), test data revealed that even when learning goals, simulation ideas, and level progressions were thoroughly validated, single-shot unassisted generations passed all technical and pedagogical criteria at a rate of only 3.5%.

Under these evaluation criteria, the vast majority of first-attempt outputs failed on at least one dimension. To address this, the research team designed a multidimensional automated evaluation framework (Auto-rater) that renders code in Chrome and inspects it across four categories:

• Visual: Checking for viewport overflows, overlapping elements (such as telemetry panels obstructing apparatus), or extraneous distracting elements.
• Mechanics: Ensuring interactive controls like buttons and sliders operate correctly.
• Telemetry: Verifying real-time readouts and dynamic plots (such as curves tracing transient voltage and current changes in RC circuits).
• Solvability: The most technically distinctive check. The system dispatches dedicated testing agents to open the browser, manipulate controls like a human student, and deliberately test extreme parameter ranges to verify whether level goals are genuinely solvable within the interface.

If any check fails, diagnostic feedback is routed back to the model for targeted code revisions, iterating until all criteria are satisfied (evaluations consider both generated code and rendered visual output in Chrome).

This multi-round self-refinement cycle produced substantial gains. With pre-requisite goals validated, the overall interface pass rate climbed from 3.5% on the 1st round to 28.9% midway, ultimately reaching 69.3% after 10 rounds of self-refinement.

Notably, progress was not monotonic across all categories. According to data in the technical report:

• Telemetry pass rate: rose steadily from an initial 23.3% to 93.5%;
• Mechanics pass rate: increased from an initial 67.0% to 98.2%;
• Visual layout pass rate: improved from an initial 47.8% to 84.7%;
• Level solvability pass rate: followed a non-linear trajectory of 85.5% → 72.9% → 87.9%.

The mid-process dip in solvability illustrates the interconnected nature of interactive components, where isolated fixes can unintentionally disrupt other mechanics. Automated end-to-end verification in real environments filters out numerous hidden defects before human review.

Real-World Outcomes and Limitations: Strong in Physics and Chemistry, Textbook-Like in Biology

To evaluate the pedagogical quality of these interactives, the research team conducted two empirical evaluations involving practicing educators.

The first evaluation engaged 12 practicing US STEM teachers. Each teacher submitted 3 custom topics tailored to their curricular needs, yielding 36 requests. The generated learning goals were overwhelmingly approved as-is or required only minor adjustments. On the backend, the system produced 5 candidates per request, with internal review selecting the highest-quality version for the teacher. Of the 36 requests, 3 below quality thresholds were eliminated internally, leaving 33 presented to teachers.

All participating teachers rated the usability of these simulations at 7 and above, with an average above 8.1 out of 10. (The blog post summarized this as teachers rating "quality" at an average of 8 out of 10, whereas the technical report specifically evaluated usability.) In qualitative feedback, teachers consistently highlighted differentiated instruction as the tool's greatest value. Traditional educational simulations are typically rigid software packages where parameters and pacing cannot be adapted to diverse student needs; in contrast, this system allows customization to class pacing, while embedded scaffolded hints alleviate the challenge of providing one-on-one assistance during class. Teachers also noted shortcomings present at the time: the need for tighter alignment with curriculum standards, and the absence of explanatory feedback on erroneous attempts (which was subsequently addressed).

The second evaluation tested 40 expert-curated STEM topics spanning upper elementary through undergraduate levels. Each interactive passing automated checks was independently reviewed by two UK subject-specialist teachers. Under strict acceptance criteria, the overall acceptance rate reached 86%, with most sub-metrics landing in the "good" or "excellent" bands.

However, performance varied substantially across disciplines:

Physics and chemistry performed best. Whether covering collision dynamics, projectile motion, or the ideal gas law, core concepts rely naturally on precise mathematical formulas and continuous variables. These map directly to interactive mechanisms involving slider adjustments and dynamic plot responses, earning scores closest to "excellent."

Biology performed weakest. Biology interactives scored significantly lower in interaction quality and visual appeal. Topics like the cell cycle or the central dogma in secondary biology focus predominantly on qualitative mechanisms and morphological memorization rather than continuous mathematical equations. When generating these interactives, the model struggled to identify intuitive interactive metaphors, frequently collapsing into step-by-step static displays resembling a digital textbook page-turner and losing the engaging nature of true interactivity.

Beyond disciplinary disparities, the research faces a fundamental limitation: to date, the project lacks empirical data on student learning gains in authentic classrooms. High ratings reflect experienced educators' assessments of usability and pedagogical alignment, but whether these tools measurably improve test scores or deepen conceptual understanding remains to be evaluated in future controlled classroom studies.

What Teachers and Schools Can Access Today

Currently, this experiment includes a public sample library hosted on the Google Research website (requiring a Google account login).

The library contains 36 completed interactives individually verified and marked "Vetted by teacher," covering topics such as Kepler's laws of planetary motion, identifying misleading data charts, and rocket sled kinematics. All content is in English, primarily focused on middle and high school science and mathematics, alongside an elementary school topic and several computer science modules.

For schools seeking custom learning interactives, institutions using Google Workspace for Education can apply for the Google for Education pilot program. Participating teachers can submit customized standards and topics for system generation. However, unverified code is never served directly to students: newly generated interactives must first be tested and approved by the requesting teacher before being published for classroom use.

As the report notes, this research represents an initial step. The critical priority now is evaluating student learning gains with real teachers in authentic classrooms—a goal Google is pursuing through its Google for Education pilot program.