When AI Moves the Button: Build a Support Loop for Adaptive UIs

A developer detailed a control loop for AI-generated adaptive user interfaces, using React, TypeScript, Zod, and PostgreSQL to treat generated UI as versioned proposals. The approach validates UI manifests against a schema, stores immutable revisions, and enables support to replay exact versions, ensuring operational safety while limiting the model's control over persistence and actions.

An adaptive interface can look impressive right up to the moment a user asks, “Where did the export button go?” That question creates an uncomfortable tension for developers. The model may be capable of producing a plausible layout, but plausibility is not the same as operational safety. Support cannot investigate a screen that no longer exists, and developers cannot improve a system when the only evidence is a screenshot of an ephemeral UI. The answer is not to preserve every pixel or require human approval for every spacing change. It is to treat generated UI as a versioned proposal with three properties: This tutorial builds that control loop with React, TypeScript, Zod, and PostgreSQL. Imagine an AI-generated account screen replaces a prominent Cancel subscription button with an ambiguous Manage plan menu. A production-ready sequence should be: Model proposes manifest ↓ Schema and policy validate it ↓ Server stores immutable revision ↓ Client renders revision ID ui 01J... ↓ User reports “I cannot find cancel” ↓ Report references ui 01J... ↓ Support replays that exact manifest ↓ Human freezes the scope and restores a known-good revision Notice what the model does not control: persistence, action permissions, deployment status, or rollback. That boundary separates the demonstrated capability—generating structured interface proposals—from the hype that a model can safely “own” the interface. The difficult part remains human work: deciding which changes are harmless, which reports indicate real harm, and when novelty is no longer worth the uncertainty. Do not evaluate model-generated JSX, JavaScript, URLs, package names, or import statements. Give the model a small UI language whose actions already exist in your application. js // ui-contract.ts import { z } from "zod"; const actionIds = "open profile", "open billing", "cancel subscription", "contact support", as const; const ActionIdSchema = z.enum actionIds ; export type UINode = | { type: "heading"; text: string; level: 1 | 2 } | { type: "text"; text: string } | { type: "notice"; tone: "info" | "warning"; text: string } | { type: "button"; label: string; actionId: z.infer<typeof ActionIdSchema } | { type: "stack"; gap: "sm" | "md" | "lg"; children: UINode }; const UINodeSchema: z.ZodType<UINode = z.lazy = z.discriminatedUnion "type", z.object { type: z.literal "heading" , text: z.string .min 1 .max 120 , level: z.union z.literal 1 , z.literal 2 , } , z.object { type: z.literal "text" , text: z.string .min 1 .max 500 , } , z.object { type: z.literal "notice" , tone: z.enum "info", "warning" , text: z.string .min 1 .max 500 , } , z.object { type: z.literal "button" , label: z.string .min 1 .max 80 , actionId: ActionIdSchema, } , z.object { type: z.literal "stack" , gap: z.enum "sm", "md", "lg" , children: z.array UINodeSchema .min 1 .max 20 , } , ; export const UIManifestSchema = z.object { contractVersion: z.literal 1 , screen: z.enum "account home", "billing home" , root: UINodeSchema, } ; export type UIManifest = z.infer<typeof UIManifestSchema ; This contract does more than prevent syntax errors. It removes an entire supply-chain failure mode: a generated layout cannot introduce a convincing but nonexistent package because dependencies are not part of the language. Package changes should still go through the normal repository, lockfile, CI, and human review process. A button in the manifest names an application capability; it does not define one. js // actions.ts export const actions = { open profile: = window.location.assign "/account/profile" , open billing: = window.location.assign "/account/billing" , cancel subscription: = window.location.assign "/account/billing/cancel" , contact support: = window.dispatchEvent new Event "open-support" , } satisfies Record<string, = void ; The renderer resolves only these registered actions: python // GeneratedUI.tsx import type { UINode } from "./ui-contract"; import { actions } from "./actions"; export function GeneratedNode { node }: { node: UINode } { switch node.type { case "heading": { const Tag = node.level === 1 ? "h1" : "h2"; return <Tag {node.text}</Tag ; } case "text": return <p {node.text}</p ; case "notice": return <aside data-tone={node.tone} {node.text}</aside ; case "button": return <button type="button" onClick={actions node.actionId } {node.label} </button ; case "stack": return <div className={ stack stack-${node.gap} } {node.children.map child, index = <GeneratedNode key={index} node={child} / } </div ; } } Authorization must still be enforced by the destination API. Hiding an action or omitting it from a manifest is not access control. A generated response should become an immutable revision. Do not overwrite a single current ui JSON column, because that destroys the evidence support needs. CREATE TABLE ui revisions id text PRIMARY KEY, scope text NOT NULL, parent id text REFERENCES ui revisions id , status text NOT NULL CHECK status IN 'proposed', 'active', 'rejected', 'frozen', 'superseded' , manifest jsonb NOT NULL, policy result jsonb NOT NULL, created at timestamptz NOT NULL DEFAULT now ; CREATE TABLE ui scopes scope text PRIMARY KEY, active revision id text NOT NULL REFERENCES ui revisions id , last good revision id text NOT NULL REFERENCES ui revisions id , generation enabled boolean NOT NULL DEFAULT true, updated at timestamptz NOT NULL DEFAULT now ; CREATE TABLE ui feedback id text PRIMARY KEY, revision id text NOT NULL REFERENCES ui revisions id , category text NOT NULL CHECK category IN 'cannot find action', 'misleading copy', 'broken action', 'other' , expected action text, message text NOT NULL, created at timestamptz NOT NULL DEFAULT now ; Parse first, apply policy second, and only then store the proposal: js const parsed = UIManifestSchema.safeParse modelOutput ; if parsed.success { return { accepted: false, reason: "invalid contract" }; } const policy = evaluatePolicy parsed.data ; await db.query INSERT INTO ui revisions id, scope, parent id, status, manifest, policy result VALUES $1, $2, $3, $4, $5, $6 , revisionId, scope, currentRevisionId, policy.autoActivate ? "active" : "proposed", parsed.data, policy, ; Keep the raw prompt out of this table unless you have a defined privacy and retention reason to store it. Support usually needs the resulting manifest and policy decision, not an indefinite archive of user context. A route such as /account is insufficient when two visitors may receive different layouts. Put the revision ID on the rendered screen: export function AdaptiveScreen { revisionId, root, }: { revisionId: string; root: UINode; } { return <main data-ui-revision={revisionId} <GeneratedNode node={root} / <FeedbackForm revisionId={revisionId} / </main ; } Use categories that help triage rather than asking only, “How was this experience?” function FeedbackForm { revisionId }: { revisionId: string } { async function submit formData: FormData { await fetch "/api/ui-feedback", { method: "POST", headers: { "content-type": "application/json" }, body: JSON.stringify { revisionId, category: formData.get "category" , expectedAction: formData.get "expectedAction" || null, message: formData.get "message" , } , } ; } return <form action={submit} <label What went wrong? <select name="category" required <option value="cannot find action" I cannot find an action</option <option value="misleading copy" The wording is misleading</option <option value="broken action" An action does not work</option <option value="other" Something else</option </select </label <label What were you trying to do? <input name="expectedAction" maxLength={120} / </label <label Details <textarea name="message" required maxLength={2000} / </label <button type="submit" Send feedback</button </form ; } Validate the same fields on the server. Also verify that revisionId exists; never trust a client-provided manifest. Not every complaint deserves a global rollback. A small decision table keeps the response proportionate: | Signal | Immediate action | Follow-up | |---|---|---| | One subjective copy complaint | Keep revision active | Review during normal triage | | Repeated “cannot find action” reports on one revision | Freeze that revision | Compare against its parent | | Registered action throws or reaches the wrong destination | Restore last-good revision | Open an application bug | | Billing, deletion, consent, or security action becomes ambiguous | Disable generation for that scope | Require human review before reactivation | | Invalid manifest reaches a client | Fall back immediately | Treat as a contract enforcement defect | The important distinction is scope . A broken billing layout should not necessarily disable experimentation on a low-risk dashboard, but it should stop further billing mutations. A rollback should be one database transaction, not another model request: BEGIN; UPDATE ui revisions SET status = 'frozen' WHERE id = $1 AND status = 'active'; UPDATE ui scopes SET active revision id = last good revision id, generation enabled = false, updated at = now WHERE scope = $2 AND active revision id = $1; COMMIT; If the second update affects zero rows, another revision may already be active. Return that conflict to the operator instead of silently claiming rollback succeeded. Create an internal route such as: /support/ui-revisions/:revisionId It should show: The replay view must remain read-only by default. Rendering a historical manifest should not trigger analytics, navigation, billing operations, or other real actions. Replace action handlers with labels such as Would invoke: cancel subscription . This is also useful engineering practice for less-experienced developers. Instead of asking them to trust or reject “the AI,” they can inspect a concrete artifact, identify the violated invariant, and make a bounded decision. Judgment grows from examining failures, not from pretending automation removed the need to understand them. Once reports are linked to immutable revisions, AI can assist with tasks whose output remains advisory: It should not: The model can reduce reading and drafting work. The human still decides what the interface is allowed to mean. A structured form is useful for aggregation, but some users need a conversation. You can add a hosted chat widget while keeping revision storage and rollback inside your application. For example, Knocket https://knocket.trtc.io/ provides an embeddable live-chat widget installed with a script tag and does not require a custom chat backend. Visitors do not need an account to begin chatting. Keep the revision reference visible and easy to copy rather than depending on undocumented widget metadata: <p Diagnostic code: <code id="ui-diagnostic" ui revision=ui 01JABC123</code </p <button type="button" id="copy-ui-diagnostic" Copy diagnostic code</button <script document .getElementById "copy-ui-diagnostic" .addEventListener "click", async = { const value = document.getElementById "ui-diagnostic" .textContent; await navigator.clipboard.writeText value ; } ; </script < -- Paste the Knocket script tag generated by its setup flow here. -- Messages can be handled in its unified inbox or routed to Telegram, where a quoted reply can be delivered back to the website visitor. The durable technical record should still be the revision and structured report in your own system; chat is the conversational return path, not the rollback mechanism. Expected result: schema validation rejects the complete proposal. Do not silently drop the button and render an incomplete screen. Schema validity does not prove product correctness. Add scope-specific policy rules, such as requiring cancel subscription somewhere in the billing cancellation journey. The report must continue pointing to its original immutable revision. The replay page should clearly state that the revision is no longer active. Keep the diagnostic code visible so the user can include it in another support channel. Do not claim the report was received until the server acknowledges it. Install an error boundary outside the generated subtree. It should replace the subtree with a static known-good navigation surface and expose the revision ID. Treat this as a release blocker. Replay mode must inject inert handlers rather than import the production action registry. Ignore the suggestion at runtime. If the capability is genuinely needed, evaluate the package through registry verification, ownership review, lockfile changes, CI, and the same code-review process as any other dependency. Before enabling adaptive UI for a scope, verify that: Adaptive interfaces do not remove frontend or support work. They move the work from manually arranging every screen toward defining contracts, recognizing unsafe semantics, and responding well when a proposal fails. That is not a loss of developer value. It is a clearer description of where developer judgment is required. Disclosure: I work on Knocket, so treat it as one implementation example rather than a neutral recommendation.