Generated UI is now a product behavior.
OpenAI says GPT-6 in ChatGPT can compose answers from text, visuals, buttons, forms, charts, and interactive tools. A native component library and compiler stream the interface while the model generates it. The model chooses when a comparison, diagram, calculator, or plain answer fits the request.[1]
That is a real change in the answer format. It also moves part of interface design into runtime behavior. The same product can present one request as prose and the next as a working control panel.
Adapt the presentation. Keep the user's bearings fixed.
Fast generation does not settle the design.
Dan Cohen's account of Zotero describes five years of discussion and prototypes before its first public release. The team did not begin with a complete specification. It combined ideas from a local research app, a web scrapbook, browser extensions, metadata services, and the practices of working historians. Cohen's point is direct: code could have arrived faster, but the product idea still needed time and collaboration.[2]
Generated interfaces compress implementation time. They do not remove the work of deciding what must remain stable across users, sessions, and revisions. A form can look different without changing the action it will perform. A chart can move without changing its source. A control can be replaced without hiding whether it already fired.
Motion should carry context, not erase it.
MDN says view transitions can reduce cognitive load and help users stay in context between interface states. The same guide warns that hand-built transitions can cause lost reading position, focus confusion, and strange live-region announcements when old and new content overlap.[3]
Use animation to show where content moved. Do not use it to distract from a changed action. Respect reduced-motion settings. Move focus only when the interaction requires it. Keep the native input as the source of truth.
Keep four facts on one rail.
Every generated control should keep its purpose, action, state, and proof visible. Purpose says what job the control helps with. Action names what will happen before the user commits. State says what is selected, pending, complete, or failed. Proof records the source, input, output, or receipt that supports the result.
The visual arrangement may change. These four facts should not change names or disappear. A calculator can become a chart. A text answer can become a split comparison. The action and its evidence boundary should survive the swap.
Ship the stable contract beside the component.
ADAPTIVE_UI_CARD PURPOSE=[ONE SENTENCE] PRESENTATION_MODE=[TEXT|SPLIT|TOOL] PRIMARY_ACTION=[EXACT EFFECT] ACTION_AUTHORITY=[READ|DRAFT|EXECUTE] CURRENT_STATE=[VISIBLE LABEL] SOURCE_SET=[URLS OR DATASET] INPUT_SNAPSHOT=[ID OR HASH] OUTPUT_RECEIPT=[REQUIRED AFTER ACTION] FOCUS_RETURN=[ELEMENT] REDUCED_MOTION=[TESTED] RESULT=NOT TESTED
This card is a review template. It does not prove the generated interface is clear, accessible, or correct. Fill it with the exact component, test, and result before release.