So I drew this curve when I noticed a repetitive pattern across several projects that I built with AI agents.

💡 IDEA ↑

A new idea always gives me the first high because in my head I can already imagine how the product works. With AI, I’m not that worried about the building process; the only thought in my head is: “I have to build it.”

🧠 Plan ↓

Then I start talking to the agent to plan the product, and that’s when I start to think about the details: the product features, the interactions, some technical limits, and all the other things that start to appear. My enthusiasm gets lower as the idea becomes more concrete, because now you have to worry about the real problems.

🪄 First shot ↑

But the first shot from the agent raises the curve again, because it produces a rough version. A working prototype shows how the function works, and for a moment, you feel that the product is already there. I love this part because it gives me a quick hit of dopamine, like watching a short video. Something that existed only in my head a few minutes ago can suddenly be clicked and tested.

🐞 Debugging ↓

Conversely, the iteration phase with its heavy bug fixing is where my enthusiasm reaches its lowest point. Bug fixing is never really part of a designer’s mindset or work. It is repetitive, and often one fix causes another problem, which leads to another fix. This is usually the hardest part for me.

️️✏️ Refinement ↑

Aside of bug fixing, I start to add design refinements, which I really enjoy: crafting visual details, motion, and sounds to make it more personal, and adding a bit of my own taste. This is the hands-on design work I am most comfortable with.

️️👌 Done ↑

When the product finally works and you find it is almost there, the curve rises again. But you’ll never know if it is truly done.

⚙️ Testing ↓

Then come tests and adjustments. While necessary, they are also a bit boring, and the curve dips once more.

🚀 Launch ↑

Finally, it is time to publish the product. This is a major milestone—the product gets a domain and you spread the word.

🏜️ Deserted ↓

But if nobody cares, it is a sad story. This often happens when I build solely from my perspective as a creator, following my own curiosity instead of solving a user problem.

Making something and getting people to use it are two completely different jobs. AI agents have made building so easy and cheap, but attention has become increasingly expensive. Product marketing is just as critical as building itself.

The curve shows me where my fuel comes from: imagination creates the fuel, while the realization drains it. To reach the final destination, you need a kind of force field: an obsession. Some people call it intention—the intention to keep you there. That is why I feel vibe coding is the odyssey of your mind.

For everyone undergoing this same mental journey while building things, my only advice is this:

Keep your obsession and enthusiasm alive with your imagination while working through the engineering parts to make it come true.

Those conversations reveal a fact that, for designers who are new to coding agents, getting started can feel daunting. While a few frameworks, examples, and ways of working can make that first step much approachable.

But once you begin, curiosity would drive most of the work. You try something, break something else, figure out why, and try again. Soon, the tool becomes less frightening.

So I’m sharing the complete slide deck as a reference for anyone who wants to bring coding agents into their design practice. Take whatever helps you get started, then adapt it through your own work.

One thing is clear: the best way to learn how to build is to build something.

Subscribe now

Claude Code can already do plenty of basic research work. It can search the web, compare products, synthesize documents, and organize the result into a template. These are useful capabilities, and by now, many of us use them almost every day.

I use them too, but they are not what I want to focus on here. The more interesting change in my own work has happened at two other points in the research process:

How I think while the research is still open, and how the result enters a product team once the research is done.

In those two moments, I use Claude Code in two different roles: as a thinking partner and as an artifact maker.

Subscribe now

Read more

Every time you start speaking, say: “Hi Legend.”

It sounds stupid.

That is the point.

I don’t use this line because I want my AI assistant to flatter me. I use it as a warning signal.

Subscribe now

Context Rot

When you work with Claude Code for long enough, you start to notice a strange kind of decay. The context indicator at the bottom slowly fills up. At first, nothing seems wrong. The model still answers quickly. The tone is still confident. The work still moves.

But as the circle gets closer to full, the quality starts to slip.

Not all at once. Slowly.

The so-called Context Rot: the slow decay of shared context between you and the AI, while the model still sounds completely fine.

It forgets a rule you set earlier. It ignores a small preference. It stops following a writing constraint that was obvious two hours ago. It still sounds fluent, which makes the problem harder to notice.

This is the annoying part of AI collaboration: the model does not tell you when it starts forgetting.

When the context gets too full, earlier conversation gets compressed into a summary to make room. That summary keeps the session alive, but it is not the same as memory. Some details survive. Some don’t.

And the things that disappear are often the things you care about most: the small rules, the decisions, the boundaries, the “please never do this again” moments.

By the time you notice, the work has already drifted.

So I leave a passphrase at the top.

Like two spies meeting in a station. Before they exchange anything important, one says the line. If the other person does not answer correctly, you stop trusting the situation.

For me, if Claude no longer says “Hi Legend,” I know that is the moment to reset.

The trick is simple:

Because the scary part is not that AI forgets.

The scary part is not knowing when the forgetting began.

Claude Code is an agent, and an agent is only as good as how you configure it. That’s the part worth paying attention to as a designer:

Out of the box it leans engineering, but you can set it up to fit how you actually work — to understand design, respect your workflow, and carry the right capabilities — so it produces better results, faster.

That setup process is what this piece is about. I call it your design stack.

Let’s get into it.

What a design stack is

A technical stack is the set of technologies you decide on before writing a line of application code.

A design stack is the same idea, applied to Claude Code: the brief, the design knowledge, and the tools you hand the agent upfront.

The reason it’s worth doing is that it’s a one-time setup. Configure it once, and the agent shows up understanding your project and your design language — instead of a capable stranger improvising from scratch on every task.

It has three parts, and the easiest way to hold them in your head is to imagine three different people you’d hire:

1. CLAUDE.md → the Creative Director. The project brief.

2. DESIGN.md → the Design Guardian. The design system guide.

3. MCPs and Skills → the Specialists. The toolkit.

Each does a distinct job. Together they’re the onboarding you give Claude Code before it touches the work.

Below are some perks for paid subscribers:

• CLAUDE.md, DESIGN.md, MCPs, and Skills each broken down in depth — what they are, how to configure them, and how they work together in practice

• The specific MCPs and Skills I’d tell any designer to install, with the actual resources and links I use day to day

• A step-by-step guide to building your own Claude Skill from scratch, the way I built mine.

Read more

I’m a designer learning to build. Which means I have a stake in one of the loudest claims in tech right now:

I wanted to know if that was true — so I tried to take it apart.

The Missing Layer

Here’s where it started. You build a site with AI, point it at Linear, tell it to copy the style. The AI obeys: it reads the fonts, colors, radii, spacing, packs them into tokens, builds from the numbers.

The background is dark. The font is sans-serif. The corners are 6px. And something is off. The proportions feel wrong. The rhythm feels wrong.

Most people blame incomplete extraction. That isn’t it. A set of tokens does not add up to a style. You can hold every value a site has, and still fail to reproduce how it looks. Because the numbers are dead, and the logic that uses them is alive. The moment your AI hits a page that didn’t exist on the original site, it has nothing to judge against, so it guesses

Tokens tell the agent what to use, not how to think. The missing layer sits above the numbers.

That missing, I suspect, is taste.

“Taste” Is a Word That’s Been Worn Out

For the past year, taste has been everywhere in tech — crowned “the last human moat in the age of AI.”

Paul Graham says it’ll only matter more. Andreessen says picking the right thing to build is itself taste. A thousand LinkedIn posts repackage it as a mystical, unteachable gift. But almost nobody says what taste actually is.

, in his column for The New Yorker, mentioned “taste-washing” — companies using the word as a humanist fig leaf over an anti-human technology. He reaches back to Voltaire: taste isn’t just seeing what’s beautiful, you have to feel it. So AI is fundamentally tasteless.

I agree feeling is the source of human taste. But I’m curious about the other side.

A designer’s taste eventually lands — as concrete decisions: this color not that one, space here not there. Those decisions have a logic, and logic can be articulated. So: can that landing layer be extracted, so an AI works from it? The AI doesn’t need to possess taste. But could it reproduce its output?

To find out, I ran an experiment. Running it is what clarified the first question too.

Subscribe now

Style Extractors Only Do a Third of the Job

Tools like CSS Peeper and miromiro already pull style off a site — every font, color, spacing value, radius. That’s the what. Useful, but only the first layer.

One layer down is the how. If spacing runs 4, 8, 16, 24, 32, 64, the how is “multiples of 4.” Building a new page, you don’t look up the original numbers; you remember the rule. Rules transfer. Values don’t.

One layer below is the why. Why separate hierarchy with grays, and barely touch the brand color? Why does the accent land only on the single most important button? This is judgment.

An example. A lot of premium sites are almost entirely black, white, and gray — except the one CTA button, in the brand color. They could have used more brand color in the headings, the nav. They held back. Because once a color is everywhere, it stops meaning anything. Save the bright one for the place you most want clicked, and the eye goes there on its own.

That’s a trade-off: giving up projecting the brand for guiding the next click.

That trade-off is taste. Which gives me a working formula:

The trade-off is what you took and what you gave up; the decision is the reason behind it. Most tools stop at the what. A few reach the how. Taste lives in the why.

Reverse-Engineering the Why

If taste is trade-off logic, it can run backwards. The method is abductive reasoning: hand it a finished result, have it infer how the decision was made. A detective reading a crime scene; a doctor reasoning from symptoms to cause.

The difference is a design’s “symptoms” are scattered across fonts, colors, spacing, shadows — so you measure each first, find the patterns, then infer the decisions behind them.

It has just became #1 Product of the Week in Design Tools, on top of #2 Product of the Day on Product Hunt 👏

Hand it a URL; it opens a browser, visits a few connected pages, pulls data and screenshots, runs a four-step pipeline, and returns two files: a Design Map (the values) and a Taste DNA (the judgment).

The pipeline: split one large task across four agents, each with one job — the surveyor, the detective, the critic, the skeptic.

Read more

Claude Code can now write directly to the Figma canvas through Figma MCP.

You describe an interface in natural language; it builds it. Visually, the result can be pixel-perfect. But click into any layer and you’ll find #5C6AC4 where color/brand/primary should be, 14 where text/body-sm is defined, a freshly minted one-off component where an existing Button instance is sitting right there in the library.

The design system has all of this. Claude Code used none of it.

The problem isn’t capability. It knows how to call the Figma API, how to query a library, how to bind a variable. It just doesn’t know that in your project, it must. Nobody told it the rules, so it made up its own.

The Harness, and What It Isn’t

In AI engineering, people talk about a concept called Harness:

The constraint framework you build around a model. It defines what the model can do, what it can’t, and how to verify the output. The model is the engine; the harness is everything that makes the engine run by your rules.

I want to be precise here: what I built is not a harness. A harness is an architectural concern. It lives at the system level. What I built is closer to a workflow enforcement layer:

In this case, Figma. And the problem is governance.

Figma has its own governance system: variables, styles, component libraries, naming conventions. But Claude Code operates entirely outside that system.

• Every color value is isolated.

• Every component is improvised.

• Every modification requires re-locating everything from scratch.

• It passes visual QA. It fails structural QA.

The question is straightforward:

Four Skills, Four Rules

Based on that framing, I built a set of Claude Code Skills specifically for Figma design workflows. Four skills, each handling one job.

01 | Preflight: Health Check Before Anything Moves

Every design session starts with three parallel checks:

1. Is Figma MCP connected?

2. Are file read/write permissions in place?

3. Are styles, variables, and components from the current file fully loaded?

It outputs a Token Map and Component Registry as the reference baseline for the entire session. Until Preflight passes, no node gets created.

The value is simple: you don’t discover thirty minutes in that your library tokens never loaded.

02 | Reference Interpreter: Plan Before You Build

When you share a screenshot, a reference link, or a design description, this skill triggers. It parses your input into a structured Design Brief: which sections to build, which components to use, which tokens to apply. You confirm direction first. Then construction begins.

03 | Component Rules: Search Before You Create

Every UI construction task follows one rule: search the connected library first. If a matching component exists, use its instance. Only if nothing is found do you build from scratch, and even then, auto layout and semantic naming are mandatory.

This skill changes the AI’s default behavior. Without it, the instinct is to invent. With it, the first move becomes look up.

For any team that maintains a design system, that sequence is the difference between usable and not.

04 | Style Binding: Token Enforcement and QA

Whenever a task involves color, typography, spacing, or border radius, this rule activates. Every visual property must bind to its corresponding variable or style. No raw values accepted.

After writing to Figma, it runs a QA pass, confirming bindings item by item.

This is the most essential of the four. It does exactly one thing:

The Tool Follows the Scenario

These skills don’t just solve a token-binding problem. They encode a more fundamental judgment: the same AI tool should play different roles in different contexts, and produce different kinds of output accordingly.

When the designer needs to stay in the loop, Claude Code acts as a design assistant. Its output must be something a human can pick up, modify, and iterate on. That means compliance at every layer: tokens, components, layout structure. All four skills are active. The full governance chain is in effect.

When the goal is a quick prototype, it switches to coding mode. Speed takes priority over compliance. The enforcement layer steps back. Raw values are expected, not exceptions.

AI is powerful enough to write Figma. It’s powerful enough to write React. But the gap between a powerful tool and a usable one is often just a set of rules that nobody wrote.

I’ve spent seven years in the design industry. Strip away the user research and product definition, and the core task was always the same: draw things. Wireframes, visual specs — hand them to engineering, then wait. I was essentially a translator. Translating requirements into ideas, ideas into files, and then waiting for someone else to translate those files into code.

That changed in 2024.

My main tools now are Claude Code, Figma Make, and LLMs. They’ve rebuilt how I work from the ground up. I replaced static deliverables and Figma prototype flows with working demos. Instead of digging through component libraries, I connect my design system to Claude Code and have it generate the interface. I run research and synthesis inside ChatGPT projects.

In this process, I’m no longer a translator. I’m more like a conductor: issuing direction, converting my intent and experience into tasks AI can execute, then applying a senior designer’s judgment to evaluate what comes back. For the parts that matter most, I’m still hands-on.

Seven years of experience haven’t become obsolete. They’ve just moved.

The skills are the same, where they apply is different.

Subscribe now

i. Developing a “Design Sense” Inside Code

Designers have always carried a particular frustration: you can imagine it, but you can’t build it. Or more precisely: what you produce and what actually runs are never quite the same thing.

Figma is a great tool. It slows you down and forces you to think, because it’s a middle layer. The instincts you develop there are spatial and visual — you sense change by dragging shapes around. That’s fundamentally the same as sketching on paper.

In a real product, design sense lives in systems and time: how the interface behaves when real data flows in, the easing of an animation, the logical chain between one interaction and the next. These are different muscles entirely.

Externalize Your Tacit Knowledge ↘

AI coding has dramatically lowered the cost of a first draft. The hard part now is generating a high-quality first shot — and then iterating effectively from there. What that actually tests is whether you can transmit your tacit knowledge to the AI.

AI understands the world’s explicit knowledge: things you can Google, documentation that’s been written down, concepts that have been named and structured. But most of what you bring to your work is tacit — accumulated through years of practice. It’s more like a personal knowledge graph: some of it is public, but a lot of it is uniquely yours. Hidden reasoning behind your calls. Intuition that tells you why something is right without being able to fully explain it. If you can’t transfer that, AI output will be generic.

The 3C framework helps: Context, Components, Criteria.

Context is everything the AI can see.

You need to transmit the full background of your project — what you’re building, who it’s for, what constraints exist, what decisions have already been made. For ongoing projects, I keep a context file in the project folder that the AI reads every session and that I update as things evolve.

Components are the tools you hand the AI to do the job.

LLMs have reasoning and retrieval built in — but for specialized work (code review, frontend design, unit testing), they need more specific scaffolding. That’s when you pull in the right Skills or configure MCP. The point: don’t assume the AI already has everything it needs to complete your task. You have to hand it the tools.

Criteria is how you define output quality.

It’s not just about telling the AI what to generate — equally important is telling it what not to generate. Negative constraints are often more effective than positive instructions. Set specific standards for format, style, and accuracy, and build in a mechanism for the AI to self-evaluate. After generating a UI, I’ll ask it to check: did it default to blue-purple? Did it reach for Arial? A quick self-audit for whether it’s produced AI slop.

With these three layers in place, the judgment calls that live in your head — the ones you’d struggle to articulate out loud — can be transmitted clearly. The output quality shifts noticeably.

Actually Run It Yourself ↘

Watching someone do something and doing it yourself are completely different experiences. There are endless AI tutorials out there right now, but the only real way to learn is to build something.

Specifically: have the AI generate a project architecture and watch how it organizes files and modules. Ask it to write tests and observe how it handles edge cases. Follow an error message down the stack until you understand what it’s actually saying. After you’ve run through this once end-to-end, you’ll find that a lot of the technical fear you had was imaginary.

More importantly — you can only develop your own general rules by doing specific things. For example: when an agent keeps circling the same bug without breaking through, you can bring in a different AI for a fresh perspective and escape the failure loop. That kind of judgment can be learned from others, but it mostly comes from accumulation.

After vibe-coding five products, you start to feel a faint “sense of the material.” It’s essentially muscle memory built on states.

ii. Redesigning the Design Process

Jenny Wen, Head of Design at Anthropic, argued on Lenny’s Podcast that the traditional design process — research, diverge, converge, deliver — is dead. Specifically:

1. Engineering velocity has outpaced linear design workflows

2. Designers no longer have time to “obsess” over static visual specs

3. Long-horizon “design vision” has become impractical

From this view, the death of the design process looks like it was forced by engineering’s dramatically expanded execution capacity — with a bit of tech industry hyperbole mixed in. The traditional diverge-converge flow hasn’t actually failed.

Intuition → Demo → Inevitability ↘

In the past, rigorous upfront research was necessary because building something verifiable was expensive. Now that cost is close to zero. The entire game has changed. Experienced product thinkers can rely on intuition to generate a demo, then use that demo to pressure-test their judgment — instead of talking in circles at a whiteboard about whether a direction is right.

More critically, a demo running in a real browser carries a special kind of persuasive weight. Cleo, a former Facebook designer, calls it the “Aura of Inevitability.” When a design concept is no longer a static visual spec but something built in real code that actually runs, it takes on a kind of gravity. In that situation, it becomes very hard for a team to argue about whether to pursue something — because it nearly exists already.

The natural response is: we can probably ship this.

A static file can’t do that. Only a working prototype has that weight.

Return to First Principles ↘

Before AI, most designers had limited real exposure to how software works at a deeper level. We mostly operated at the abstraction layer: visuals, interactions, information architecture. That wasn’t a capability gap — it was a threshold gap. Just getting the design right and the prototype running consumed most of the available energy. There wasn’t room to go deeper.

What AI changed is precisely that ratio. It compressed the cost of “how to build it” to near zero, and in doing so, returned time and cognitive resources to designers. We can now spend more energy on the more fundamental question: what should this thing actually be?

And when you start seriously asking “what is it,” first principles thinking becomes sharp.

This question has two layers.

The first is the core concept of the product — the underlying form in which the software presents itself. TikTok is fundamentally an auto-looping video list. Notion’s core is the block: pages and databases. Cursor’s core is the agent, the editor, and the model. These concepts seem simple. But you can only find the leanest, most flexible connections between features by seeing through to them.

The second layer: once you understand the foundation, you can start to derive what a product should ideally be, growing logic from the inside out, rather than checking off feature lists against competitors, making choices inside someone else’s map.

This kind of understanding gives designers real space to explore what a product can become at its outer limit.

iii. Building Your Own Scaffolding

Every designer hits points where the workflow has friction, where the tools don’t quite fit. The old options were: tolerate it, or throw more manual effort at the problem. Waiting for a new tool to appear was a luxury. Most of the time, you just made do.

Now, designers can bootstrap their own tools — custom scaffolding built around the specific task at hand.

My own example: finding icons used to mean hunting across the web every single time. Classic repetitive drain.

Build a production-ready Icon Library documentation site.
## Tech Stack
React + TypeScript · Tailwind CSS v4 · shadcn/ui
lucide-react for UI · WCAG 2.1 AA · Mobile-first
## Core Features
1. ~100 icons in 8 categories (UI & Nav, Communication,
Media, Commerce, Social, Weather, Dev, Misc)
2. Fuzzy search + multi-select category filter
3. Size selector (12/16/24/40px) + stroke slider (1–3px)
4. Copy SVG / JSX · Download PNG / SVG per icon
5. Light + dark theme (system preference)
6. Guidelines page with specs, accessibility, code examples
## Layout
Sticky header · Sidebar w/ category counts · Control bar
Responsive icon grid (1→2→4 cols) · Footer v1.0.0
## Icon Data Shape
{ id, name, category, tags[], svg (24×24 viewBox) }
## Deliver
Static site · All features working · Clean, typed code
No backend needed · Easy to extend with more icons

I eventually built a dedicated icon library using Figma Make, pulling together open-source icon sets from across the web, with controls for color, weight, and style, and direct export to PNG or SVG. Something that used to happen every time now happened once. It’s the smallest possible unit of scaffolding. But it genuinely eliminated friction from that step.

Ryo Lu, Head of Design at Cursor, did something similar at a larger scale. He mentioned that designers are constantly blocked by complex backend servers and production environments — so he built Baby Cursor for himself: a highly simplified, stripped-down sandbox (miniature environments) that let him validate ideas quickly without those constraints getting in the way.

The reusable principle: when you find a step in your workflow that repeatedly drains energy and is repetitive by nature, that’s the signal to build a tool. Spend the one-time cost to set it up, and everything saved after that is time you can spend on judgment and creation.

This used to require knowing how to code. That barrier is gone.

Writing this, I realize that I’ve been saying the same thing in different ways throughout:

AI hasn’t made designers less important. It’s made the question of who the designer is more important than ever.

Anyone can use the tools. What you build with them depends on who you are.

That’s why this newsletter is called Design to Build.

More Design + AI content coming — follow along ⟡˖

Shortly after the release of Gemini 3, I vibe-built a product: a galactic compass that lets you navigate the solar system. I called it There.

The motivation was deeply personal. I simply wanted to build an arrow that could accurately point to celestial bodies (inspired by Galactic Compass made by Matt Webb). That idea alone already felt romantic enough to me.

On the first day, I spent a few hours putting together a very rough demo, just to verify whether such a spatial mechanism could actually work. Once that foundation was proven, I spent the next few days refining the interface and exploring different approaches — whether to build full planetary models with three.js, or to express them through lighter-weight textures instead.

Another important challenge was figuring out how to combine three-dimensional directional logic with a phone’s gyroscope. No matter how the phone was held or oriented, the arrow needed to remain stable and precise, pointing reliably at the target body without drifting or misalignment.

Subscribe now

In less than a week, There went live. I bought a domain and launched it on Product Hunt. It was the first time I had built and launched a product entirely on my own, end to end. The response was modest but not insignificant. A small group of people found it interesting, even “cool,” but it didn’t break out or go viral — which was entirely expected.

To me, There feels more like a high-fidelity personal tool. Whenever I see the sun or the moon, I open it to check whether the arrow is still pointing correctly. I’ve even considered buying a cheap phone with a gyroscope and keeping the interface permanently on, turning it into a kind of ambient object in my living room.

What struck me most through this process was a simple realization: AI isn’t just about increasing output — that’s not the key point. What matters is that it makes it easier to materialize ideas that used to exist only at the level of feeling, even if the result is something disposable.

Yosuke Ushigome describes this kind of creation as a “perfect back scratcher” — a tool whose curvature fits only the creator’s own body.

Tool democratization ≠ Meaning democratization

When we talk about AI, it’s easy to emphasize the “democratization of technology.” And that’s not wrong.

AI does lower the barrier to making and using tools. It enables more solo builders and one-person companies, allowing individuals to accomplish things that once required teams or specialized backgrounds.

But tool democratization does not equal meaning democratization.

The dominant value narratives and power structures remain largely unchanged. This is why today’s AI products can feel simultaneously diverse and homogeneous: they serve shared, era-specific demands, using newer technologies to achieve goals established long ago in the industrial age — efficiency, productivity, process optimization.

From this perspective, even if the number of AI applications keeps growing, the world itself does not automatically become richer in meaning. It’s diversity repeating itself.

Making Chindōgu

In 1990s, inventor Kenji Kawakami introduced a category of inventions known as Chindōgu — often translated as “unuseless inventions” because they had no commercial value by design.

For Kawakami, Chindōgu were not jokes meant to provoke laughter. Humor was merely a side effect. At their core, they are self-sufficient acts of creation that invite reflection on commercial products.

Yosuke Ushigome argues that one consequence of vibe coding is that more people can become Chindōgu inventors: creating strange, highly personal tools. When AI is no longer used solely to serve markets, but instead to respond to personal interests, confusions, and desires, richness begins to emerge.

Motivations that once had to hide at the very end of the long tail now have a greater chance of being materialized. Not for scale, growth, or monetization — but simply to give a private feeling a place to land, and perhaps attract small circles of like-minded people.

The world isn’t overturned. But its texture becomes slightly richer.

Same Sh*t, Different Year

It’s important to note: richer doesn’t mean better.

AI is a tool for materializing intention. The problem is that human intention is not always clear, nor does it naturally point toward better outcomes. It can be kitschy, superficial, or fall into familiar clichés over and over again.

I’m not interested in assigning any noble purpose to these acts of “creation.” What feels more honest to me is this:

AI increases the complexity of the world, but it doesn’t make it more legible. It doesn’t guide us toward a more beautiful future, nor does it resolve our disagreements about values. The less admirable things remain. Dominant judgment structures remain stable.

But change happens in the gaps.

When individuals can bypass organizations and markets, using widely available tools to pursue deeply personal motivations, meaning begins to branch.

That’s why I have a very concrete wish for 2026: to host a series of gatherings in the Netherlands where people share the things they’ve been tinkering with — not to show off skills or attract investment, but to let meanings intertwine.

I want to call it Chindōgu Party.

Interested in how AI is reshaping interface design?
Join the newsletter for insights, case studies, and the latest experiments.

Subscribe now

To make a large language model (LLM) truly useful, everything begins with context management.

Context is more than a single prompt, it is the entire accumulation of conversation series. Every user input, combined with every AI response, forms the evolving environment in which meaning is created.

In practice, context behaves a lot like memory. Just as human memory is organized, the context of an AI system can also be understood as a layered structure.

Subscribe now

Human memory is often described in three parts:

• Semantic memory: long-term knowledge, concepts, and facts — what I know.

• Working memory: temporary information needed for the current task — what I am processing right now.

• Long-term memory: accumulated experiences, preferences, and patterns — what I tend to do.

AI systems mirror this architecture and its context can also be divided into three layers:

• Library: user-provided materials such as files, webpages, and excerpts.

• Conversation: the active dialogue, grounded in the current topic.

• Memory: accumulated information across sessions, specific to the same user.

Each layer plays a different role, and each demands a different design strategy.

Establish a reliable knowledge base by enabling users to curate and structure their own materials. These resources serve as the system’s fixed semantic assets, grounding the model’s understanding in specific, user-defined contexts.

The value of this layer lies not in storage, but in how external knowledge is constructed and invoked.

Users need explicit, controllable access to these sources. Information must be readable to the model, discoverable to the user, and transparent in its invocation.

Key Feature

• Multimodal parser: Accepts documents, web links, cloud files, and videos. Automatically converts them into structured, indexable content with keywords and metadata.

• Context invoker: Allows users to choose specific sources during a conversation. Context appears as visible chips, making the invocation scope clear and controllable.

Use case

NotebookLM and Flowith both support uploading multi-format files and external links. Flowith further analyzes and categorizes these materials, turning them into content seeds with associated keywords, making retrieval easier.

Most products surrender the entire knowledge base to the AI once it’s uploaded. Users can’t control which part is being used. Tools like YouMind and Notion AI take a different approach: users can manually specify source files via @mentions, and context chips make these references explicit.

Use semantic organization and content extraction to maintain a coherent conversational environment. This keeps the dialogue focused while allowing key ideas to be captured and reused.

The challenge here is managing the vertical sprawl of long chat threads.

Instead of letting conversations stretch endlessly downward, the system should compress and surface meaning, helping users stay anchored in the current topic while carrying important information forward.

Key feature

• Semantic aggregator: Automatically identifies thematic segments in long conversations and presents them in collapsible topic sections, expanding only what’s relevant.

• Content notebook: Allows users to extract AI outputs into an independent workspace for refinement, reducing the friction of scrolling, copying, and tracking.

Use case

Ask LukeW, the assistant on Luke Wroblewski’s website, groups conversations into thematic clusters. Only the active theme is expanded, with others neatly folded away. This preserves spatial clarity and keeps users oriented.

Flowith’s Composer allows users to select AI outputs and send them directly into a dedicated workspace. This bridges the gap between conversation and downstream work, turning chat into a productive workflow rather than a transient thread.

By accumulating and recalling memory across sessions, the system builds a continuous personalized context for interaction, allowing generated responses to better reflect the user’s experiences and preferences.

Memory must balance two goals: personalization and user control.

The system should remember a user’s preferences, routines, and domain knowledge, but must do so transparently, allowing the user to manage what is stored, recalled, or forgotten.

Key feature

• Memory visualization: AI responses display the memory elements they rely on, helping users understand why personalization occurs.

• Memory management: Users can enable or disable memory in each conversation, and view, edit, or block specific stored items.

Prototype

I designed a set of memory controls for ChatGPT to make personalization more visible and negotiable.

Whenever the system draws on a stored memory, it surfaces as a small memory chip in the interface. This makes the moment of personalization explicit rather than hidden in the background.

From there, users can choose to keep, edit, or remove the memory fragment. The goal is not to collect more data, but to let users actively shape how the system remembers them over time.

Context is the king — but how?

If context is king, its power comes from how carefully we design the layers that support it.

Library, conversation, and memory are not separate modules. They are three ways of structuring intelligence. They shape how knowledge is organized, how interaction happens, and how humans and AI come to understand each other over time.

Context is not just the background of interaction. It is the structure that allows meaning to emerge at all.

📖 Further reading

• Effective context engineering for AI agents — Anthropic

• Context Management UI in AI Products — Luke Wroblewski

• More on Context Management in AI Products — Luke Wroblewski

One of the most persistent problems in AI products today is this: people still aren’t sure what these systems are capable of, or how to get the best out of them.

This is because most AI tools still greet users with a single blank box and a placeholder as vague as it is open-ended: “Ask anything.”

The result? Without clear guidance, users start crafting prompts in haste, iterate through endless revisions, lose control of the flow, and gradually pollute the context with fragmented instructions.

To improve the quality of AI output, clarity must start at the very beginning — in the way we express intent. A good prompt isn’t just a line of text, it’s the source code of collaboration.

That’s why we need prompt-building interfaces that are designed not merely to receive instructions, but to shape them. They help users understand the product’s potential while progressively clarifying their own goals through interaction.

This article looks at how we can design such interfaces through real examples and prototyping. From those explorations, I’ve distilled three design strategies that shape an effective prompt-building experience:

1. Guide — enable users to start the conversation and express intent clearly.

2. Constrain — set meaningful boundaries to narrow focus and maintain coherence.

3. Structure — provide a compositional logic that organizes dialogue and outcome.

Turn the qualities of a good prompt into measurable, actionable criteria, and let AI use those criteria to refine the user’s expression.

Across the industry, there’s now a rough consensus on what makes a good prompt. Anthropic, for instance, recommends using XML tags to structure prompts — breaking them down into roles, tasks, constraints, and examples as modular components.

You’re a financial analyst at AcmeCorp. Generate a Q2 financial report for our investors.

AcmeCorp is a B2B SaaS company. Our investors value transparency and actionable insights.

Use this data for your report:<data>{{SPREADSHEET_DATA}}</data>

<instructions>
1. Include sections: Revenue Growth, Profit Margins, Cash Flow.
2. Highlight strengths and areas for improvement.
</instructions>

Make your tone concise and professional. Follow this structure:
<formatting_example>{{Q1_REPORT}}</formatting_example>

While this format may feel intimidating for most users, it reveals something important:

the attributes of a good prompt are not mystical; they can be analyzed, formalized, and embedded directly into the product itself.

Guide means leveraging AI to help users refine natural and unstructured input into expressions that are clear, consistent, and reproducible.

Feature

• Evaluator: Reviews the prompt, rates its quality, and highlights areas for improvement.

• Enhancer: Offers several optimized rewrites, allowing one-click reconstruction with highlighted differences.

Example

Elicit is one of the few products that combine both evaluation and enhancement of prompt.

It assesses the quality of a user’s research question and dynamically proposes refinement paths, such as defining methods or narrowing focus areas. This makes it particularly suitable for academic research.

Monica AI, by contrast, offers a simple one-click optimization. It is simple and accessible but lacks multiple refinement options, focusing instead on convenience and speed.

Prototype

I explored how prompt guiding could offer richer options while giving users greater control. The focus was to understand how design can mediate the balance between the generative freedom of AI and the editorial control of users.

Define the informational scope to create clear boundaries for interaction, ensuring that the generated results remain focused and controllable.

Constrain addresses the question of how to clarify the topic and the limits of discussion. The key is to introduce contextual constraints that keep the model operating within a defined set of materials, time periods, or domains.

By limiting AI’s visible scope, it prevents drift and vagueness, resulting in outputs that are more focused and reliable.

Feature

• Boundary filter: For tasks involving web search or information retrieval, the system can dynamically generate filters aligned with the user’s query, such as time range, source type, or domain category. This allows users to deliberately define the boundaries of the response.

Example

Consensus provides global filtering capabilities that let users specify parameters like publication year, research method, knowledge domain, or geographic region at the prompt stage.

This ensures that the model’s reasoning remains grounded within a well-defined and transparent scope.

Similarly, Scite includes assistant settings where users can define academic parameters before starting the query. It suggests that scientific research tools tend to offer more control upfront.

Booking.com introduces smart filters that use AI to interpret user intent and automatically activate the most relevant filters.

Based on the user’s goal, surface key parameters and dimensions at the outset to turn unstructured requests into a flexible structural framework.

When generating with AI, every form of content carries a set of embedded decisions that directly shape the outcome.

For example:

1. 🖼️ Image generation: deciding on the aspect ratio, composition, and visual style.

2. 💬 Translation: defining the source and target languages, and sometimes the tone of equivalence.

3. ✍️ Writing: specifying the length, tone, and intended purpose of the text.

Structure helps identify these decisions in advance and exposes them during input. This form of pre-structured guidance reduces unnecessary iteration and produces results that better match user expectations.

Feature

• Structure Generator: Once the user selects a task, the system identifies its key contextual factors and presents a configurable prompt structure, using selectable fields or options to guide input.

Example

Luke Wroblewski demonstrated an interesting “Lego-style” prompting example in Bench, where choosing the task type, tool channel, and output format automatically builds a structured prompt.

When you choose different content types in Monica AI, the system displays distinct prompt-extension interfaces, each offering relevant preset parameters.

Similar approaches have been widely explored in Chinese AI products at the application layer.

Prototype

Using image generation as a use case, I designed an advanced image generator that extends the chat interface into a configurator.

It lets users fine-tune parameters while composing prompts, producing results that are more precise and aligned with intent.

For AI products, prompt engineering is as essential as sign-up or onboarding, because it marks the start of collaboration.

Unlike traditional interfaces where intent emerges along the way, AI requires users to express it clearly and structurally from the very beginning.

The design task then lies in bridging the transition from user intention to clear articulation. And this is the very purpose of prompt-building interfaces.

It means giving form to intention, setting boundaries for meaning, and composing structures that allow intelligence to respond.

In doing so, we are not just building interfaces, but cultivating a shared language between human intent and machine interpretation.

In 1989, Alan Kay published User Interface: A Personal View, building on Marshall McLuhan’s idea that “the medium is the message.” A medium doesn’t just carry information, it reshapes how we think. To make sense of it, we first internalize the medium.

An interface, then, is a cognitive framework.

Today, AI interfaces are shifting fast: from chat to voice, from canvases to agent-driven cross-tool spaces. As models converge in capability, the real differentiation has moved to the interface layer. The interface is no longer just a channel. It is the key that unlocks technology, translating complexity into affordances and shaping the flow of human attention.

Subscribe now

The Collapse of Interaction

Before large language models, our typical path to finding answers online looked something like this: break your question down into keywords (like pizza, recipe, tutorial) and feed them to a search engine.

Then you wade through a long list of results, browsing page by page, clicking on a few promising links to read carefully, and finally mentally stitching those fragments together into your own version of the answer.

In contrast, with conversational AI products, I simply say: “Give me the perfect pizza recipe and instructions,” and the AI immediately serves up a curated answer. If it’s not quite right, I add a couple more sentences, the AI continues to refine or rewrite, and soon I’ve iterated to a final answer.

So with AI’s intervention, we can see two major shifts in product interaction paradigms:

From Command-Based to Intent-Based

Traditional interfaces relied on a turn-taking loop: input → output → user judgment → next command. Now, instead of issuing step-by-step instructions, the user states the goal, and the system handles the process behind the scenes.

From Process-Driven to Outcome-Driven

Interaction used to feel like a visible journey, where users accumulated knowledge and built judgment along the way. Today, much of that process is folded into the backend. Interaction becomes a cycle of prompting and refining around the result itself. The user’s main task is to evaluate the output, while the system dynamically connects the dots based on intent.

The Unmoored Chat Box

Interestingly, most AI products have converged on the same choice: a chat box. The reason is obvious — chat feels natural, with virtually zero learning curve. Prompts unfold as back-and-forth conversation, offering high interactivity, tolerance for errors, low barriers to entry, and almost unlimited flexibility. It’s the perfect vehicle for mass adoption.

This is why Sam Altman wants to build ChatGPT into a Personal Life OS. In that value narrative, the experiential intuitiveness and multimodal extensibility of conversational interaction is the solution for vast life scenarios.

But there’s another, less visible factor: LLMs are inherently squishy. The same intent, placed in slightly different contexts, can produce different results. Therefore, ensuring that a setting always corresponds to stable, reproducible effects is a thankless task.

As a result, AI products often bury parameters deep in the system instead of exposing them as explicit controls.

Take ChatGPT as an example. Beyond plain text, it can also produce tables, images, charts, code snippets, videos, and content cards.

One way to unlock these formats is to be explicit in the prompt — say, asking the AI to present the answer as a flowchart. But this puts the burden back on the user, who now has to master structured prompting and understand how content should align with different formats.

The second is to let the AI decide, having the system choose the appropriate presentation based on the generated content’s characteristics. This points to a major trend in future interfaces — Generative UI.

In this model, AI doesn’t just generate content, it simultaneously decides and renders the most fitting presentation container, truly merging output with interface for genuine personalization.

But before Generative UI becomes reality, the chat box stays out of control.

Category Error

Dave Edwards, founder of Artificiality, offered a thought-provoking metaphor that most digital products fall into one of two categories:

• Windows: they connect users to external information and resources — think Tripadvisor, Airbnb, or Spotify.

• Rooms: they provide spaces for work, collaboration, and creation — tools like Figma, Photoshop, or PowerPoint.

If we map AI users along a proficiency spectrum: there are beginners, intermediate users, and power users.

Conversational interfaces naturally cater to the first two groups. They brand the system as a “no learning required” product. Perfect for newcomers, right? But for power users, the chat box strips away control panels and leaves only an open-ended input field.

Analyze this software licensing agreement for legal risks and liabilities.

We’re a multinational enterprise considering this agreement for our core data infrastructure.

<agreement>
{{CONTRACT}}</agreement>

This is our standard contract for reference:
<standard_contract>{{STANDARD_CONTRACT}}</standard_contract>

<instructions>
1. Analyze these clauses:
- Indemnification
- Limitation of liability
- IP ownership

2. Note unusual or concerning terms.

3. Compare to our standard contract.

4. Summarize findings in <findings> tags.

5. List actionable recommendations in <recommendations> tags.</instructions>

That’s why you’ll see one user writing a 300-word structured prompt with XML tags, while another asks “How many shapes of McNuggets are there?”

The problem is that many AI products are designed as “windows” with a clean input box that seems able to carry any conversation. But in terms of technical capability, they’re absolutely “rooms” capable of supporting deep creation.

And here lies the category error: users with complex needs require explicit functions and sufficient control, yet find themselves trapped in a “window.”

So people improvise:
They buy prompt templates.
They use Raycast to manage and trigger them.
They spin up endless new chats every day.
They save outputs into notes — then bring them back into the chat again.

The intelligence isn’t limited, the interface is what cages it.

As AI systems mature, the real question is not simply which interface will dominate, but how we will negotiate agency between human and machine. That balance between outcome and process, freedom and control will define the next era of design.