Agentic UI: Two Modes I Learnt Building With Claude Code

Tristan Russell • April 2026

I have spent the last year getting AI coding agents to build user interfaces for me. A mobile Sudoku app. A personal portfolio. An indie software studio brand. A learning-platform prototype. Some of the output was good. A lot of it was terrible in exactly the same way, every time.

This post is what I learnt, and what the wider industry has shipped alongside that learning. The short version: there are two distinct modes of working with agents on UI, and getting good results requires knowing which mode you are in.

I want to be honest upfront that none of this was obvious to me when I started. I walked into every pitfall before I understood what I was doing wrong. My first project, a Sudoku app I started back when Claude 3.7 Sonnet was the frontier model, is still carrying technical debt from hard-coded values I spent weeks cleaning up later. That experience is a lot of what this post is about.

The Problem You Will Hit Immediately

Ask a coding agent to build a UI from scratch and the output has a fingerprint. Purple gradients on white backgrounds. Inter or Roboto as the font. Softly rounded cards with drop shadows. A palette that hovers somewhere between pale blue and washed-out lavender.

It is not bad. It is just always the same.

Anthropic's own Claude Code ships with a frontend-design skill that calls this aesthetic "AI slop". Adam Wathan, the creator of Tailwind CSS, apologised on X in August 2025 for making every button in Tailwind UI bg-indigo-500 five years ago. That choice trained a generation of models to make every AI-generated button the same colour.

The industry has named it. The problem is real and widely acknowledged. What surprised me is how little guidance exists for what to do about it beyond "write better prompts."

Why It Happens

Large language models return the statistical centre of their training data. Anthropic calls this distributional convergence. Without guidance, an agent asked for "a clean, modern landing page" reaches for the patterns that appeared most often in its training data: the Tailwind defaults, the dashboard template that shipped on a thousand marketing sites.

Distributional convergence in one picture. The agent returns the centre of the distribution unless given an anchor that pulls it elsewhere.

The failure mode I hit hardest was not the initial aesthetic. It was the drift. Ask the agent to modify an existing page and the new components do not match the old ones. Spacing shifts. A colour swaps for a similar-but-wrong alternative. Each round pulls harder toward the centre.

TDP's Dianne Alter documented this precisely: when she tested Google Stitch on a real brand without a design specification in context, Stitch invented a green colour palette for a design system that had no green.

That was my first real lesson. The agent needs an anchor strong enough to overcome the pull toward the mean. Prompt engineering alone does not provide one.

Two Modes, Not One

I tried a lot of things. Most did not work. Two approaches did, and they turned out to solve different problems:

Creative generation under constraint. Bespoke design work where the agent produces original UI against a defined brand system.
Declarative generation from a schema. Content work where the agent assembles pages from a pre-built component library.

These are not the same problem. They do not benefit from the same techniques. Treating them as one is part of why early attempts fail.

CopilotKit has published a useful three-mode taxonomy of generative UI: static, declarative, and open-ended. Static is the conservative end of the spectrum: the agent doesn't design or assemble anything, it just maps generated data to predefined components. A weather card. A chart that always renders the same way. In practice it is less generative UI and more "the agent decides which component to show." It is the right starting point for most teams, and most production apps still live there.

My two modes sit further along the spectrum. Mode 2 maps onto their declarative: the agent emits a structured specification against a registry of pre-approved components, not arbitrary HTML. CopilotKit frames it as a middle ground that is neither handcrafted per use case nor fully free-form, and that is exactly the posture I have found works for content-heavy projects. Mode 1 sits at their open-ended end, but shaped by brand guidelines rather than running loose.

Both are valid ways to do generative UI. The interesting question is where each one actually belongs.

Open-ended generation is too slow to do on the fly. Building tristanbuilds.com took Claude Code several hours of back-and-forth against the brand guidelines. That investment is fine for a site that then sits there, but the same process triggered every time a user opens a page would be unusable: too slow, too expensive, too prone to regression between runs. So Mode 1 belongs in agentic development, where the agent helps author code that ships once. Mode 2 is where the industry will land for generative UI on the fly: runtime composition fast and reliable enough to sit in the critical path of a live product.

There is a speculative third lane. Open-ended generation might become useful at runtime again in non-time-sensitive environments. Imagine an agent you talk to, plan with, and send off to work for an hour on your behalf. You come back and it has drafted a highly personalised UI for you. The constraints that kill open-ended in a live request-response product (slow, expensive) stop mattering when the user is not waiting. My bet for the mainstream is still declarative, but this is the most interesting place open-ended could go.

Mode 1: When You Want Something Original

My first proper attempt at Mode 1 was tristanbuilds.com, the brand site for my indie software studio. I wanted something distinctive. Honest, restrained, anti-dark-pattern. A visual identity that matched the values.

My first instinct was to give the agent those values and let it design. I got the centroid. White backgrounds, pale blue accents, the same generic minimalism every AI landing page has. The agent heard "honesty" and "simplicity" and reached for the same vocabulary thousands of design blogs use to describe the centroid.

That did not work. Here is what did.

Research First, Design Second

I stopped asking the agent to design from values. Instead, I used Claude.ai's research feature to investigate what actually constitutes a strong brand guidelines document. Logo rules. Colour systems with contrast ratios. Typography hierarchies. Tone of voice. UI pattern conventions.

Then I had the agent build a full branding document for Tristan Builds, applying that research to my specific brand.

I reviewed it and caught hallucinations. The agent had confidently invented the surname "Davison" for me, one of many reminders that AI output needs human verification. I corrected, refined, and only then handed the document to the design agent.

The output was the current tristanbuilds.com. Not a centroid. A coherent visual system grounded in stated rules.

The current tristanbuilds.com, generated by Claude Code against a full branding document.

This matches what Anthropic has since formalised. In November 2025 they shipped a frontend-design Skill built into Claude Code that explicitly instructs the agent to avoid Inter, Roboto, purple gradients, and cookie-cutter layouts. They have also published a use case guide for packaging your own brand guidelines as a Skill.

The pattern I stumbled on turns out to be the pattern Anthropic recommends.

Build The System Before The Output

One lesson kept surfacing across every project. How much an agent helps you is directly proportional to how much structure you give it to work inside.

The clearest example is hard-coded values. Ask an agent to build a button and you will often get a hex code baked into the component's stylesheet. Ask for another component and you will get the same hex code written out again. Nothing breaks. But there is no single source of truth, and the next global change becomes an archaeological dig.

The fix is to set up design tokens before the agent generates anything. Named variables for colours, typography, spacing, and radii, referenced everywhere instead of literal values. Iris van Dijk's piece on hard-coded colours calls this the difference between local decisions and system decisions.

The same principle applies beyond tokens. An explicit instruction file, a CLAUDE.md or an AGENTS.md, telling the agent your conventions, your constraints, and the patterns you want it to follow, does more for output quality than any clever prompt.

The architecture is the leverage. Build the system correctly and the agent becomes a disciplined collaborator. Skip that step and you end up with the centroid, scattered everywhere, in permanent marker.

Making Guidelines Persistent

One practical problem with brand documents is that they are ephemeral. Every new coding session starts fresh, and re-uploading a 40-page PDF every time is friction you will eventually stop tolerating.

The solution is Claude Code Skills: folders containing a SKILL.md file and supporting resources. Claude does not load every Skill into context at session start. It uses progressive disclosure: only the short YAML description loads initially, and the body loads on demand when the agent judges it relevant.

That matters because it means you can decompose your guidelines. One Skill for tone of voice. One for colour and visual identity. One for typography. One for component patterns. The agent loads only what the task needs.

Writing copy pulls in tone of voice. Building a new component pulls in colour and typography. The context window stays lean. The brand stays consistent.

Anthropic made Skills an open standard in December 2025, which means the pattern is not Claude-specific. Simon Willison has called Skills "maybe a bigger deal than MCP", which is a striking claim from one of the most careful practitioners writing in this space.

Mode 2: When You Want Fifty Pages That All Look The Same

Brand guidelines solve the creative-work problem. They are the wrong tool for the other problem I hit: producing many pages that all need to look the same, hold together as a system, and ship fast.

For a learning-platform prototype I was building, freeform UI generation kept breaking down. The first page looked decent. The fifth looked slightly different. By the twentieth, the site felt like it had been designed by twenty different people.

So I stopped letting the agent design.

Compose, Don't Generate

Instead, I pre-built a library of reusable components inspired by LinkedIn Learning and Coursera. Each page became a JSON file: a list of component references with their content parameters. The agent did not write CSS or HTML. It selected components and filled their parameters. The rendering layer, which I controlled, handled everything visual.

This is what CopilotKit calls declarative generative UI: the agent returns a structured specification rather than arbitrary UI code, and the rendering layer interprets that specification against a registry of predefined components. Their framing is that declarative preserves consistency while giving agents far greater expressive power than purely static component libraries. That matches exactly what I saw.

Three-panel diagram showing an agent writing JSON page configuration on the left, a rendering layer in the middle, and the final rendered web page on the right. — The agent writes JSON. The rendering layer handles the visual output. Every page draws from the same component library.

On that project, with templated sections and a single operator, I saw throughput gains of roughly five to ten times on the page-generation work specifically. Ten pages in the time it would previously have taken to produce one or two.

But raw speed is only half the story. The consistency I got was the other half, and in practice it mattered more.

In Mode 1 work, every iteration carries a risk of drift. You ship a page, come back two weeks later, ask the agent to extend it, and something shifts. A colour changes. Spacing loosens. The new section does not quite match the old one. You spend almost as much time correcting the regression as you did on the original work.

In Mode 2, that entire category of rework disappears. Every page draws from the same component library. Visual coherence is structural rather than negotiated.

The 5–10× I saw is not the agent coding faster. It is the agent not having to code at all. Mode 2 is not freeform work. The decisions are already made. The agent is filling a schema, not designing a system.

Why Declarative Generation Works

Five things change when you move from freeform generation to composition:

No design deliberation. The agent picks components and fills parameters. Generation becomes closer to data entry than creative work.
Consistency is guaranteed. Every page draws from the same component library, so visual coherence is structural rather than negotiated.
No iteration spiral. There is nothing to iterate on visually because the components are already correct.
Context efficiency. The agent needs the component schema, not the full codebase. A 200-line schema beats a 10,000-line repo as input.
Lower contribution barrier. JSON page definitions can be produced by anyone who can fill a form.

The trade-off is real. You give up creative latitude. The more components you add to address edge cases, the harder the agent finds it to choose between them. And the component library itself has to be high-quality, or the whole system inherits the quality ceiling of the worst component in it.

The Industry Shipped This Pattern

While I was figuring this out on a personal project, serious companies were shipping production versions of the same pattern.

Sanity released Agent Actions, generating schema-validated content where outputs are checked against the content types in your schema. Vercel released json-render in January 2026, hitting 13,000+ GitHub stars within two months. Builder.io Fusion 1.0 shipped in November 2025, generating production code by mapping designs onto your existing component library. Contentful added AI Actions. Storyblok released an MCP server. Figma Make ships with "kits" and "slots" that constrain AI generation to a predefined design system.

The pattern is now conventional wisdom among the platforms that take this seriously.

Choosing Between The Two

Both modes are valid. The question is which fits the work.

The two modes solve different problems. Mode 1 makes one bespoke thing look right. Mode 2 makes many things look the same.

Dimension	Creative generation (Mode 1)	Declarative generation (Mode 2)
Best suited for	Brand identity, marketing, bespoke design	Content sites, documentation, product pages
Primary constraint	Brand guidelines loaded as context	Component library plus JSON schema
Throughput	Low, each page individually shaped	High, the agent fills slots
Consistency	Depends on guideline quality; drifts over iteration	Guaranteed by the component library
Creative ceiling	High, limited by brand rather than parts	Capped by what exists in the library
Required investment	Design tokens, brand docs, Skills	Components, schema, rendering layer
Failure mode	Centroid drift when guidelines are thin	Stale or inconsistent component libraries
Who can contribute	Designers, developers	Anyone who can fill a structured form

If your project needs a distinctive brand moment, invest in Mode 1. Build the tokens, write the guidelines, encode them as Skills. If your project needs many similar pages at speed with guaranteed consistency, invest in Mode 2.

Most organisations will need both. The strategic question is not which mode to pick. It is which workloads belong in which mode.

Where This Is Heading

Here is what I find most interesting. The same pattern is now appearing one layer up, in how design systems themselves are being rebuilt to be consumed directly by agents.

Through 2025 and into 2026, every major design system has shipped or announced agent-consumable infrastructure:

Atlassian released @atlaskit/ads-mcp for AI prototyping
Shopify launched unified Polaris in October 2025, designed for LLM-assisted workflows
IBM shipped a Carbon MCP server
Figma's Dev Mode MCP Server reached general availability
shadcn/ui lists "AI-Ready" as a core product principle

The pattern is the same across all of them. Take the design system you already have and make it structurally legible to an agent. Expose the components, the tokens, the constraints, the valid compositions.

Turn the design system from "a library humans read" into "a library agents can query and compose from."

The protocols underneath this shift have consolidated faster than I expected. Model Context Protocol (MCP), Anthropic's open standard from November 2024, was adopted by OpenAI in March 2025 and Google and Microsoft later that year. Anthropic donated MCP to the Linux Foundation in December 2025. By April 2026 there are roughly 10,000 active public MCP servers.

The UI-specific layer is newer but real. MCP Apps (SEP-1865) launched in January 2026. WebMCP reached W3C Draft status in February 2026 and shipped behind flags in Chrome 146 and Edge 147.

My reading of the trajectory: the next eighteen months will sort the design systems that anticipated this from the ones that did not. Teams that already parameterise their components, expose their tokens, and ship clean schemas will find both agentic composition and creative generation work against their existing system.

Teams that treat their design system as bespoke pages will have to rebuild the substrate before agents can usefully deploy inside their content process.

I could be wrong about the timeline. I do not think I am wrong about the direction.

Agentic UI is no longer a research area you peek at from the sidelines. It has shipped. The question now is how thoughtfully you adopt it.

Both modes exist because both solve real problems. The teams that understand when to use which, and invest in the right substrate for each, will move faster than the ones that conflate them.

What has your experience been? I am particularly interested in where the two-mode frame breaks down, or where people have found a third pattern I am missing.

References

The sources behind this post, organised by topic for further reading.