A few weeks ago I closed The Visible Layer with a claim. The claim: the surface layer of design (UI) has been commodified, but the work that actually decides whether a final design is any good (problem definition, framing, flow, exploration) sits upstream of where the current tools operate, and almost nobody is building there.

This is an upstream experiment, a tool called Designer. And this is part one: what it is and how it works. Part two will be my analysis of what worked, what didn’t, and what I’d do differently.

Good design comes from a good design process

Quick recap. Lovable, v0, Stitch, and Claude Design focus on UI. Prompt in a sentence: get a plausible interface out. Remarkable, and also narrower than it looks. They all work downstream of the real work. They accept whatever framing arrived in the prompt. The object model is implicit and undocumented. The flows are inferred from what the category usually looks like, not from what this user’s task actually is.

Ask for “a notes app” and you get the average. Apple-Notes-shaped: clean, capable, theory-free. The chrome is right. The point of view is missing because nobody took one.

Karri Saarinen said it cleanly: output isn’t design. The form is the easy part now. What’s left is deciding what should exist at all, and that’s still mostly manual, mostly senior, and mostly untouched by the tools.

So here’s the question I wanted to explore. What would a tool look like if it modeled the UX process? Not “make me a screen,” but “given this problem and this user, what are the genuinely different bets worth making, and which one actually holds up?”

What Designer is

Designer is a canvas. Not a chat box with a preview pane, but a left-to-right workspace where each node represents a part of the design process.

On the left, the inputs - problem, research, etc. In the middle, the design hypothesis incubator / idea generator. On the right, the design hypotheses, and then the designs themselves. Left to right, the canvas is the design process.

We’ll start on the left, with the framing, because that’s where Designer starts, and it’s the part the other tools skip.

The shape of the canvas is the argument. A design is not a screen you generate. It’s a system you reason about (inputs, positions, artifacts, judgment), and the tool should make that whole chain visible. Eliel Saarinen again: always design a thing by considering it in its next larger context. The canvas is that instinct turned into software.

Framing the Design Problem

Five inputs feed the canvas, but only the design brief is actually required.

Design Brief. The directive: the challenge, the problem, or the opportunity. It’s the one input every tool already takes, just a sentence in a box. The difference is what happens next. Here the brief is a seed for the rest of the framing, not the whole of it.

Research & Context. Who the audience actually is, what they use today and how it fails them, where the real opportunity sits. Strategic grounding. The kind that decides which directions are even worth pursuing. Designer can draft a first pass from the brief, but it’s deliberately disciplined: no invented studies, no fake statistics, no drifting.

Objectives & Metrics. Not business metrics like KPIs, e.g., conversion and retention. Those live downstream of a shipped product, and nothing has shipped yet. These are design properties a reviewer (or another AI) can judge from the artifact itself, each paired with how it fails when overdone. You’re defining what good looks like, in design terms, before a design exists.

Design Constraints. Not the execution rules the name might suggest, the contrast ratios, type scales, and touch-target sizes. Designer treats those as build-time craft, handled later. Constraints here are strategic: what decides which directions are even viable. The section opens by declaring the surface (a phone, a desktop tool, a kiosk, a voice flow), naming the real deal-breakers (the regulation that applies, the audience composition you have to reach), and separating the hard non-negotiables from the space that’s open to explore. Less a fence around the pixels than a filter on which bets are worth making at all.

Design System. Optional, and pointedly downstream. If you have a visual identity (tokens, type, components), Designer normalizes it into a portable spec and hands it to the designs, not the strategy. The surface layer (the commodified part) is treated as exactly that: an input you plug in, not the work. The hypothesis takes its position first. The system just dresses it.

Three of these (research, objectives, constraints) Designer allows the user to generate draft versions from the brief if you let it, so a thin start doesn’t stay thin. But this relies on what the large language model knows about the domain, and it’s going to be subject to the same kinds of hallucinations we’re already familiar with. Use with caution. These are better completed with real, hard-earned domain knowledge and verifiable facts.

Hypotheses, not variations

This is the heart of Designer. Can it generate plausible, viable, valuable design hypotheses?

Feed the Incubator your brief and it doesn’t return five versions of the same page. It returns hypotheses: genuinely different bets about what will work for this user and this problem.

Take the notes app. Instead of one generic answer, you’d get distinct positions: a block-composition bet where the unit is a block and pages become databases (Notion’s theory of thinking); a plain-text-you-own bet where files live in a vault forever (Obsidian’s); a deliberate zero-structure capture bet, fast and frictionless, chosen on purpose rather than by default. Three different products, each taking a position on what notes are for. Designer surfaces those positions instead of quietly collapsing into one.

And they’re spread on purpose. Each hypothesis sits at a distinct point along exploration axes, the dimensions along which the solutions could meaningfully differ. The Incubator maps that space first, then places bets across it, so you get spread, not noise. Ask for more and it excludes the ones you already have, pushing into new territory instead of circling the average.

There’s an optional first move here too, a checkbox called Brainstorm directions first, off by default. Turn it on and Designer runs a divergent pass before the incubator even starts: brainstorm 10 to 15 deliberately obtuse product directions, no filtering for plausibility, the stranger the better. Then a curation pass converges, keeping the five with the widest spread and reshaping or dropping anything that isn’t genuinely a software product. Those five seed the hypotheses. It’s an extra step, off by default, there for when you want to cast a wider net before the incubator commits.

This is the take a position problem from The Visible Layer, turned into a mechanism. And it’s the bounding box from [New Rules]: before you build anything, you define the space you’re going to explore. You’re not designing a screen. You’re designing the boundaries of which screens could exist.

Exploring the solution space

Pick a hypothesis, hit Design, and Designer builds it. A working static prototype. HTML, CSS, and JavaScript. Clickable, navigable, the interactions run.

Because the marginal cost of a build is low, you don’t have to commit. Run several hypotheses in parallel. Build the same one twice and compare. Results stack as versions (v1, v2), so exploration accumulates instead of overwriting itself.

This is the move I argued for in New Rules: when generation is cheap, you explore the solution space directly rather than through proxies. Three approaches instead of one. The cost of being wrong early drops to near nothing.

But a build isn’t one shot, and that’s what separates it from a prompt-to-page toy. It’s an agent. It plans, writes files, checks its own work, and fixes what it broke. Before it writes a line of code, the agent commits to a plan: which features are needed to verify the hypothesis and which are scaffolds, visibly present but openly inert. What you get is a prototype where the parts that claim to work, work. The trick is building enough of a prototype to be able to prove out the hypothesis, or not.

Which brings me to design iterations and self-improvement.

Evaluation is the bounding box

A polished page no longer proves anything. The screen looks the same whether someone spent three weeks understanding the user or three minutes describing one to a model. So Designer doesn’t trust the surface. It evaluates.

Turn on Auto-improve, and every build gets scored. Against rubrics, not vibes. Design quality. Fidelity to the hypothesis: did the artifact actually express the position it was supposed to take? Implementation quality. A headless browser even renders the thing and checks that it works: console errors, broken images, layout.

Then it revises. The evaluation produces a fix list, the agent applies it, and the loop runs again. It’s bounded. It stops when the design clears the bar you set, or when it hits a ceiling. You define good before the variant exists, and the system converges toward it. A small, designer-controlled version of the Darwinian loop - hypothesize, build, judge, keep the best.

A note on what Designer is not

Designer is a pair designer. Not a replacement, and not a researcher. It does not talk to your users. It will happily generate a beautiful, confident answer to the wrong question. The framing is only ever as good as what you bring to it. The average is a gravity well, too. Left loose, even a hypothesis engine drifts toward the category default, and a lot of the work has gone into pulling against that. And a working prototype is still a prototype. It’s an argument you can click, not a shipped product.

Which is exactly the right place for it to sit. The scarce skills (the ones that stay scarce when generation is cheap) are the ones I keep landing on: understanding what users actually need, articulating it precisely, and the judgment to know when the numbers, or the pretty screen, are lying.

How it’s put together (for the technically curious)

Skip this if you don’t care how the sausage is made.

The build agent runs on an agentic coding harness (Pi) inside an isolated, in-memory sandbox. The agent gets file tools and a shell, like a developer in a tiny disposable VM, but with no network and no package installs. Just the craft of assembling the artifact, then validating its own HTML and JavaScript before it calls the work done.

The design judgment isn’t hard-coded. It lives in a library of prompts and skills (skill.md) the agent loads as it works: design quality, accessibility, and the discipline of using patterns rather than reinventing them. This is the rules of use point from The Visible Layer: a component library is inventory; the value is the governing logic. I tried to write that logic down and experimented with the various prompts.

Around it sits a server that orchestrates each run, streams progress to the canvas live, and runs evaluation as independent rubric workers plus that headless browser. Everything the agent produces is a real file tree you can preview, inspect, and download. That said, there is no follow-up, there is no re-prompt, and that’s a real limitation, and something I’ll return to in part two of this where I get to what worked and what did not.

That’s the architecture in a paragraph. The interesting engineering is in the details: the sandbox boundary, how positions are kept genuinely distinct, and how evaluation feeds revision. That’s a post of its own.

What’s next

This was part one: what Designer is. Part two is the part I’m most interested in writing: what I learned from building and using it. More soon.

So AI has commodified the UI. What now?

Let’s be honest, the visible layer of digital design has been largely commodified. Google Stitch, Claude Design, v0, Lovable can all generate a plausible interface from a sentence. That’s the conversation everyone is having (ad nauseam).

But Karri Saarinen made the deeper point recently in Output Isn’t Design: “the hard part of design is rarely generating the form.” The rest of design is figuring out what should exist at all. This essay sits in that lineage. The argument I want to add is more specific: the surface layer of design was already mostly pattern selection and design systems, and the rest of the UX process, the part that decides whether a product is actually any good, is still mostly untouched (for now).

The surface converged. That’s why generation works.

Most modern interfaces do not constitute invention. Login, onboarding, dashboards, checkout, settings, search, filters, tables, navigation, modals, alerts, empty states. These are solved problems, partly because users move between products and learn the patterns once. Modal behavior, table affordances, button placement, the way a filter chip works. Cross-product literacy. The patterns are universal by design.

Design systems made that convergence official a decade ago: stop reinventing the dropdown. They formalized the patterns into reusable components, documented the props and states, and made the inventory portable. Once that work was done, machine assembly was the obvious next step. AI generation didn’t invent the convergence. It inherited it from design systems and industrialized it.

On the brand and UI side, you can watch the cycle complete in real time. Last week Google open-sourced DESIGN.md, a portable markdown spec that hands AI design and coding agents like Stitch, Claude Design, and Cursor a project’s design tokens and component rules in a single file. The spec covers colors, typography, spacing, border-radius, component variants, contrast rules. Visual identity, made portable to any agent. But there’s no field for the user’s mental model. No field for the task flow. No field for what the product is for or who it’s for. The investment is going where the patterns already converged.

When a model generates a competent page design now, it isn’t doing magic. It’s drawing from a world where most surface problems already have conventional answers and where the answers are increasingly written down. The convergence is real. But it’s also a much narrower achievement than the demos make it look.

A polished looking page no longer proves anything

Visual polish, layout skill, UI fluency, and the visible craft of design used to be a moat. But now a non-designer can prompt their way to something that looks competent. The visible layer has been cheapened. I’m not saying here that UI is dead; in fact, I believe the opposite to be true. Originality is now more important than ever. It will stand out against the grey of agentic creation.

That matters because product design has historically been judged on what it looks like. A polished screen was circumstantial evidence of careful thinking underneath. Not anymore. The screen looks the same whether someone spent three weeks understanding the user or three minutes describing one to a model. Saarinen makes the same observation from the other direction: products that look ambitious and impressive at first glance often start to come apart the moment you actually use them. The form is there. The fit is not.

Surface patterns converge across products. Mental models don’t.

The natural follow-on is: if surface patterns converged, why haven’t deeper layers converged too?

Surface patterns converged because users learned them across products. Mental models don’t work that way. A mental model is a position on what the product is for, what the user is doing, and how the underlying world is shaped. Two products can share a button pattern and hold completely different positions on what they exist to do.

Notes apps are maybe the cleanest example. Apple Notes is what you get when no position is taken: a plain text editor with folders, search, and a few formatting controls. Competent, generic, theory-free. Notion and Obsidian each take a position, and the position shows up in the underlying object model.

Notion’s primary unit is the block. Blocks compose into pages, and pages can become databases. It’s a structured-composition theory of thinking, built for someone managing wikis, project trackers, team knowledge bases. Obsidian’s primary unit is the markdown file. Files live in a vault you own and link to each other through links. It’s a knowledge-belongs-to-the-user theory, built for someone who wants their notes in plain text, on their own machine, forever.

These object models aren’t arbitrary technical choices. They exist because each product is solving a specific problem for a specific kind of user. The user and the problem come first. The mental model is the position the product takes on them. The object model is what that position looks like written down.

Ask a model to generate “a notes app” and you get the average. Something Apple-Notes-shaped: clean, generic, capable, theory-free. The chrome looks right. The point of view is missing because no one took one. No specific user, no specific problem.

This is the gap the surface convergence hides. AI assembly is good at producing the average of a category. It is not good at producing a product that takes a position.

The work the current tools aren’t doing

Set research aside (that is a huge topic in its own right that I’ll come back to another day). Even with the research done, there’s a body of work that has to happen before anything appears on a screen.

Framing: what is the product for, and what is it not for? Which user does it serve, which does it ignore? What does success mean? The current tools don’t frame. They accept whatever framing arrived in the prompt (its all implicit).

Mental model and information architecture: what nouns live in the user’s world, how do they relate, what’s the taxonomy? Sophia V Prater ‘s OOUX methodology is the rigorous version of this work. The approach models objects and the relationships between them before any screens exist.

Interaction and behavioral design: flows, state machines, what the system decides versus what it asks, permissions, multi-user behavior, edge cases, time-on-task priorities. A pro tool optimizes for keystroke economy and reversibility on the fiftieth use. A consumer tool optimizes for legibility on the first. These are different products built on different assumptions about who is using them and how often.

Current tools work almost entirely downstream of all that. They take a sentence and produce an artifact. The framing is whatever was in the sentence. The object model is implicit, undocumented, and unstable across sessions. The flows are inferred from what the use case usually looks like, not from what this particular user’s task actually is.

The output looks like design. But most of the work that makes design good hasn’t happened.

Pattern libraries are not systems

A design system gives you the parts. It doesn’t automatically give you the rules for using them. Without that layer, even a good system can be reduced to a warehouse of components: buttons, cards, tabs, menus, charts, forms. Inventory without governing logic.

The value of a system was never the inventory. It’s the rules of use. When does this pattern appear? What is it allowed to do? Which product principle does it express? What expectation does it set in the user? How does it scale across teams and edge cases?

Christine Vallaure de la Paz made a related point in a recent piece on agentic design systems: “good building blocks do not come from a component library maintained in isolation.” They come from someone who modeled the whole product first. The agentic setup pulls toward efficiency, toward the inventory of things to colour in quickly. Whether anything in the inventory is worth assembling is a separate question, and it’s the one that doesn’t get asked enough.

A model can remix the inventory without understanding the rules. That’s local optimization at scale. Each generated screen makes sense on its own; the product as a whole feels incoherent because nobody, human or model, was working on the system. Only on its parts.

Pages aren’t designed in isolation

A feature is never just a feature. The moment it enters a product, it becomes a relationship to everything it touches. Does it fit an existing pattern or do you need a new one? Where does it sit in the user’s flow? Does its placement here change what the user expects over there? Pattern reuse isn’t aesthetic preference. It’s the difference between a product that scales and a maintenance burden every team and user pays.

I wrote about this previously: every feature you add reshapes the product around it. The architect Eliel Saarinen put the same discipline in spatial terms: always design a thing by considering it in its next larger context. A chair in a room. A room in a house. A house in a city plan.

And this is exactly what today’s design generation tools don’t do. When you prompt v0, Google Stitch, Claude Design, or Figma Make for a component or a screen, it has no relationship to the whole. It doesn’t know your patterns, your users’ learned behaviors, the top tasks the application has to support, or where this thing sits in a journey. It produces parts that look good in isolation and quietly accumulate the cost of reconciling them, for designers, for engineers, for users who have to learn five variations of the same control.

The unfinished part of the stack

Familiar patterns aren’t the problem. Good design uses them all the time. The problem is assembly without a model: of the product, of the user, of the system those patterns belong to. The visible competence of the output convinces people the work is done. In a word you might just say the UX. Right now AI assembly skips it.

Much of what passed for product design was already pattern selection. The value was never the production of screens. It was the authorship of the system underneath: deciding which patterns exist, when they apply, where consistency matters and where it has to give.

For these tools to get better they need to move upstream. Into framing, mental models, object design, flows. Into the work that actually decides whether the product is any good. Not many people are building there yet. But watch this space... more on this soon.

(Originally published on LinkedIn: April 28, 2026).

Originally published on LinkedIn - January 31, 2026

The Economic Shift in Code

The fundamental economics of software production are being restructured around a simple principle: the marginal cost of producing working code is collapsing toward zero.

Historically, software was constrained by human cognitive bandwidth. There’s a limit to how much a developer can write, debug, and maintain in a day. Or a sprint. Or a program increment. This constraint is being removed in layers.

Three Layers of Change

Large language models made code generation nearly instantaneous. A developer describes what they want; the model produces it. This alone changed everything but had limits: the human still orchestrates, reviews, and integrates.

Agentic scaffolding added autonomy. Tools like Claude Code, Cursor, and similar CLIs wrap models in loops that can execute code, observe results, and iterate. The human sets a goal; the agent works toward it, handling intermediate steps autonomously. This is where most production use sits today.

Agent swarms take it further. Multiple AI agents work in coordination: specialized agents handle distinct tasks (planning, coding, testing, code review, documentation), orchestration layers break problems into subtasks and route them appropriately, and feedback loops allow agents to critique and iterate on each other’s outputs. This mirrors how human engineering teams operate, but at machine speed and cost. Tools like Conductor let developers run multiple Claude Code agents in parallel, each in an isolated git worktree, with a dashboard showing what each agent is working on. And swarm coordination is now being built into the models themselves: Kimi K2.5, released this week, can self-direct up to 100 sub-agents executing 1,500 tool calls in parallel, with the orchestration learned through reinforcement learning rather than hand-coded.

Three layers

The Evidence

This isn’t speculative.

When SWE-bench launched in October 2023, the best AI systems solved under 2% of real-world GitHub issues autonomously. By March 2024, Devin reached 13.86%. It was the first agentic system to show real traction. Today, top systems exceed 75% on SWE-bench Verified.

The improvement came from better models, better tooling, and most importantly, agentic scaffolding that lets AI systems iterate on their own code until tests pass.

AI tools are now building AI tools. Anthropic built Cowork, a general-purpose desktop agent, in approximately ten days, with the code written primarily by Claude Code itself.

Cursor recently demonstrated what sustained autonomous development looks like: hundreds of AI agents running for a week straight, generating three million lines of Rust code for a browser built from scratch. The browser “kind of works.” But the lesson is clear: coordinated, autonomous software development at scale is no longer theoretical.

What Near-Zero Marginal Cost Means

Exploring alternatives becomes cheaper

Exploring alternatives becomes cheaper. You can try three approaches instead of committing to one upfront. Build the feature two different ways and see which performs better. The cost of being wrong early drops dramatically.

First versions come faster. Getting to something testable takes less time. The gap between “idea” and “working prototype” compresses.

The bottleneck shifts from production to specification. When producing code is cheap, the constraint moves to knowing what code to produce. Defining the problem well, specifying the requirements precisely, and understanding what users actually need. Design lives here.

Why This Changes Design

When the cost of a downstream activity collapses, it restructures the purpose and methods of everything upstream.

Design exists upstream of software development. It feeds into it. Traditionally, design served a specific economic function: risk mitigation for expensive downstream work.

The Traditional Logic

The reasoning was straightforward:

• Software is expensive to build

• Building the wrong thing wastes that investment

• Therefore, explore and validate before committing to code

This created an entire methodology: wireframes, prototypes, usability testing, and concept validation. All proxies for the real thing, because the real thing costs too much to build speculatively.

The Inversion

If agent swarms collapse the marginal cost of working software to near-zero, this logic inverts.

Why prototype when you can ship?

Instead of testing a prototype with 8 users, you could deploy actual variants to real users in production. Instead of debating whether users will understand a flow, you could build the candidate flows and measure. Multivariate testing platforms already generate and test hundreds of combinations simultaneously, varying headlines, layouts, CTAs, and imagery across pages. This isn’t A/B testing as we know it. It’s parallel exploration of the solution space.

Stitch Fix offers a glimpse of what this looks like for product generation. Their Outfit Creation Model generates 13 million new outfit combinations every day, trained on millions of stylist-created outfits, considering real-time inventory and client preferences. They’re not prototyping outfit ideas. They’re generating and testing them at a scale no human team could match. This is AI-native product generation, not UI design. But it demonstrates the principle: when generation is cheap, you explore the solution space directly rather than through proxies.

This doesn’t mean prototyping vanishes. Prototypes still have value for rapid conceptual exploration, stakeholder alignment, and situations where production deployment infrastructure is the bottleneck. But the economic logic points toward a shift: the burden of proof moves from “why build this?” to “why not just ship it and learn?”

The New Workflow

This is the direction the economics point toward

Traditional Design & Build vs New

Traditional

• Research → Design → Build → Test

• 3 concepts tested as prototypes

• 8-12 research participants

• Months of iteration

Zero-Marginal-Cost Model

• Define needs → Specify parameters → Generate variants → Deploy → Measure → Converge

• Hundreds of combinations tested in production (via multivariate testing)

• Real user behavior at scale

• Days or weeks

What Design Becomes

As the integration between AI generation and experimentation infrastructure matures, the designer’s role shifts. How quickly this happens depends on how fast the emerging tools become reliable and widespread. But the direction is clear enough to act on now.

For Designers: From Artifacts to Specifications

The designer’s core competency is integration: taking inputs from research, business, and technical constraints and synthesizing them into solutions that satisfy all three. That doesn’t change. But when generation becomes cheap, this skill expresses itself differently.

You’re not designing a screen. You’re designing the boundaries of what screens could exist. The output shifts from wireframes and prototypes to specifications that define what a solution must do, what it must never do, and how you’ll know if it worked.

Stop: Spending time on pixel-level execution that can be generated. Treating prototypes as the primary learning vehicle when variants could ship.

Start: Translating research insights and business requirements into specifications precise enough to guide generation. Defining evaluation criteria before variants exist - hat’s the bounding box? Designing experiments, not screens. Define the scope scope of the solution space. The where to explore - the constraints.

Maybe Jensen Huang CEO of NVIDIA said it best.

Captions are auto generated

Play

Smart is someone technically astute but with empathy

“The traditional definition of smart — solving technical problems — is a commodity. That’s the first thing AI solved. The real definition of smart is someone at the intersection of technical ability and human empathy, who can see around corners and preempt problems before they show up — through a combination of data analysis, life experience, wisdom, and sensing other people. That person might score horribly on the SAT.”

Think about it.

For Researchers: The Interpretive Layer

When you can generate anything, knowing what to generate matters more. Researchers own this.

Generative research surfaces human needs and identifies which directions are worth exploring. Before anyone can specify a solution, someone has to understand what users actually need. This doesn’t come from behavioral data. It comes from qualitative work that reveals needs users can’t articulate and opportunities metrics can’t capture.

Interpretive research explains what behavioral data means. When you can deploy hundreds of variants, you get abundant data on what users do. The scarce resource becomes understanding why.

The Booking.com WiFi example illustrates this. It comes from traditional A/B testing, not AI-generated variants, but the lesson applies even more as variant generation scales: quantitative testing of “WiFi Strength - Strong” labels showed no conversion lift. Only through user interviews did researchers discover guests cared about what WiFi enabled (Netflix streaming, email), not signal strength itself. The winning variant was “Fast Netflix Streaming.” Behavioral data alone would have missed this.

Qualitative insights remain a huge differentiator

Stop treating qualitative and quantitative as sequential phases. Running studies in isolation from live experimentation.

Start: Integrating into the experimentation loop. Identifying which directions are worth exploring before experiments begin. Interpreting what the numbers can’t explain. Being the person who asks, “What’s the WiFi really about?”

The Evidence

Three things need to be true for the thesis of this essay to hold: experimentation at scale must be valuable, AI must be able to generate variants cheaply, and the two must integrate. The first is proven. The second is proven. The third is emerging.

Experimentation at Scale Works

The largest digital companies have already demonstrated that continuous experimentation drives results.

Spotify ($17B) says there is no single Spotify. There’s a version for every user. Their homepage uses multi-armed bandits to balance exploration and exploitation in real-time, continuously testing which content surfaces best for each listener. Their experimentation platform, Confidence, has scaled to over 300 teams running experiments regularly.

Booking.com ($24B) runs 25,000+ A/B tests annually. That’s roughly 70 tests launching every single day, with 1,000 concurrent experiments deployable across 75 countries in under an hour.

Netflix ($39B) runs thousands of streaming experiments per year, with automation enabling engineers to configure, deploy, and analyze tests from a single file.

These companies built their experimentation infrastructure over years, with large engineering teams, before the current AI moment. They prove that experimentation at scale is valuable. They don’t prove that AI is generating the variants. But they set the benchmark: this is what’s possible when you treat every user interaction as a learning opportunity.

The Value Extends Across Revenue Scales

Experimentation isn’t only for companies with hundreds of millions of users.

Electronic Arts ($7.6B) learned through A/B testing that pre-order incentives can backfire. They discovered that certain bonus structures reduced conversions rather than lifting them.

Clarks ($1.1B), the 200-year-old footwear retailer, discovered £2.8 million in hidden annual revenue by testing shipping messaging visibility. Customers weren’t abandoning because of price. They didn’t know how close they were to free shipping.

At $35–50M in revenue, companies like Curiosity Stream and Tea Collection have tested hundreds of variant combinations across key pages, generating measurable revenue lift. Tea Collection’s head of e-commerce said it “created a culture of experimentation across our organization.”

The Experimentation Infrastructure Is Emerging

The experimentation infrastructure exists. The AI generation capability exists. What’s emerging is the connection between them.

VWO has integrated GPT-3.5 to suggest copy variations directly in its visual editor. This is AI-assisted variant creation, though it still requires human selection and deployment. Evolv AI goes further, using machine learning to automatically combine and optimize variants, with newer generative AI features for creating copy and images. P&O Cruises reported achieving “6 years worth of experimentation in 3 months” using Evolv’s platform, testing 72 combinations to find a variant that generated £1.3 million in incremental revenue.

Newer tools like Mida, Keak, and Fibr AI are building explicitly around AI-generated variants. You describe a change in natural language, and the system creates and deploys the experiment. These are early, but they point toward where the integration is heading.

The full realization is not yet widespread: AI that generates variants from specification at machine speed and cost, deploys them to production, measures results, and converges on winners with minimal human intervention. But the trajectory is clear. The companies that connect these pieces will operate differently than those still treating experimentation as a quarterly initiative.

The Hard Problems

Ethical Boundaries

Not everything should be an experiment. Some variants might be manipulative, confusing, or harmful. The speed of generation outpaces the speed of ethical review.

When you can deploy hundreds of variant combinations overnight, governance becomes a bottleneck that can’t be ignored. Ethical constraints must be built into specifications before generation begins.

Infrastructure for Measurement

This model assumes solid systems for deploying variants, tracking outcomes, and converging on winners. Booking.com built this infrastructure over years. But the timeline is compressing: platforms like Evolv AI, VWO, and Webflow Optimize now offer this as a service. A children’s clothing retailer can run 341 variant combinations; a regional bank can triple conversions through systematic testing. The infrastructure that was once a competitive moat is becoming table stakes.

The Risk of Losing Depth

Behavioral data tells you what happened. It doesn’t tell you what to try next. If organizations lean too heavily on generated variants and measured outcomes, they risk losing the deeper understanding that comes from talking to users directly. The researchers who ask “what’s the WiFi really about?” prevent optimization from becoming a local maximum search with no way out.

Conclusion

The economics of code are changing. That much is proven. As production costs collapse, the economic logic points upstream: the value shifts to the work that determines what gets produced.

The full integration of AI generation with experimentation infrastructure is not yet widespread. The pieces exist. Experimentation at scale is proven valuable. AI can generate variants cheaply. The connection between them is emerging. Companies like P&O Cruises and Tea Collection offer early evidence. Tools like VWO, Evolv AI, and newer entrants are building toward this future.

The question is not whether this integration will happen, but when. And for design teams, the question is whether to build the capabilities now or catch up later.

The skills that become more valuable are the ones that remain scarce when generation is cheap: deep understanding of human needs, precise articulation of requirements, and the judgment to know when the numbers are lying.

January 17, 2026

2025 was the year user interfaces started breaking out of the AI chat box. New standards and protocols emerged defining how user interfaces will work alongside smart agentic systems. If you are not already in the know, join me, and strap in. 2026 is going to be a hell of a ride.

This primer is in two parts. Part 1 covers the four types of surfaces where AI agents meet users. It’s a conceptual grounding for anyone thinking about how UX and UI work alongside AI. Part 2 gets into the agentic UI stack: the protocols, the architectural choices, the tradeoffs. That’s for people ready to understand and build.

Pick your adventure.

The Four Surfaces

The Core Problem: Agents (still) Need Interfaces

Consider a travel agent, but not a human one. An AI agent helping someone book a trip. The agent has found three flight options. Now what?

Option A: Text

“I found three flights. Option 1: Delta, departing 8:15 AM, $342. Option 2: United, departing 10:30 AM, $298. Option 3: American, departing 2:45 PM, $315. Which would you prefer?”

This works. It’s also exhausting to read or, alternatively, listen to. The user has to parse three options, hold them in memory, and compare mentally. We invented tables for a reason.

Option B: Generated UI

The agent renders a comparison card with sortable columns, visual price indicators, and a “Select” button for each option. The user glances, compares, taps, or clicks.

Option B is probably better (depending on context). But it raises hard questions. How does the agent describe what it wants to show? How does your application render it? What if the agent is a third-party service you don’t control?

These are the questions the industry started answering in 2025. Before we get to how (Part 2), let’s understand what. The different surfaces where agents and users actually meet.

Four Surfaces: Where Agents Meet Users

Agent interfaces aren’t one thing. They show up in distinct patterns, each with different interaction models. The spectrum runs from pure conversation to pure application UI, with two hybrids in between.

Chat — Primary: Conversation. The agent is conversational (e.g., ChatGPT).

Chat with UI—Primary: Conversation. Secondary: Embedded UI. The agent is an interactive chat.

UI with Chat — Primary: Application. Secondary: Embedded chat. The agent is contextual assistance.

Generative UI — Primary: Application. The agent is embedded intelligence.

Chat

Maturity: Mature

This one we are most familiar with e.g. ChatGPT, Claude, Gemini. Chat works well for open-ended exploration, Q&A, and tasks where the user drives the interaction. But it hits limits fast. Complex comparisons become walls of text - bullet lists or tables. Multi-step workflows require the user to hold state in their head. Rich interactions like selecting from options feel clunky.

Examples: ChatGPT, Claude, Gemini, customer support bots, voice assistants.

Chat is the starting point. Not the destination.

Note: As of writing Chat GPT has over 800M weekly users. So no screenshot for this one. Its what we know already.

Chat with UI

Maturity: Emerging

Chat with embedded UI. The conversational backbone remains, but agents can inject interactive components into the flow. Cards, forms, charts, buttons, tables.

The flight comparison example from earlier is Chat with UI. The agent responds conversationally (”I found three options that match your criteria”) and renders a comparison component inline. The user can still type, but they can also click, select, interact and direct.

Expedia

OpenAI’s App Store launched in December 2025 with 16 apps and is the clearest example of this emergent pattern at scale. Mention Zillow and you can ask ChatGPT to find you an apartment - the Zillow app renders interactive listings right in the conversation.

ChatGPT App Store

Ask Spotify for a playlist the Spotify app shows a playable interface. Ask Canva to create a presentation, and Canva renders an editable deck. Other launch partners include Booking.com, DoorDash, Expedia, and Coursera. Note: As of writing you have to mention the product by name or @ it to interact.

Examples: ChatGPT Apps (Spotify, Canva, Zillow, DoorDash, Booking.com), Claude Artifacts, ChatGPT Canvas.

Chat with UI is where most production agentic applications are heading right now. It keeps the flexibility of conversation while adding the efficiency of purpose-built interfaces.

UI with Chat

Maturity: Emerging

Application with embedded chat. The inverse of Chat with UI. The user’s primary experience is a UI: a dashboard, a design tool, an IDE, or a document editor. A chat panel sits alongside, available for conversing with an agent while working.

The user doesn’t come to chat. They come to do. But when they need help, the agent is there. And because it’s embedded in the application, it already has context about what you’re working on. More importantly, the agent can act. It can modify the document, update the design, and run the code. You describe what you want; the agent does it in the interface.

Cursor IDE

The most mature examples are in agentic coding. Cursor, Windsurf, and more recently Google’s Antigravity let developers work in a full IDE while conversing with an agent that can see their codebase and make changes directly. You highlight a function, ask, “Refactor this to handle errors better,” and the agent rewrites it in place. Alternatively, Loveable and v0-style agentic apps direct the agent to build the application you imagine with a prompt. Whereas Loveable, Replit, v0, and that ilk handle integration with 3rd party databases (like Supabase), tools like Cursor remain more hands-on.

Excel Copilot

Agentic browsers such as Perplexity’s Comet also offer good insight into this pattern. The agent is aware of the content of the page and can ‘act’ as a user when requested.

Play

Perplexity’s Comet agentic browser

Google Analytics - Analytics Advisor is another example of how this is coming to life in the SaaS space. The protocols and tooling are ready. The applications are catching up.

Play

Google Analytics Advisor

Examples: Google Analytics (analytics), Cursor, Windsurf (coding); Notion AI, Excel Copilot (productivity), Perplexity Comet (web browser).

UI with Chat is powerful when the user’s mental model is “I’m working in an application” rather than “I’m talking to an AI.” The chat is a feature, not the product. The common pattern, per the examples shared, is the content framed and the chat adjacent.

Generative UI

Maturity: Frontier

Play

CoPilotKit

Pure application interface. The agent isn’t a conversational partner; it’s the intelligence behind and generating the application. Users interact with the UI directly; the agent decides what to show, what to highlight, and what options to provide. This can include a conversation element, but the key distinction is that what’s displayed has been partially or fully generated and orchestrated by an agentic layer.

Google validated this pattern in November 2025. Their research team published “Generative UI: LLMs are Effective UI Generators,” demonstrating that AI models can generate not just content but entire user experiences. Web pages, games, tools, applications. All designed and fully customized in response to any prompt. A single word. A paragraph of instructions. Doesn’t matter.

Left: Fashion advice. Middle: Learning about fractals. Right: Teaching mathematics

The results? Sites designed by human experts had the highest preference rates. Generated UI came in second, close behind. Then everything else: the top Google Search result for the query, raw LLM text, standard markdown. The generated interfaces were strongly preferred over all standard LLM output formats.

The paper frames this as “a first step toward fully AI-generated user experiences, where users automatically get dynamic interfaces tailored to their needs, rather than having to select from an existing catalog of applications.”

Read that again. Rather than selecting from an existing catalog of applications. The implication: apps as we know them may be an intermediate form.

The capability is now live, though still experimental. In the Gemini app, it’s called “dynamic view” and runs as a Labs experiment on desktop (not mobile yet). In Google Search AI Mode, generative UI is available to Pro and Ultra subscribers in the US. Google is A/B testing both, so you might see different versions.

Play

Google search results with a Van Gogh dynamic gallery (created with Gemini)

The addition though is important. Google isn’t just publishing theoretical papers on the subject. They shipped it. It’s experimental, it’s limited, but it’s in production with real users.

But here’s what makes Generative UI truly frontier: it doesn’t stop at one-shot generation. In its full-blown form, the UX and UI orchestrator agent is hypothesizing interface improvements, building them and A/B testing them, then finally auto selecting the best. Think of a UI, eventually a product, subject to Darwinian style evolution. Google proved the foundation, but we have the trajectory.

Side note: This one is probably the most scary for a UX/UI designer today, and if you are one, I’d encourage you to embrace the change because it’s coming whether you want it or not. Ride the wave; don’t get hit by it.

This pattern takes several forms:

Proactive/Ambient: The agent observes and surfaces insights without being asked. A dashboard that highlights “Revenue dropped 15% in Southeast region, here’s why.” A design tool that warns “These elements are misaligned.” The user didn’t ask. The agent noticed.

Orchestration: The agent decides what to show, what to prioritize, what to fetch. The user sees a curated interface but doesn’t realize an agent is generating it.

Responsive to manipulation: The user drags, clicks, selects. The agent responds by updating other parts of the interface. You move a box in a design tool; the agent suggests layout adjustments elsewhere.

Invisible infrastructure: The agent is so embedded you don’t think about it as AI. Google Maps routing. Spotify’s recommendations. Smart home interfaces deciding what’s urgent.

Proto-examples of this pattern predate the current stack. Algorithmic feeds, recommendation engines, and apps like Google Maps and Waze have operated this way for years. What’s new is the tooling to build generalized Generative UI.

Tools like Lovable, Bolt, and v0 are particularly interesting here. Their interface is Chat and UI (you describe what you want, they show previews), but their output is an agent-authored application. An entire UI generated by an agentic layer. They’re meta-tools: Chat and UI interfaces that produce Agentic UI artifacts.

Proto-examples: Google Gemini Search, Spotify, Waze, algorithmic feeds, recommendation systems.

Tools enabling Agentic UI: A collection of emerging standards and protocols. See Part 2.

Generative UI is the frontier. The protocols exist. The tooling to create it exists. But production applications fully leveraging these new capabilities are only beginning to emerge. This is where agents stop being “AI features” and become invisible infrastructure.

The Voice Dimension

Voice isn’t a fifth surface. It’s a modality that cuts across all four. But its impact varies depending on where you are on the spectrum.

For Chat and Chat with UI, voice is convenience. You’re speaking instead of typing. Siri, Alexa, and ChatGPT voice mode are examples. It’s hands-free input, but you still need to look at the screen to see and interact with whatever UI the agent renders. Useful. Not transformative.

For UI with Chat and Agentic UI, voice is control. You’re not just inputting. You’re commanding an intelligent system that can act. The agent changes state, modifies documents, orchestrates systems, and reports back. Voice becomes a way to operate an application, not just converse with it.

The difference is significant.

UI with Chat + voice: You’re in Cursor, hands on the keyboard writing code. You say “refactor this function to handle the edge case we discussed.” The agent does it. You never broke flow. Voice isn’t replacing typing. It’s a parallel control channel while your hands do other work.

Agentic & Generative UI + voice: You’re driving. You say, “Cancel my 3pm, message Sarah that I’ll reschedule, and find me 30 minutes tomorrow for a replacement.” The agent does all of it. Then it says, “Done.” I noticed you have a conflict tomorrow morning. Want me to sort that out too?” Eyes on the road. Hands on the wheel. Full control of an intelligent system acting on your behalf.

This opens up:

• Parallel input: voice commands while hands do other tasks (driving, cooking, physical work).

• Conversational feedback loops: the agent acts, describes outcomes, you course-correct verbally

• Accessibility: agentic applications available to users who can’t rely on screens

Voice in the first two patterns is a nicer way to talk to a chatbot. Voice in the last two is a way to command an intelligent application to create outcomes.

Delegated UI

Maturity: Emerging

At the far end of the spectrum, the interface disappears. Not because design failed, but because the user isn’t there.

In Delegated, the user has handed off execution. “Book me the cheapest flight that gets me there by 6pm.” “Process expense reports that match policy, flag the ones that don’t.” “Schedule something with Sarah next week.” The agent acts. The user reviews outcomes later, or not at all.

This pattern isn’t new. Email filters, auto-pay, smart home routines, and Zapier workflows have operated this way for years. What’s new is agents with enough judgment to handle ambiguity, situations where pre-programmed rules would break. Klarna’s AI resolves customer service claims end-to-end. AI SDRs send outreach without human review. Replit agents maintain deployed applications autonomously.

This isn’t Generative UI. In Generative UI, the agent orchestrates what the user sees in the moment. In Delegated, there is no moment. The user set intent, explicitly or through learned preferences, and walked away.

The design challenges shift entirely:

• From “what does the user see?” to “what is the agent allowed to do?”

• From “how does the user interact?” to “when does the agent escalate?”

• From “what’s the flow?” to “what are the guardrails, cost ceilings, and rollback mechanisms?”

Jakob Nielsen explores this shift in No More User Interface?, arguing designers will move from wireframes to operating manuals, defining policies and confidence thresholds rather than screens.

This is real design work. But it’s not UI design. Parts 1 and 2 of this series focus on the surfaces where users and agents still meet visually. We’ll return to Delegated and what it means to design for user absence in a future article.

So that’s the territory (so far), and only lightly touched. Four surfaces, from mature to frontier, with voice as a force multiplier. If you’re here for a conceptual grounding, you have it. If you want to understand how to build these surfaces, the protocols, the architectural decisions, and the tradeoffs, continue to Part 2 (coming soon).