After GPT-6 Ignites Generative UI, the Next Gap Is Generative Workflow

After GPT-6's Generative UI, the real challenge is building a matching Generative Workflow execution layer.
GPT-6's Intelligent UI marks a shift from AI generating answers to generating interfaces — a trend called Generative UI. But the author argues a deeper layer is being overlooked: the execution system beneath the interface (data retrieval, state management, tool calls, step orchestration) resembles a workflow compiler/runtime more than a UI system. The article distinguishes Generative UI (presentation) from Generative Workflow (execution), proposes they be generated together in a feedback loop from intent to execution, and introduces the open-source project FlowX as an early proof-of-concept. The central conclusion: the real moat lies in the workflow engine beneath the interface.
From Generating Answers to Generating Interfaces
The Intelligent UI feature introduced with GPT-6 marks a pivotal shift in human-computer interaction. For a long time, AI primarily generated text, code, or answers. Now it has started generating interfaces for tasks themselves — charts, forms, buttons, interactive components, and ad-hoc tools dynamically assembled around the user's goal.
The community has coined this shift "Generative UI." It means software is no longer a fixed form designed in advance, but something assembled on the fly based on what the user is trying to do right now. A discussion on Reddit captured the significance of this trend precisely: AI is no longer just answering questions — it's creating the right control panel for the question.
But at exactly this inflection point, a deeper question surfaces: what's actually happening beneath the interface?

Interfaces Are Easy to Generate. Systems Are Not.
Generating an interface is relatively easy to describe, but generating a system that actually gets work done is another matter entirely. Consider a classic example:
"Analyze this company's financial data, identify anomalous changes, compare with last quarter, and produce an executive summary."
Generative UI can present the results as charts, tables, controls, and interactive explanations. But underneath the interface, the system still has to do serious heavy lifting:
- Retrieve the right data
- Transform and validate that data
- Execute multiple analysis steps
- Maintain state between steps
- Call external tools or APIs
- Produce intermediate results
- Allow the user to modify a specific step
- Re-execute the modified flow
This no longer resembles a traditional UI system — it's closer to a workflow compiler/runtime. In other words, the interface is just the tip of the iceberg. The underlying execution logic is what actually determines the ceiling on capability.
The concept of a workflow compiler/runtime sits at the intersection of compiler theory and process engine design. Traditional workflow engines (such as Apache Airflow and Temporal) schedule pre-defined directed acyclic graphs (DAGs), managing step dependencies, retries, and state persistence. The "compiler" metaphor emphasizes that requirements described in natural language or high-level intent must be "compiled" into a sequence of low-level operations that can be executed mechanically. Combining the two means the system must not only execute workflows but also dynamically generate the workflow structure itself from intent. The key difference from traditional RPA (Robotic Process Automation) is that RPA flows are manually recorded or written in advance, whereas in generative workflows, the execution graph is inferred in real time by AI. This dual capability — generate and execute — is precisely the missing link in most current AI assistants: they can describe how to do something, but there's no execution artifact that can be inspected, modified, and re-run.
Two Layers That Must Be Distinguished
A valuable conceptual distinction emerges here — one that may become a critical dividing line in next-generation agentic systems:
Generative UI
Addresses how users interact with generated applications. It focuses on the presentation layer: how to display results and action entry points in the most appropriate form.
Generative Workflow
Addresses how generated applications actually complete tasks. It focuses on the execution layer: how data flows, how steps are orchestrated, how state is maintained, how tools are invoked.
Distinguishing these two layers matters because they solve fundamentally different problems. The UI layer is the visible interaction contract; the workflow layer is the invisible execution engine. Optimizing only the former leaves AI agents permanently stuck in the awkward position of "impressive demos, hollow deployments."
It's worth noting that "Generative UI" already has concrete technical implementations in the industry. Vercel's AI SDK streamUI primitive, Vercel v0, and Anthropic's Artifacts feature are all early forms of Generative UI — they enable LLMs to output renderable React components or interactive interfaces directly, rather than plain text. These implementations validated the hypothesis that "interfaces can be generated in real time," but they also exposed the problem raised in this article: these tools still optimize for the presentation layer. The interfaces they generate are typically one-shot, stateless code fragments with no corresponding execution-layer abstraction. The current boom in Generative UI, therefore, serves as a perfect foil for the absence of Generative Workflow.
From prompt→answer to intent→execution
What's truly exciting is that these two layers could ultimately be generated together. The interaction paradigm would evolve from the simple:
prompt → answer
Into a feedback loop:
intent → UI + workflow → execution → feedback → workflow update → better execution
The significance of this loop is that execution is no longer a black box. After a user expresses intent, the system simultaneously generates both an interface and the underlying workflow. After execution, user feedback can flow directly back into the workflow itself, driving updates and producing better results.
This also changes how we understand "agent skills." A skill no longer has to be a static prompt or instruction set — it can become a living, executable workflow that can be inspected, modified, replayed, and continuously evolved based on user feedback. This is a genuinely imaginative perspective: skills upgrade from "text templates" to "runnable, evolvable program assets."
Agent skills currently exist in mainstream frameworks primarily as "tool calling" or "function calling" — essentially a statically registered function signature with a description string, which the LLM selects at decision time. The function calling mechanisms from OpenAI, Anthropic, and other major platforms all fall into this category. The article's proposal to upgrade skills into "runnable, evolvable program assets" means a skill is no longer a one-shot function call, but a stateful program unit with internal state, support for partial modification, and replay capability. This aligns with the direction frameworks like LangGraph and AutoGen are pursuing with "stateful agent graphs," but goes further by requiring that skills be directly inspectable and modifiable by users — rather than remaining a black box. This is a critical step in the evolution from "AI doing it for you" to "human-AI collaborative programming."
FlowX: An Early Open-Source Exploration
The author's team has translated this idea into an open-source project called FlowX (GitHub: AIpRoBuilder/FlowX). The project currently focuses on two things:
- Converting natural language requirements into executable workflows;
- Allowing individual workflow nodes to be updated and re-run through conversation.
The second point is especially aligned with the feedback loop described above — users don't need to start over from scratch. Instead, they can precisely modify a single node in the flow and re-run just that part. This "node-level editability" design is the embodiment of treating workflows as first-class citizens rather than one-shot artifacts.
It's worth noting that FlowX is still in early experimental stages — more of a testbed for validating whether "generative workflow" is a sound abstraction than a mature product.
An Open Question
The question the author ultimately poses is larger than any specific implementation:
If Generative UI is the new interaction layer for AI software, what should the execution layer look like? Is "Generative Workflow" the right abstraction — or will agentic systems ultimately converge on some other form?
There's no standard answer yet. What is certain is that once interfaces can be dynamically generated, the community's attention will inevitably shift from "what did the AI say" to "what did the AI do, how did it do it, and can it be corrected." Whoever gets the execution-layer abstraction right may well define the foundation of the next generation of AI agents.
For developers focused on AI application architecture, this is a direction worth thinking about early: don't fixate only on the beautiful generated interface. The real moat is usually hidden in the workflow engine beneath it.
Related articles

SwiftUI Agent Skill: Teaching AI Coding Tools to Write Idiomatic SwiftUI Code
SwiftUI-Agent-Skill by Paul Hudson gives Claude Code, Codex & other AI tools a dedicated SwiftUI knowledge pack. 5,200+ Stars. Learn what Agent Skills are and why they matter.

40 Years of Backpropagation: Remembering the Forgotten David Rumelhart
On the 40th anniversary of the backpropagation paper, we revisit deep learning pioneer David Rumelhart — his contributions to neural networks, PDP theory, and cognitive science.

Building a Text-to-Image Model from Scratch: One Young Developer's Data Challenge
A young developer shares their PyTorch text-to-image project on Reddit, facing a critical data shortage. This article covers data bottlenecks and practical tips including open datasets, auto-captioning, and LoRA fine-tuning.