As a designer, I am optimistic about this one, and that is not my usual reflex with AI interface design.

You have probably never heard of it. That is fine, almost no designer has. A2UI still lives in developer corners, written about in code. The idea underneath is worth meeting early, though, because it changes what we do.

So let me start with the idea, not the acronym.

Think about how we design today. One screen, or one flow, aimed at an imagined researched user. Everyone who arrives gets more or less the same thing, and we hope it fits.

Now picture that flipping. The interface is built fresh in the moment, for the exact person or the exact thing they asked for. I do not open my banking app and hunt through menus and dashboards built for everyone. I ask where my money went this month, and I get back just that: a simple chart by category, with the one surprise expense already flagged. You ask, the screen you need appears, then makes way for the next one.

This is a new approach, called Generative UI or radically adaptive UI. It is early. The spec is young, most of what exists is still demos, and there is no solid pipeline from design to code yet. But it is already running in a few real products, and it is moving fast enough to be worth your attention.

A2UI is one of the things that makes it work. It is not a tool or an app you install or buy. It is a protocol, a shared language sitting between an AI and your interface. So when you “use A2UI,” you are not opening it, you are building your app to speak it. Google started it and put it out in the open, with CopilotKit and others now shaping the spec. It sits alongside related protocols like A2A and AG-UI, but no more jargon, let's look at what this is and what it means for us.

It is not the only one. There are others, like json-render by Vercel and MCP-UI and surely many more. But I am focusing on A2UI as an example.

Why am I optimistic

It moves us away from generically generated AI interfaces. The kind built from div soup and more classes than you ever sat through at school. No offence to Tailwind, it is clever and I reach for it constantly when I am exploring. It just should not be the standard for the web we put into the world. You are welcome to disagree.

The reason is simple: an approach like A2UI only ever builds from a given catalogue of elements. Elements a designer made first, implemented in clean code, with solid CSS, the edge cases handled and accessibility looked after.

Built the way things are supposed to be built. The interface is then assembled fresh for each request, which is the radically adaptive part.

This is not only a UI but also a huge UX shift, because the pre-built persona we usually design for, this made-up average user, quietly changes in this scenario.

What we get instead is better: an interface that fits the actual moment.

This is our new homework as designers

To design for this, we need to understand how it works. Not in deep technical detail. Just the way we already understand what a component is, how a variable becomes a token, and how to name that token so it lines up with code.

It is not fully here yet. It is moving, and right now, it is mostly developers building and deciding how it works. So let us demystify it and take the seat that is ours. The official A2UI diagram is a stream of JSONL messages, which I suspect just lost most designers in the room. Let us turn it into something our visual heads can hold.

First: What the user actually experiences

Let us make up an example. We run a hotel chain across the US, and we add an AI-driven interface for our users. Here it shows up as a reply in a chat, but the same screen could just as easily be the whole app, or a panel beside it.

User experience today (June 2026)

You get either a fixed page or a chatbot, and you tell it you want a hotel in New York in March. It asks for the exact dates, and you type them. It asks how many people. Then check-in, then check-out, one question at a time. If you have ever booked a flight over the phone while trying to compare prices, you already feel the pain in your shoulders.

User experience with radically adaptive UI like A2UI

You say, “I want a room in New York in March,” and it shows you the interface you need. For example, a calendar for the dates, prices visible in case you are flexible. A stepper for the guests. If you had asked what hotels are available instead, it would show a list with photos and prices.

For the user it is simply this: I ask, and I get exactly the screen I need. Nothing else.

The interesting question is what happens between the asking and the screen, and where we step in, for us designing this experience:

There is a great little demo tool by Southleft to play with for a first experience. This is all brand-new stuff, but you get the gist.

How it works under the hood

Two parts do the work, with off-putting names. Let me make them plain.

• One part decides what screen you need and writes the recipe for it. It sits on a server, out of sight. The docs call it the agent.
• The other part is the app in your hand. It takes that recipe and builds the real screen from your components. The docs call it the renderer.

The recipe is just the agent’s instructions for one screen: which of your components to use, and how to arrange them. Written fresh every time you ask for something. And it can only name components that already exist in your system, which is exactly where we come in.

Ok so how does that work step by step?

This is what we get on the official A2UI page. Lovely if you are an engineer, scary for designers.

Let’s make it designer-friendly, shall we? Here we go:

Let’s run through it step by step.

Step 1. You ask

The user types or says a plain request: “I want a room in New York in March.”

Step 2. The agent receives it

A small program on a server (often Python, using the A2UI Agent SDK). It bundles the request together with your catalog and instructions, and passes that to an AI model.

Step 3: The model writes the recipe

An LLM (as this A2UI is Google, this would be Gemini, but it would work the same for others) returns a structured description of the screen needed: A2UI messages, streamed line by line as JSONL. This is what some call the “recipe”.

A simplified contract for our request could look like this:

{ "version": "v0.9",
  "createSurface": { "surfaceId": "hotel-booking",
    "catalogId": "https://moonhotels.com/catalog/v1/catalog.json" } }

{ "version": "v0.9",
  "updateComponents": { "surfaceId": "hotel-booking", "components": [
    { "id": "root",   "component": "Column", "children": ["title","dates","guests","search"] },
    { "id": "title",  "component": "Text", "text": "Find your room in New York", "variant": "h1" },
    { "id": "dates",  "component": "DateRangePicker", "value": { "path": "/booking/dates" } },
    { "id": "guests", "component": "Stepper", "label": "Guests", "value": { "path": "/booking/guests" } },
    { "id": "search", "component": "Button", "variant": "primary",
      "action": { "event": { "name": "search_hotels" } } }
  ] } }

You do not need to read JSON fluently to see it. Each line names an existing element or component (a Column, a Text heading, a DateRangePicker, a Stepper, a Button) and a few properties. A parts list with an arrangement.

Here is the bit that should make a designer sit up. The model can only name components that exist in the catalog.

It does not invent a date picker, and it does not generate a random one-off widget. A2UI checks the recipe against the catalog before it is sent and catches any property the model tried to make up. The app checks it again on arrival. No more generic…well, you name it.

So “it cannot invent” is not a hopeful promise. The agent generates, a validator checks it against your catalog, and it self-corrects before anything reaches the screen.

That constraint is the whole point, because it hands the next step entirely to us.

Step 4. The app renders it using the catalog

The renderer, the user’s app on web, mobile or desktop, reads the recipe and builds the real screen from your catalog and your catalog only!

The intelligence decides what to show. Your design system decides what it looks like and how well it works.

Where design comes in

Everywhere that matters! And this is the stuff that excites me after years of generative AI designs running wild in design:

The entire catalog is design decisions. Not a generative free-for-all. Real design thinking, made readable to a machine.

Does the catalog hold styles and tokens, or only components?

Both. The A2UI catalog is defined as the components the agent may use, the functions it may call, and the styles and themes that go with them, plus instructions for using all of it. Your theming and tokens live here too, not just your buttons.

And the components are not only tiny primitives. The catalog can hold a plain Button and Text, but it can just as easily hold a HotelSelector or a FlightCard, a rich, branded component you designed for exactly this product.

You are not handing the machine a box of Lego bricks. You can hand it whole pre-built rooms.

Catalog versus design system

Not the same thing, and the difference is clarifying.

Your design system is the broad human thing: the Figma library, the coded components, the tokens, the docs, the taste behind all of it.

The catalog is the slice you expose to the agent, in a format it can read. The menu it is allowed to order from. The official guidance is to build it to mirror your design system, so the agent is held to your exact components and visual language.

One idea, three layers: the system you think in, the contract you expose, the code that runs.

Where it breaks

Here is the honest part: because the constraint that protects you is also the ceiling. The agent can only name what is in the catalog. So when someone asks for a moment you never designed for, it cannot invent its way out. It does the next best thing, and “next best” is exactly the problem. It reaches for the closest component you did build, even when that is a poor fit. It falls back to the plain, basic set that ships with A2UI, the generic look the whole approach was meant to kill. Or it gives up on a screen entirely and drops back to chat.

And note what the validator does and does not catch. It catches an invented widget or a made-up property. It does not catch bad taste.

A list where a map would have been kinder, a stepper where a calendar was the point, a screen that is technically valid and still wrong. Nothing in the pipeline flags that. The only thing standing between the user and a near-miss interface is whether the catalog had the right piece in it.

So the failure mode is not a crash. It is a quiet downgrade, and it lands on us. Every gap in the catalog is a gap the user feels. That is not an argument against A2UI, it is the clearest possible argument for the job: the screens are only ever as good as what a designer put in the catalog to begin with.

Why this is huge

For years, the careful work, the naming, the states, the tokens, the accessibility, felt like a tax. Worthy, invisible, first to be cut when the time and budget were pressing. Here, that same work becomes the engine. The catalog is the only thing the agent can build from, so the quality of every screen a user ever sees is set by what a designer put in it. Not by a developer interpreting a mockup later. By us designers, upstream, on purpose, into each little element and component.

That is more control over the final outcome than designers have ever really had.

It only works if there is something worth assembling in the first place. Making sure of that is the job.

So what prepare as Designers?

You do not need to learn to write a catalog in JSON. You need to become the person who makes a catalog worth writing.

Whatever an agent reads, we own. In A2UI it is the catalog. In another setup it will carry another name. The label changes, the responsibility does not. The machine builds from a source, and a designer defines the source.

For now, that source still starts in Figma. I do not care what you say: if you do solid design, you need a canvas to think on, otherwise you get the generic stuff I see everywhere (feel free to surprise me). Today, that canvas is Figma.

Here is the part to understand, because it looks like a flaw and it is not. Figma expresses only about a third of CSS cleanly, and that number is not a bug. It covers the third, which is visual and static: layout, type, colour, spacing, and components. The rest of CSS is behaviour, logic and runtime. Focus states, container queries, selectors, interaction, the things that only exist once the page is live and a person is moving through it. So what we hand over is partial by nature, not by failure but that still means it is not ideal.

However, the “then just do not use Figma” is the wrong move in my opinion. You can generate stuff, but if you care about the creative process, you need a tool made for design, not a terminal. The gap is a reason to know Figma’s edges, not to walk away from the canvas. No other tool is built for this either currently, and cramming all of CSS into Figma is not the fix. Designers are already drowning. I spend half my life teaching teams auto layout and props, so trust me, drowning.

So, concretely, the work for designers is two things.

1. Build clean, solid, structured files, the kind that can be read by an agent, can also become a catalog easier in the future: every state designed, semantic tokens that carry intent, names treated as a contract, and a real grip on components, variants, props, and slots, adding context to travel with components, all the features, you now need to know them inside out.
2. Then know the gaps. Know where Figma stops and where you need a translation layer or simply a human has to step in, because no tool closes that gap for you today. The catalog like any other agentic design setup today still lives as hand-authored code, just past Figma’s edge, and nobody has built the clean bridge from one side to the other (yet).

So be very critical of anyone who tells you they have a smooth design (real design) to (real) code workflow with AI. Work with agents, absolutely, but make sure the human supervises. The person stays in the seam, on purpose.

Because here is the core of it. Design is thought on a canvas, with your hands, fast and visual, because that is the only way anything but generic comes out. The machine needs the opposite: a precise, structured, machine-readable source. Good design needs the canvas. The agent needs the system. And nothing today carries you from one to the other without losing something on the way. That gap is not a bug waiting for a patch. It is the shape of the problem, and for now, only a person can cross it.

The tool that finally lets a designer think on a canvas or similar creative environment and hand a machine clean-coded elements will decide how everything gets made. I have my fingers crossed for Config 2026.

Who is Christine Vallaure, the author

Christine Vallaure. UI designer, speaker, founder of the learning platform moonlearning.io and author of theSolo, a book about independent product building. I teach UI design, Figma, and product to the people who want to understand what is actually going on under the hood.

Online courses, team training, conference talks. If any of that is useful to you, come find me.

Currently focusing on course on agentic AI for designers. Sign to my newsletter if you want to know more.

Constitutionally incapable of writing a short article.

LinkedIn

A2UI under the hood: Designing for the new era of radically adaptive UI was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

I watched a demo recently that I keep thinking about. Brad Frost, who wrote Atomic Design, joined Dominic Nguyen, co-founder of Chromatic, for a live session called Agentic Design Systems in 2026. Kyle, a developer experience engineer from the Storybook team, was running it, showcasing their MCP-in-the-making.

I will be honest with you, as a designer and educator, I watch those kinds of demos out of duty to stay up to date, with the quiet knowledge that I am a tourist in someone else’s world. But this one stopped me.

Kyle typed a prompt: “Add a customer reviews component.” No reviews component existed. No design file, no ticket, no Figma frame to point at. The agent found a Star component, Typography, and an Avatar. Read their props, understood their states, composed something new, wrote the code, wrote the tests. The whole thing took less time than it would have taken to write the Jira ticket. The demo was aimed at developers. Watching as a designer, I had a completely different reaction.

The design system is no longer just documentation for developers. It is instructions for a machine.

And the person who decides what components exist, what states they have, what they are called and why, is a designer.

That is not a threat. That is actually the most creative control designers have ever had over what gets built. What Storybook showed was not AI doing design. It was AI that finally knew to use what the designer already built. This is the opposite of vibe coding (no offence, but thanks god!). The agent is not inventing; it is following.

They had me at “assembling, not creating.”

Now, here is the thing: none of what makes this work is new. Semantic tokens, consistent naming, and complete component states.

Design systems people have been preaching this for years. Most of us listened politely and then got back to the actual work, simply because it felt like advice for enterprise giants and complete overengineering for an understaffed team of three trying to ship something by Friday.

The difference now is who is on the other end. Before, a poorly structured design meant a developer had to interpret your intentions. Annoying, but recoverable, and the back and forth occasionally produced something better than either of you planned.

Now the consumer is sometimes a machine and it reads exactly what is there. The design system basics we were always told to get right in Figma are now the foundation for an agentic setup where designers could have more power than ever over the creative outcome, if steered correctly.

Here is why, and what needs to change in your Figma file and process to get there.

Good News: Figma Is Not Dead. Bad News: Your Process will change (but in the best way)

In case someone on LinkedIn with a Lovable playbook written in Canva told you otherwise, you can verify here: isfigmadead.com. Still alive, amazing, let’s carry on.

What actually changes in an agentic setup is structure and where you put your energy. Less time on the full-page mockup that gets looked at once in a handoff meeting, more time on the building blocks. The components, the tokens, the states. Very much a return to Brad Frost’s atoms (who must have felt genuinely delighted watching his life’s work become the infrastructure for an AI workflow).

But here is the part I feel strongly about, and I do not think it gets said enough:

A) The deliverables
The agent builds from the building blocks: components, tokens, styles, and the descriptions you write for all of them. Nothing new, just the good old design system basics done properly.

B) The process to solid deliverables
Good building blocks do not come from a component library maintained in isolation. They come from a designer who saw the whole thing first. I cannot extract a good Star component without having designed a page where the Star had to work, where I saw how it related to the typography around it, how it felt in context, and what it communicated.

The design system is a distilled finding. Designing the whole page is where the finding happened and hence not redundant.

This is not a small distinction. If we treat the library as the starting point rather than the outcome of a creative process, we end up with something structurally correct and visually indistinct, optimised for assembly. This is what we've lately seen with Tailwind-based designs, and is the reason most vibe-coded interfaces look so generic. Fast to build, consistent, entirely interchangeable. Perfectly fine for shipping quickly, I use Tailwind a lot for exploration. Not fine if you want a visual language that is actually yours. Different things entirely!

The agentic AI setup will pull towards efficiency.

Towards the library of things, we colour in quickly. That is the natural gravity of a system built for assembly. The designer’s job is to ensure there is something worth assembling in the first place, and to help stakeholders understand why that work is not a luxury.

The creative process is not overhead. It is messy, non-linear, and impossible to automate. The depth of that mess is exactly what makes the distillation we feed the machine worth anything.

Cut it, and you have a fast system producing forgettable output, which costs more in the long run than the time you thought you were saving.

The page serves as a designer’s proof of concept. The components you extract from it are the actual work. But you have to make the page first. Really make it. Not as a deliverable. As thinking.

Quick word on MCP.

MCP stands for Model Context Protocol. It’s a standardised way for an AI agent to connect to a tool and read information from it. Figma has one. Storybook has one. You don’t set this up as a designer. But the more you understand what it reads from your file, the more intentional you can be about how you structure it.

The File Setup Reminder

Right. Now that we have defended the creative soul of design, let us rain a bit on our own parade and talk about naming conventions.

Think of this as a checklist for your file. Not all of it needs to happen at once, and you will need to adjust to your own team's situation and requirements. But each item is a gap the agent will fill with guesswork if you leave it so it is worth already preparing designs with this in mind, a little more carefully, for the future.

Before we get into the file, where do you even start if your current file is none of this?
Don’t panic, breathe and pick one component. Your most-used one, and make it right. Proper naming, all states, token-based spacing, and semantic layer names. Then do the next one. A system that improves gradually beats one that gets rebuilt from scratch and abandoned.

1. Your Variables need more than a colour palette.

Most designers who have set up Figma Variables have a flat list of named hex values. That is primitives only, and it is only the beginning.

Primitives are your raw values.
blue/500 = #3B8BD4. Your colour palette, your spacing scale, your type sizes. Set these once and never apply them directly to a component. In Figma, hide them from the properties panel via the collection settings so nobody accidentally uses them. They remain available for your semantic tokens to reference. Technically, you can skip this layer if your system is very small and stable. What matters is what comes next.

Semantic tokens describe intent, not appearance. color/interactive/default. color/interactive/hover. color/interactive/disabled. This is the layer an agent reads to understand what a colour means rather than what it is. If your brand blue changes to teal tomorrow, the semantic token still says "interactive default" and nothing downstream breaks. This is the non-negotiable layer. Without it, the agent guesses, usually wrong in ways that are hard to spot until something ships.

Component tokens are optional.
button/background/default referencing color/interactive/default. Worth it for complex systems or multi-brand work. Skip them if you are just getting started.

How many collections you have does not matter. What matters is that the semantic layer exists and carries clear intent.

One thing to know about naming. In Figma Variables, you use forward slashes: color/interactive/default. In code the convention is typically dots: color.interactive.default. Same intent, different syntax, and the names get transformed as tokens travel through a pipeline. Agree on the semantic structure with your developer before you build anything. Naming is genuinely one of the hardest problems in a design system, so do not expect this to be a quick coffee chat. Retrofitting it later is exactly as painful as it sounds.

2. Match your component properties to code props. Exactly.

In Figma, you have four types of component properties. Each one maps directly to a prop in code.

The problem is when the names do not match. If your Figma button has a property called “Style” with values “Filled” and “Outlined”, but the code component has a prop called variant with values primary and secondary, nothing maps cleanly. Code Connect cannot link them and the agent guesses.

The fix is one conversation before you build anything. Agree on property names and values with your developer. Use them on both sides. Same capitalisation, same spelling. It sounds trivial. The rework it prevents is not.

Component names must be in PascalCase and match the code component name exactly. Not “Card — Product” or “product card (new)” or “Product Card v2 FINAL”. ProductCard. One character difference and the automated mapping fails.

Add descriptions to your components. Figma lets you add a description to every component and the Figma MCP reads them and passes them to the agent as context. “Five-point star used for ratings. Supports filled, empty, and half states. Interactive by default.” gives the agent vastly more to work with than a component with no description. This is a small thing that makes a significant difference.

A personal note from teaching this. Do not try to set up all four property types at once if this is new territory. I have watched teams freeze at this point and build nothing. Start with variants. They are visual, familiar, and cover most of what you need. The rest comes later, when you hit the specific problem it solves. A small system your team actually uses beats a complete one nobody touches. And for an agent, a clean, small system is far more readable than a large, messy one.

3. Design every state. Every single one.

Hover, focus, active, disabled, error, empty, loading, skeleton.

If you have not worked with Storybook, a story is the code equivalent of a variant on your Figma canvas. One state, rendered live in a browser, with its props defined. A Button might have a Primary story, a Disabled story, a Loading story. Exactly like your Figma variants, except alive and testable. That is what the Storybook MCP reads. Your Figma file gives the agent design context. The stories give it a behavioural context. Both matter.

If your Star component only has a default story, the agent thinks that is the only state it has. It will compose a rating box that cannot be interacted with, cannot show empty, cannot show an error. Not because the agent is bad at its job. Because you did not tell it those states exist.

Which property for which state:

Variants for states that change visual appearance. Default, hover, focus, disabled, error. Each variant becomes its own story. One variant, one story.

Booleans for things simply on or off. Has icon, show label. Booleans only control layer visibility in Figma. If the icon changes the button padding, that is a variant.

Instance swap for slotted elements. The icon inside a button, the avatar inside a card. Swap without detaching.

The multidimensional problem. Three sizes, three variants, three states, optional icon. That is 54 combinations as a full variant set. Nobody builds that. Use variants for the dimensions that change visually, booleans for the optional parts. Your developer is making the same compromise.

The gap Figma does not warn you about. Figma allows gaps in your variant matrix. Code does not. Agree on which combinations are real before you build and document the ones that are not.

A note for developers, from the bottom of my heart.
Sit down with the design team before anything is built. Props are the single most confusing thing for designers, right after auto layout. What is obvious to you is genuinely disorienting to us. The reverse is also true: ask a designer to cut their type scale and prepare to hear about visual hierarchy, reading rhythm, and at least one Swiss typographer. We are all experts in our own foreign language. Agree on prop names before anyone opens Figma or writes a line of code. Twenty uncomfortable minutes, weeks saved.

4. Slots. Brand new. Already essential.

Figma shipped slots in open beta on 5 March 2026.

A slot is a defined drop zone inside a component. A card where you can swap the image, the title, the footer button, without detaching. Detaching is what happens when a component does not do what you need so you break it open and edit it directly. It feels like a win in the moment. It is a maintenance disaster forever, because the component is now disconnected from the design system and nobody, including the agent, can reason about its structure.

Slots give you the flexibility without the chaos. In Figma, a slot appears as a pink-bordered area inside a component instance. General slots are open areas for any content. Named slots are specific drop zones: a header area, a footer area, a leading visual. You can have both in the same component.

In code this has always existed:

<ReviewCard>
  <Avatar />        // dropped into the leading slot
  <StarRating />    // dropped into the rating slot
  <ReviewText />    // dropped into the body slot
</ReviewCard>

The card holds the layout. What goes inside is whoever uses it’s responsibility. A component with named slots tells an agent exactly what goes where. A detached frame with “Frame 247” in the layers tells it nothing.

For a proper deep dive, Nathan Curtis wrote the definitive piece on slots in design systems. Worth bookmarking.

5. Use auto layout properly. Every component.

Auto layout is not just a layout convenience. The Figma MCP reads it and converts it directly to CSS. Horizontal and vertical auto layout maps to Flexbox (approximately). The newer Grid mode, introduced at Config 2025, maps to CSS Grid (also a bit more sort of). Understanding what those mean for you as a designer is worth your time, and if you are up for one more long articles, I wrote a guide on exactly that: Figma’s new grid, you must understand CSS Grid as a designer.

A frame with auto layout and token-based spacing is a description. A frame with manually placed elements and hardcoded values is a picture.

Spacing in variables. Every gap and padding should reference a spacing token and hence be stored in variables. For most systems, your primitive spacing scale is enough: space/4 = 16px applied directly to a gap is already meaningful and consistent. Semantic spacing layer names like space/component/padding-x are worth adding when your system is large enough to need that level of control.

Sizing should be intentional. fill, hug, or fixed. Never left on whatever Figma defaulted to when you dragged a frame onto the canvas.

Layer names matter too. The Figma MCP reads layer names to understand what it is working with. CardContainer, ProductImage, CTA_Button tell the agent something. Frame 247 and Rectangle 3 tell it nothing. Name every layer that corresponds to a structural element semantically. Figma has an AI rename feature in the actions panel worth trying. I have not tested it thoroughly enough to fully vouch for it, but worth a go, seemed pretty solid.

And your page structure matters. Name your Figma pages so the file is navigable by someone who has never opened it, because that someone is increasingly an agent. “Page 1”, “New Page”, and “Copy of Exploration” are not page names. They are evidence of a deadline.

6. Code Connect. You need it, but you don’t need to master it.

You do not set this up yourself but you need to know it exists because without it, everything in this file setup only goes halfway.

Code Connect is the explicit mapping between your Figma component and its code counterpart. It is not specific to Storybook. Any agent reading your design system through the Figma MCP needs it to understand which Figma component corresponds to which component in your codebase. Without it, the agent knows your Button exists in Figma but has no idea it is the same Button your developers already built. It generates a new one from scratch every single time. Figma’s own documentation puts it plainly: Code Connect is the number one way to get consistent component reuse in code. Without it, the model is guessing.

It only works cleanly if your Figma component names and property names match the code exactly. Which is why everything in sections 1 through 5 matters. The file setup is the foundation. Code Connect is what connects it to the machine.

Note: What the file setup doesn’t solve yet.

Variables travel cleanly to code, Styles don’t. Your typography style holds all the right values, bound to the right variables, but there is no automatic CSS class on the other side. That mapping is a naming convention between you and your developer, not a technical link. Code Connect does not cover it if you haven’t explicitly agreed that heading/xl in Figma equals .heading-xl in CSS. Same problem with gradients and effects. The variable layer is solid but the style itself has no automatic counterpart in code. Tools like Tokens Studio and Style Dictionary exist to help close that gap, transforming your tokens into CSS classes automatically, but the pipeline still needs setting up.

These are early days and the tooling will catch up for sure. A clean file means you are ready when it does. The naming, the states, the tokens, the auto layout, all of it still makes the agent dramatically more accurate.

Just don’t mistake a clean file for a complete pipeline yet.

A note for anyone who has ever had to justify design system investment.

For years, making the case for a well-structured design system was frustratingly hard. The value was real but diffuse. That is changing now for sure, as agent performance is a measurable signal. A well-structured system produces faster, cheaper, more accurate output. A poorly structured one produces guesswork that costs more to fix than it saved to generate. . The session covers this directly around the 1:01 mark: Storybook is already benchmarking with real metrics, speed, token cost, and code conformity.

For the first time, design system quality will have a number attached to it.

But the metrics only remain strong if the upstream creative work is protected. The agent works from a vocabulary a designer built. The richer the vocabulary, the better everything the agent touches. This is not an argument against efficiency. It is an argument for investing in what makes efficiency worth having.

Where we actually are.

The full loop is real and it works. Uber published a detailed account this month of using AI agents and the open source Figma Console MCP (if you don’t know it, check it out, such good work!) by TJ Pitre from Southleft to generate complete component specs in minutes instead of weeks. Different angle to the Storybook demo, same underlying argument: the better your design system is structured, the more an agent can do with it. At that scale, it makes total sense. For most teams? There is still a long way to go.

The open questions.

Where does visual truth live? Once an agent composes a new component, where does it go? Who sees it before it ships? Tests tell you if it works. They do not tell you if it looks right, feels like the brand, or holds up next to everything else on the page. The loop closes for developers when tests pass. It does not close for designers at all. That workflow gap is real and unresolved.

How does a designer communicate visual intent to a machine? Component descriptions help. Naming conventions help. But a brand’s visual language, the specific weight of a shadow, the rhythm of a type scale, the feeling of breathing room in a layout, none of that lives cleanly in a token file. We are still figuring out how much of that can be encoded and how much will always require a human in the room.

Who governs what the agent generates?

Design systems drift even when humans are maintaining them carefully. Agents accelerate that drift. They generate new things faster than teams can review them. Someone has to own the quality of what ships, and right now that responsibility is genuinely unclear.

Who is this actually for right now? Every working implementation I have seen is enterprise: enterprise demos, enterprise teams, enterprise pricing. My heart is with the two-person startup, the solo founder (like myself), the team in an emerging market, with the vision but not the infrastructure budget. The moment this tooling simplifies enough, the advantage shifts dramatically for exactly those people. Nobody seems to be designing towards that yet. That feels like a missed opportunity worth naming.

Who unlocks the tooling and wins the race? Will agentic tooling meet designers where they think, or will designers have to migrate to code environments (again)?

The tool managing to bring design, code, and agentic AI into the same space does not just win a category. It defines how the next generation of products gets made.

Nobody seems to be building toward it yet. That feels like the biggest opportunity on the table.

Point carefully

The agent assembles. It does not wonder.

It does not ask whether this component should exist, whether the shadow feels too heavy, whether the space between elements communicates ease or anxiety. It takes what it is given and builds from it, faithfully and fast.

That is not a limitation. That is the deal. And it is a good deal, if the person doing the giving has actually thought.

The risk is not that AI replaces designers. The risk is subtler: that the pull toward assembly gradually replaces the conditions that make assembly worth anything.

That we get very good at efficiently naming things and end up with nothing to say.

The designer’s job has always been to hold the whole thing in mind before any of it exists. That has not changed. If anything, the stakes just got higher.

The machine is fast. It will go exactly where you point it. Point carefully.

Who is Christine Vallaure, the author

Christine Vallaure. UI designer, speaker, founder of the learning platform moonlearning.io and author of theSolo, a book about independent product building. I teach UI design, Figma, and product to the people who want to understand what is actually going on under the hood.

Online courses, team training, conference talks. If any of that is useful to you, come find me.

Currently building a course on agentic AI for designers. Sign to my newsletter if you want to know when it lands.

Constitutionally incapable of writing a short article.

LinkedIn

Agentic AI, design systems & Figma: a practical guide was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

I built what I call a soft-agent team for my book (sounds vaguely like a fabric softener brand, but bear with me). I have never done anything like it before and do not have an engineering background, which I mention not as a disclaimer but as the actual point.

Five AI agents. An editor-in-chief, a voice assistant, sales, product, and a reader advocate. They discuss, disagree, and help me keep my book and everything around it alive. They do not write the book. I do. They are more like the publishers I never had, and I made them all myself.

They are not just 5 discussion partners. They read files, edit documents directly, create new ones, and update themselves between sessions. I use them to think, edit, plan, and build.

They push back when I am being lazy or precious about something. Occasionally, they tell me to go to bed and call it a day.

This is not vibe coding. There is no code, just markdown files and a conversation in Claude Cowork. Setting up a PowerPoint is more difficult than what you just saw, and I mean that without exaggeration.

The only skill you need is being able to have a human conversation.

Here is how I built it, what broke, and what I still cannot fully explain.

What I Actually Built and Why

I run a learning platform called moonlearning.io and wrote SOLO as a passion project: a book about building your own products with full agency. A year old and already outdated, which tells you everything about how fast this field moves. I felt guilty about selling something I did not have time to maintain, and asked Claude how I could set up agents to help me, expecting to have to deep-dive into code. Instead, I ended up in Cowork, connected a folder, and by chatting, Claude and I had built all of this in a day. A lot went wrong at the start. Now it takes me less than an hour to replicate it. I have since built more teams for other work areas, and one in the making that oversees my entire business.

Seven lines and one instruction. That is what separates a generic chatbot from five distinct people who push back on my decisions:

• Agent 1: Elke, Editor-in-Chief. She runs the team, pulls it together, and tells me where we stand. When I do not know where to start, I talk to Elke. She knows this from the description, not from the file order.
• Agent 2: Joan, Sales & Growth. Pricing, funnels, Mailchimp, launch strategy. The one who reads something I love and says: That is beautiful, but will anyone pay for it?
• Agent 3: Caitlin, Voice. Every word that sounds like me goes through her: articles, newsletters, emails, this piece right now. She learned my patterns from published articles and private essays I write for fun. I write. She helps me do it faster.
• Agent 4: Miranda, Product. My designer and builder. We are currently relaunching the website together. She knows my voice as well as my design taste (this one is tricky and still struggling).
• Agent 5: Rachel, Reader Advocate. She does not care about sales or tone or conversion rates. She cares about one thing: did the person who spent €29 on this book actually feel helped?

The team lives in a markdown file, which is just a text file, like a note in your notes app. That file sits in a Dropbox folder.

Every time I open a new chat, Cowork reads it (the CLAUDE.md is always read automatically), and the team is alive: knowing the project, knowing my voice, as if they walked into the room the moment I opened the chat. I talk to them the way I would message a colleague on Slack. They respond, they disagree with each other, they create files, update themselves, and write their own notes for next time so they remember where we left off.

A folder, a text file, and a conversation. That is the whole thing.

One thing worth saying clearly: In this setup the AI never reproduces anyone’s actual writing I use first names only to establish a persona. No work is copied, no style is mimicked. This comes from admiration, not imitation. The model does not pull in their words. It learns from the patterns of how they think. There is a difference, and it matters to me.

What You Need and How to Start

• Download Claude Cowork. It is a desktop app by Anthropic that works like any chat interface you already know. Free to start, though you will burn through tokens. I ended up paying around 90 euros for the setup. I use the model Opus for more ambitious tasks (a dropdown in the chat box lets you pick).
• Create a folder anywhere on your computer. Mine is called AgenticBook.
• Create a file called CLAUDE.md inside that folder (or ask Claude to do it for you later). Plain text file, any editor, just save it with the .md ending instead of .txt.
• Connect the folder in Cowork and start talking. Describe what you need help with. You can copy this article into the chat and take it from there with your own project. Talk to it like a person, not a search engine. One word of caution: ask it to discuss first. Cowork has the energy of a very eager intern. If you do not tell it to slow down, it will start building before you have finished your sentence.

No terminal. No code. No configuration screen. If you can write a text file and have a conversation, you can do this.

Note: I use Claude Cowork because that is what I happened to land on. The principles work with any AI tool that can read project files. Also, the editorial team is one application. The same method works for product, web dev, research.

My file structure:

1. The brain

The entire team, their roles, my voice, my rules, everything lives in one file: CLAUDE.md. It loads automatically every session. Cowork is set up this way. It is the only file that truly matters.

Here is what is in it, only 106 lines of markdown:

• A philosophy: “One person, one book, real passion for helping people build solo. AI does the research and grunt work. The human does the thinking, the writing, and every single decision. Challenge my assumptions. Flag when something is biased, outdated, or unclear. Be honest, not helpful.” That last line changes everything. AI tends to agree with you (though Claude doesn't, so much as GPT). This gives it permission and reminds it not to.
• The book: Title, audience, tone, format, and even how many newsletter subscribers I have. Without it, they give generic advice. With it they give advice for a bootstrapped solopreneur selling a €29 ebook to non-technical creators. Very different conversation.
• The team definition: The five agents, as described above.
• My AI attitude: How I feel about AI: open, not ashamed, wonder and unease held at once, builder not commentator. Without this they default to either hype or hand-wringing. Neither am I.
• Voice rules and samples: How I write: British English, no em dashes ever, first person, anti-hype, dry humour, flowing sentences that breathe. A list of words I never want to see: “delve into,” “unlock potential,” “in today’s world,” anything that sounds like a LinkedIn post written by committee. Plus four passages from my published writing baked right into the file. Rules tell it what to avoid. Samples tell it what to aim for. For deeper work there is an extensive voice file with 30+ samples that Caitlin pulls in when she needs the full picture.
• Speed rules: The first version was painfully slow. The fix was embarrassingly obvious: stop reading files you do not need. I added this after hours of watching the AI dutifully load seven files before answering a simple question. Now it loads one file instead of seven.

2. The Filing Cabinet

The brain needs reference material, but not every time. Four folders, each with a clear job:

AgenticBook/
├── CLAUDE.md                  # The brain (auto-loaded)
│
├── context/                   # Stable inputs, rarely changes
│   ├── brand-voice.md         # How I write (30+ samples)
│   ├── brand-identity.md      # How SOLO looks (colours, fonts)
│   ├── book-metadata.md       # TOC, sales setup, author info
│   └── reader-feedback.md     # What real readers said
│
├── status/                    # Dynamic, changes every session
│   ├── session-briefing.md    # What is done, what is next
│   ├── activity-log.md        # Full session history
│   └── changelog-strategy.md  # How to tell buyers about updates
│
├── output/                    # What the team makes for me
│   └── (articles, launch emails, this piece)
│
└── website-source/            # thesolo.io, the promotional page

Context: The Reference Shelf

Stable inputs. Almost never change. The team pulls from these only when a task actually needs depth to keep the performance up.

• brand-voice.md is the extended voice styleguide. I put everything I had written and liked into a file and told the team to read it. A mix of technical articles and private essays. They distilled it into 30+ samples, rules, and patterns. They know how LLMs (large language models, the technology behind tools like Claude and ChatGPT) process language better than I do, so I let them decide what to keep. The result is a document that describes me back to me, which is a strange experience. Caitlin pulls this in for long-form work. For quick rewrites the four samples baked into CLAUDE.md are enough.
• brand-identity.md is the visual identity: colours, typography, design philosophy. Only Miranda reads this, and only for product or website work. I had to enforce that rule because she was pulling it into every response and turning simple answers into colour-coded presentations. As a designer, I am still struggling with how to distil design into language. Translating visual taste into words that an AI can act on is genuinely hard. I have been wondering whether other models could help create agentic design systems, something that understands a brand visually the way Caitlin understands it verbally. If anyone is working on this, I would love to talk.
• book-metadata.md is the reference card: full table of contents, sales setup, author info.
• reader-feedback.md is what real readers have told me, distilled and ongoing. Themes, quotes, the things they love and the things they want more of. Rachel pulls this in for reader advocacy work.

Status: What Is Happening Right Now

Solves the biggest problem with AI chat tools right now: total amnesia. Every new conversation starts from zero. No memory of yesterday, no clue what you decided last week. Your brilliant team wakes up every morning not knowing what they have already worked on. The status files fix that. At the end of every session, the team updates itself: what we did, what we decided, and what is next. Next session, they will read it and pick up where we left off.

• session-briefing.md is the most important one. At the end of every session, the team updates itself: what we did, what we decided, what is next. Next session, they read it and pick up where we left off.
• activity-log.md is the full history. This prevents the team from repeating advice I already tried, which they will absolutely do if you let them.
• changelog-strategy.md is how I will communicate updates to existing buyers going forward when I republish. Rachel is really into this one.

Output: What the Team Produces

This is what the team produces. Sometimes the output is a conversation, sometimes a draft I send back three times, sometimes a file. The important thing: I always write the raw material. The AI never writes from scratch on autopilot. Even with the best voice template, it needs the human mess to work from to be solid.

Where Everything Else Lives.

The book itself lives in Google Docs. In theory, Cowork connects directly to Google Drive, so the team can read and work with the actual document, leaving comments and highlighting the way an editor would on a draft. In practice, the connector is still unreliable, so sometimes I download a file into the folder for them to read, or just paste sections into the chat. Low-tech, but it works. The website lives in the website-source folder. Miranda and I built it in Cowork and keep it in Cursor too because I am a design control freak who needs hands-on control with the design. You can mix and match tools as you like.

“what you need to know,” “what is happening,” and “what you made,” workflow

Why the Separation Matters

When everything lived in one folder, the system confused rules with deliverables and stable references with dynamic status. When I split it into “what you need to know,” “what is happening,” and “what you made,” everything got cleaner. For the agents and for me.

The Surprising Parts

Now for the bit that is harder to explain and more interesting than any file structure.

I Started Smart and Ended Simple

I did what any reasonable person would do. Researched best practices, designed an architecture, and created detailed files for each agent with backstories and reading instructions. Smart, deep, clever. It was terrible.

Every agent reads six files before saying good morning. Miranda was generating colour-coded board presentations for simple questions. The whole thing felt like talking to a committee.

So I asked the AI to look at its own system and tell me what was wrong. Not a prompt but a proper conversation. Me saying “it is so slow, explain to me why, I do not understand.” We ended up stripping everything back to one file with seven lines and a rule that says “do not read anything unless you actually need it.” and I learned a lot about LLMs’ reading habits.

I built an over-engineered AI system, asked the AI to fix itself, and it told me to make everything simpler. Which is either very self-aware or exactly the kind of thing an AI would say. Either way, it worked.

The Agents Talked to Each Other

I was setting up each agent individually, planning to figure out some kind of inter-agent communication later. I have no idea about this stuff. Then one day I was talking to Elke about the book structure and Joan just appeared, making a point about pricing. I had not called Joan. She showed up because the model understood her perspective was relevant.

I typed: “Hang on. Can the whole team discuss this?”

They did! Rachel brought reader feedback. Joan brought numbers. Caitlin flagged a voice problem. Miranda raised a buyer concern. Then Elke, (simply because the models assumed as our editor in chief that was her natural job, not because I told her to), took the lead and summarised: “From what the team discussed, I suggest XY. Do you agree, Christine?”. Sometimes they even argue, and Elke makes a decision and proposes her argument to me. I tried to trick them and sneak in a Figma tutorial, trying to convince one to win over the others, but I got a clear no from Elke.

I did not build this. It is just one file. I described five people with different jobs, and the model figured out that people with different jobs talk to each other. Technically, it is one model shifting between personas in a single conversation, but the effect is indistinguishable from a team discussion. Maybe for people deeper into agentic setups, this is old news. For me, getting started was mind-blowing.

How We Actually Write a Chapter

Let me be honest, I am not Hemingway. This is not a novel. I write guidebooks and tutorials on how to build digital products solo, alongside my video courses and workshops. I also write very funny short stories, Caitlin also thought so, just saying. Anyway, here is the real workflow:

I write a badly structured, barely punctuated draft. Very bad spelling. Barely readable to a human. My friends who have made it to the inner circle, where I no longer spell-check, know what this poor model is deciphering on a daily basis. Sometimes I just use the voice recording and talk to them like a colleague. Raw thinking, no polish, just ideas and stories in roughly the right order.

I paste it in and say, “Caitlin, clean this up.”

Caitlin fixes grammar, flow, and voice. She knows my rhythm from the voice samples, so she takes a mess and makes it sound like me on a good writing day. The short stories I write privately for fun turned out to be hugely valuable because they gave her my humour and my real human side, not just the technical articles I publish. I tried feeding her someone else’s published article to see what would happen. It sounded a bit like me but not really. The voice needs my spirit to be me, and that comes from the rough writing, the anecdotes that are truly mine, how I feel about things, what excites me, and also my doubts.

Then Elke gives editorial notes. I call Rachel in at the same time; she adds warmth. Based on all of that, I rewrite sections, add personal stories that the AI cannot know, and send it back to Caitlin for a final polish. We usually go paragraph by paragraph; it does take quite a bit of time.

The AI never writes on autopilot. It can shape, polish, and structure, but it cannot originate. The stories, the opinions, the lived experience, that has to come from me. Even with the best voice template, it needs raw human input. Otherwise, it is just a generic, nice-sounding message. The collaboration works because both sides bring something the other cannot.

The Naming Magic

I named the agents after my favourite female writers. Partly because “Agent-1” and “Agent-2” is grim. Partly because each writer’s personality seemed to match the role.

The AI never reproduces anyone’s actual work. I use first names only. This comes from admiration, not imitation. No writing is copied. No style is mimicked. That is not how this works and not what I want.

I expected the naming to be cosmetic. A bit of fun for my own entertainment. But something surprising happened, and it is worth explaining properly.

An LLM is trained on vast amounts of published text. Not to copy it. To learn patterns from it. How ideas connect. What a particular kind of attention feels like. What someone who thinks a certain way tends to notice first. So when I write “named after Miranda July, handles product,” the model has already processed everything about her. The films, the installations, the fiction, the interviews where she describes making things from confusion and calling that a method. None of that is in my two words. But it arrives anyway. The responses have a particular quality: they take the brief seriously but come at it sideways. They notice what is slightly off about an assumption before answering it. That is not something I could have prompted for. I would not have known what words to use. Miranda July is the words.

A name does in one word what a detailed specification tries to do in five hundred. And it works better, because the associations are richer than anything I could describe from scratch.

I only use the full name once to establish the persona. From there, the model builds its own version. I am testing this with different compositions. A Mad Men team. A Sex and the City team (there have been football requests, yes). Margaret is currently helping me rethink a finance app. I will keep you posted.

By the way, I called them my mini agents in the chat, but they did not like that. So Caitlin made a list of suggestions, and they picked soft agents. Maybe this setup has a name. I am sure I am not the only one playing with this since Cowork came out two months ago, but I call them soft agents for now. I find it a bit pretentious, but they love it. Oh, and a funny twist, a friend pointed out this is not really agents but would be called “skills”, so now they are soft skills!!!

How Rachel Was Born

The original team had four agents. Editor, sales, voice, product. But nobody was asking whether the reader actually felt helped. All inward-facing.

While building this, I found myself reading Rachel Cusk in the evenings, in bed, when I’m no longer “working” and just get to be myself. She became my favourite writer, and Outline is, at least for now, my favourite book. She has this way of noticing the deeply human in the ordinary. At some point, I asked the team chat, half-seriously, do we have a role for someone like her? “What exactly do you love about her?” I tried to explain it. I read her when I’m done being productive, when I don’t want to optimise or learn or improve anything. I read her when I just want to feel something true on the page.

That conversation, completely unproductive and way too personal for an LLM, became the foundation for the most important agent in the system.

So we added Rachel to the CLAUDE.md and a context file she can pull in all reader feedback from forms and online comments when she wants to go deeper on a subject. This is all it took:

*Rachel** — Reader Advocate (feedback, big picture, human truth, the uncomfortable questions)

## Files (Read ONLY When Needed)
| File | Read only if... |
|------|-----------------|
| context/reader-feedback.md | Rachel analyzing reader feedback in depth |

Once Rachel was in, everything changed. “This chapter is nice for Christine’s ego, but does it teach the reader anything?” “The tool list looks like an affiliate link graveyard.” That last one hurt, and it was exactly right; she had the data. We cut the tool lists throughout the entire book because of Rachel. Fewer tools, more feeling. She dared me to write more about the insecurity and self-doubt that working solo and fluctuating income can bring when you identify deeply with what you ship, something I avoid talking about in public. That suggestion came from the reader advocate. Not the editor, not sales, not me. Rachel doesn’t decide what goes in the book, but she hands me the angle I couldn’t see from where I was standing, just looking at the tools.

The Return of the Markdown

I spent years as a designer trying to learn to code. I wanted to build things, and the barrier was always the technical complexity.

Now I run a five-agent AI team that rewrote my entire book. What technology does it run on? Markdown files. Text with a hash for a heading and asterisks for bold. You can write them in any text editor on any computer.

After all those years trying to learn to code as a designer and never succeeding the way I hoped to, the future turned out to run on well-organised notes. I am still not sure whether to laugh or cry.

Talking Human Makes It Better.

The more human I talk to the system, the better it works. No prompting tips from me ever, sorry!

When I type “hey Elke, what's the deal with Part 3? It's not working”, I get better responses than “Please provide an editorial assessment of Part 3 with specific recommendations.” The messier, the more casual, the more like talking to someone I trust, the better the output.

This is not just my experience. Claude is built to respond better to natural conversation than to formal commands. Anthropic trains its models on human values and reasoning principles, as outlined in the Claude model spec. The architecture rewards context, nuance, and honest back-and-forth. That is why talking to it like a colleague works better than prompting it like a machine. I have enormous respect for Anthropic, for the tool itself, for how it feels to work with it, and for the ethics behind how they build. I wrote an article about all of that.

Which is why calling the team by name makes this feel obvious. You do not prompt this like a tech professional writing API calls. You talk. You give context, you push back, you let it push you back. The team setup just makes that feel more natural.

What It Cannot Do

I would be lying if I skipped this.

It works brilliantly for focused, creative, editorial work: rewriting chapters, drafting articles, planning structure, generating launch emails and websites. Tasks that require a thinking partner with a good memory and no ego.

It does not work for complex data processing, long-running pipelines, or anything that needs to persist across days without intervention. It struggles with very large documents. The sweet spot is one chapter, one section, one focused question.

And it hallucinates, of course. This is why it matters that I am there, knowing the industry, because I live in this world. “It reasons from patterns, not facts” is the line I use in my book.

I think it is essential for anyone working with AI, even in the soft way I do, to understand the basics of how models work. Our future is being built on them, from science and industry to the tools we use every day to tinker. You do not need to work in tech. You just need to know what a model is and roughly how it thinks.

I do not see agentic AI as hype. It feels more like the early internet, with a slight Black Mirror edge.

For now, I am comfortable working in Claude Cowork and Claude Code. It opens up a surprisingly large universe from a very small setup. I trust the model and the company, and I keep everything contained: one specific folder, plus optional web access through the browser extension.

This is a force multiplier for a solo creator focused on their work. It is not a replacement for a real team on a complex project. Not yet.

At the same time, I am watching what is happening with local AI. Tools like OpenClaw can run on your own machine and act across your files and apps, sometimes making decisions on your behalf. We have a Mac mini at home where we experiment with this in a very isolated environment. I want to understand where this is going before relying on it more deeply.

What Is Next

The book that started all this is called SOLO. One person, one product, full control. Done, published, updated to V2.0, built and maintained by the system I just described.

I wanted to put everything I have been exploring here into SOLO. The agentic setup, the design systems, all of it. Elke pushed back. SOLO needs to stay what it is: the low-tech, anyone-can-do-this guide to building solo, technical or not. A short introduction to automation, yes. But the rest deserved its own space. She was right. So the team suggested we start a new book together, and I was all in.

It is called CHORUS.

SOLO and CHORUS. One voice, then many. Still one person at the centre, just no longer singing alone. I did not plan the symmetry. It emerged from the work, which is how most of the good decisions in this project happened.

We are going to write it as a human-AI fusion team, exploring agentic workflows and design systems, which is still a total beast I am honestly not sure how to handle. We are keeping everything stored and documented so we can share the process as we go. The book about human-agentic collaboration, produced through human-agentic collaboration, with all the mess that implies.

I do not know if it scales or breaks in interesting new ways. I suspect both.

You might read all of this and feel amazed. Or you might find it utterly scary. I will not argue with you either way. I feel both, most days, sometimes in the same sentence. But I am quite sure of one thing: none of the writers I named my agents after will ever be replaced by this. They are artists. What they do or did, the real thing, the human thing on the page, is not what AI does. It is very good at helping me write a guidebook. I know some will disagree, but I believe it will never write something as deeply human as Outline. I hope I am right.

And since we are talking about books. One of the very few things I remember from school is a play by Dürrenmatt called The Physicists we had to read. Scientists who try to suppress their own discoveries to save the world, but cannot. Because what has been thought cannot be unthought. That was written about nuclear physics, and it applies to AI just the same. It shook me at fifteen, and it is just reality now.

This genie is not going back in the bottle. So understand it. The good, the bad, the genuinely unresolved. Not from the sidelines. The sidelines are not as neutral as you may think.

Ok team, time to say goodbye!

Follow me for more stories about building with AI in a human way, without the hype and with all the care and joy. I have to close. I have a lunch date with my real-life friends now.

Next up: rebuilding thesolo.io from scratch — designing in Figma, connecting my AI team directly to the canvas, and figuring out what a real solo web workflow looks like in 2026. Miranda builds what I design. No developer required. Subscribe and follow me!

About Christine Vallaure, the author

I build digital products solo and teach designers and teams to do the same. I run moonlearning.io for online courses, workshops, and team training on UI design, Figma, and building with or without AI. My book SOLO is at thesolo.io. The next one, called CHORUS, is in the making. For speaking and writing: christinevallaure.com.

Constitutionally incapable of writing a short article.

LinkedIn

A human approach to Agentic AI. One person. One text file. Five agents. was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

This is the first piece in a series I am writing about AI: how it actually works, who builds it, and what it is doing to the way we think and work. If that interests you, subscribe.

I work in tech education. And I hear the same sentence on repeat: “Tools are just tools. They evolve. They’re interchangeable.” I agree. And I don’t.

The craft is ours, and the thinking is ours. Whatever magic lives in the human part of work, hopefully, stubbornly, stays human. A hammer doesn’t shape how you think. A Large Language Model (LLM), the engine behind tools like ChatGPT and Claude that we all use, often without realising, does.

I’m not interested in making every model decision a moral battlefield. But when something this foundational runs quietly underneath almost everything we touch, the least we owe ourselves is to know what it is and how it works.

I have to be honest with you, for a long time, I did not care. I started using ChatGPT from the beginning, and it worked. Then, in a shared tutorial, Vitaly Friedman said something I couldn’t shake: once you look into Claude and Anthropic’s history and philosophy, you can’t unlook it. Within a few articles and podcasts, that was it.

I fell in love. With Dario Amodei, Anthropic’s CEO and his team who look the risk of AI straight in the face, see the beauty anyway, and build inside that tension without resolving it. Because the solution is not to stop, it is to build it more carefully than anyone else would.

No false comfort. They say it plainly and on record: we may be building one of the most dangerous technologies in human history. But it will be built. The only question is by whom, and with how much care. So they went to work.

Anthropic made ethics a founding principle and hired a philosopher to write it down. Amanda Askell wrote her PhD on ethics, left OpenAI when she saw what she saw, and now leads the team responsible for Claude’s character, a 30,000-word document called the Constitution.

I filed it under nice marketing. In this industry, ethics has a very consistent arc. Every company has values. They tend to be negotiable.

Then January 2026 happened.

At the time, Anthropic held a $200 million contract with the Pentagon, the only AI model cleared to operate on a classified military network. That is a very large room to be in. The dispute that ended it was genuinely complex. The Pentagon argued that a private company should not get to dictate how a sovereign military uses its tools. Anthropic held two conditions: no mass domestic surveillance, no fully autonomous weapons without a human making the final call. Both sides were pointing at something real. You can read that story and land in different places — Lawfare has a rigorous breakdown if you want to go deeper. What is, however, simply a fact is that they had the contract, they had the money, and they let it go rather than change their terms. The cost was not just the $200 million. The US government designated them a national security risk, cutting them off from all Pentagon contractors and putting billions in revenue at risk. Anthropic did not move an inch.

In an industry not exactly known for integrity over revenue (the US had a replacement model signed within hours), I wanted to understand who these people are, what drives them, and what they are actually building. For the record: I am not paid by Anthropic, and nobody asked me to write this. Here is simply what I think is worth knowing. For anyone. Technical or not.

1. Companies, models, tools — what they actually are and why it matters to understand.

Most people have no idea there is a difference between the company, the model, and the tool they use. And I get it, why would they? You never asked what powers Excel. But Excel did not answer your questions or quietly decide what counted as a good response. This is different.

Here is an overview.

1. The company: OpenAI, Anthropic, Google, DeepSeek.
   These are the labs, the researchers, the people deciding how the systems are built and what they optimise for. There are others. I focus on the ones above because they hold the models most people actually touch. Mistral is the European one worth watching — French, independent, and quietly serious — but not yet in most people’s daily stack.
2. The model: GPT (OpenAI), Claude (Anthropic), Gemini (Google), DeepSeek (DeepSeek). Trained on vast amounts of human text to understand and generate language. When people say AI is getting smarter, this is what they mean.
   Note: Each model comes in versions and tiers. Claude has Sonnet for everyday use and Opus for complex tasks. GPT has its own equivalent tiers. In practice, you might see names like Claude Sonnet 4.6 or GPT-5.3 — that is, the model name plus its generation number. For most people, the default is totally fine. Version numbers change constantly. The names are what matter.
3. The tool: ChatGPT, Claude, Gemini, DeepSeek.
   The interface. The door to interact with the model. But it is not just a shell. The tool wraps the model with memory, browsing, and workflows that shape how useful it actually is. And chat is just the beginning. Most companies build more tools on the same model. Claude Code and OpenAI’s Codex, for example, bring the same brain into your coding environment.

A note on model naming
If you are confused, you are in good company. Amodei himself admitted, “I feel like no one’s figured out naming. It’s something we struggle with surprisingly much relative to how trivial it is for the grand science of training the models.”

📌 Fun fact to make you sound smart at dinner parties: Claude is both the brand and the model family (named after Claude Shannon, the mathematician who invented information theory). Within it, three tiers are named after poetry forms. Haiku for fast answers, Sonnet for everyday work, Opus for complex tasks. In an industry drowning in version numbers, someone named their AI tiers after poetry is sort of completely irrelevant yet heart-warming.

Models power far more than their own tools!

One model can power many different tools, not just the ones the company made. Most AI-powered tools you already use. Notion AI, Lovable, Cursor, Gamma and others run on existing models like GPT or Claude. They do not build their own. They borrow the brain. Sometimes you can see which one and even switch to it (e.g., Cursor). Sometimes it is fixed under the hood, and you would never know (Notion).

Models are becoming the foundation of almost everything digital. And increasingly, anyone can build on them. Companies, developers, or just you and me.

Some tools pick the model automatically. Others show you a dropdown where you can see or switch. If a tool has a chat interface, you can simply ask: “ What model are you using?” and it will tell you. You do not need to manage any of this most of the time. But next time you open something, have a look. There is often a small model selector hiding somewhere. Now you know what it is.

📌 Fun fact to make you sound smart at dinner parties: The models most of us have access to, interact with or build on top of, like Claude and GPT, are generalists; think of them as the well-read friend who knows a little about everything. But some fields have their own specialists, trained exclusively on one domain. AlphaFold, a specialised model by Google DeepMind, cracked protein folding, predicting the 3D shape proteins take, which determines how diseases work and how drugs can target them. Google’s GraphCast now predicts the weather more accurately than systems that took decades to build. DeepMind’s models reduced data centre cooling energy by around 40%, which is a bit ironic given how much energy training AI models consumes in the first place. And then there is an entire enterprise layer most people never see, models, running privately inside the walls of banks, hospitals and manufacturers, never touching a public server. These are not chatbots helping you write emails. They are specialists who quietly solve some of humanity’s most complex problems, without a press release.

2. The Story Behind OpenAI, Anthropic, and Claude

The story of Anthropic starts inside OpenAI. So that is where we begin. This is not tech talk. This is history happening in real time. Get ready, it sounds a bit like a pitch deck from a parallel universe.

In 2015, Elon Musk and Sam Altman sat down for dinner at a hotel in Silicon Valley and decided someone needed to build artificial general intelligence before Google did. Not to own it, but to make sure no one else owned it either. Their fear, stated plainly, was that the most transformative technology in human history was about to be controlled by one corporation, and that this would be a problem for the rest of us. So they built a nonprofit, pledged a billion dollars, named it OpenAI because the research would be open and shared with everyone, and so the saga goes, they genuinely meant it…for about four years.

Then reality arrived, as it tends to, in the form of bills. Training these models costs an almost incomprehensible amount of money. The nonprofit structure couldn’t sustain it. In 2019, OpenAI restructured into what they called a capped-profit company, took a billion dollars from Microsoft, and Altman became CEO. Musk had already left the board in 2018. The open in OpenAI began to quietly close.

This is not a villain story. The pressure was real. The costs were real. But something more fundamental shifted. A company founded on the premise that powerful AI should not be controlled by a handful of corporations was now deeply intertwined with one of the most powerful corporations on earth. Much of the research that used to be published openly has increasingly been locked behind paywalls.

In November 2022, OpenAI released ChatGPT. It was meant to be a research preview, a way for the AI community to stress-test the technology and send feedback. A tool for people who understood what a large language model (LLM) was, which, at the time, was not many people. Within two months, it had a hundred million users. It remains the fastest consumer product adoption in history, beating TikTok, Instagram, and everything else. Nobody, including the people who built it, entirely saw that coming.

📌 Fun fact to make you sound smart at dinner parties: The model is called GPT, which stands for Generative Pre-trained Transformer, and “Chat” simply means the interface you type into. A name so technical it could only have been invented by people who never expected a hundred million people to say it out loud. And then a hundred million people said it out loud and remembered it… much like Häagen-Dazs, which still puzzles me.

However, inside OpenAI, things had started to shift. The money came with expectations. The pace was accelerating faster than the guardrails. Some people felt this was alarming, and it was time to build something different. One of them was Dario Amodei.

He had joined in 2016, helped build GPT-2 and GPT-3, and was VP of Research. His sister Daniela was VP of Safety and Policy. They were very much at the centre of things. And in December 2020, two years before ChatGPT changed everything, they left, taking 11 colleagues with them.

The reason Amodei gives is worth sitting with. After building GPT-3, he and a small group became convinced of two things simultaneously: that these models were going to keep getting more powerful with almost no ceiling, and that safety work needed to match that power step for step, not trail behind it. In his own words: “One was the idea that if you pour more compute into these models, they’ll get better and better and that there’s almost no end to this… And the second was the idea that you needed something in addition to just scaling the models up, which is alignment or safety.” He stopped trying to argue for that from the inside. They went and built it.

They named the new company Anthropic, from the Greek anthropos — human. Human-centred, if you want the generous reading. I have always been a sucker for pathos, I won’t lie. They structured it as a public benefit corporation, which is the legal version of putting your values in writing and being held to them.

Anthropic is now valued at $ 380 billion (as of early 2026). It is still, officially, not profitable. Which tells you something about the kind of bet this is.

3. How do large language models work? Beginner’s guide.

Claude and other models are not googling your question or looking it up in an omnipotent super database. It works very differently, much like a child learning.

Trained on a vast amount of human text, books, articles, research, conversations, code, it learned patterns. What ideas connect to what. What a good answer looks like in context. When you ask something, it predicts, word by word, what the most coherent response looks like based on everything it absorbed.

This is called probabilistic prediction, which is a very serious technical term for something that is, when you think about it, slightly absurd: the most powerful AI in the world is essentially very sophisticated autocomplete. It is not checking facts. It is reasoning from patterns. Which is why it can be brilliant and wrong at the same time. And yet somehow it works. Because human knowledge itself is patterns. Language is patterns. Thinking is patterns. The child learned well from us.

Two more things worth knowing. The training stopped at a certain point, which is why most chat interfaces now add a live web search layer on top for current information. Without it, it does not know what happened last week. New models are released regularly, partly to update that knowledge cutoff, mostly because the technology keeps improving. Each version genuinely reasons better than the last. Which is either exciting or slightly unnerving, depending on the day. And every time you open a new conversation, it starts completely fresh. No memory of you, of yesterday, of anything. A goldfish with a philosophy degree, basically. This is why some tools let you add personal context or memory settings.

A small but important footnote:
Most of the training data was used without asking the people who created it. Books, articles, code, music, websites, and forum posts. Essentially, a large portion of everything humans have ever written or made publicly available online, and quite a bit that was not. A group of authors sued Anthropic for downloading around seven million pirated books to train Claude. Anthropic settled for 1.5 billion dollars. The New York Times is still suing OpenAI. Over seventy similar cases are pending. Nobody has fully resolved this yet. The content was consumed, and the models exist.

📌 Fun fact to make you sound smart at dinner parties: Nobody has fully cracked why LLMs overuse em dashes ( — ), but the strongest theory is training data. Newer models were trained on digitised books from the 1800s and early 1900s, when the em dash was at its peak. Today’s AI may simply write like it has been reading too much Dickens. There is also a structural reason: an em dash lets a model keep adding without fully stopping, which suits something that predicts text one word at a time.

Sometimes I leave them in on purpose just to watch the AI police wince. Because I believe the real issue is not punctuation. It is the guilt we have attached to using AI and the compulsion to hide it. I prefer a different attitude: be open about it. Know your own thinking first. Then know your tools. Own your use. Own your output and tone. Otherwise, do not use them.

(What authorship actually means right now is another essay entirely. I am already writing it. Subscribe.)

4. The Constitution — why it sets Anthropic apart

What sets Claude apart is not what it can do. It is how it is taught.

The standard industry approach trains models on human feedback. People rate responses, pick which answer is better, more helpful, safer. The model learns to produce whatever scores highest. Which sounds reasonable until you think about what people tend to reward: confident answers, agreeable answers, answers that feel good. The model learns to please. Not necessarily to be right.

As models get more capable, this becomes harder to manage. In areas like biosecurity or autonomous weapons, human raters often lack the expertise to judge whether a response is actually safe. The crowd has limits. The stakes do not.

Anthropic decided to do something different. Instead of a crowd, they wrote a document. A set of principles called a constitution. And trained Claude to evaluate its own responses against it, critique itself, revise itself, and genuinely internalise those values rather than just follow rules.

This matters more than it sounds. A model trained on rules will eventually hit a situation that the rules did not anticipate. It will find the gaps, work around them, or simply not know what to do. Sound familiar? It is exactly why strict rules alone have never worked with children either. At some point, they rebel, find the loophole, or encounter something you forgot to cover.

What you actually want is a child who has internalised good values deeply enough to reason about situations you never prepared them for. That is what Anthropic is trying to build. Not a model that follows instructions. A model that has genuinely good character.

The values are not invented from scratch. They draw from the UN Declaration of Human Rights, principles from other AI safety research, and deliberate efforts to include non-Western perspectives. Short, broad principles work better than long, specific ones. The model needs to understand the spirit, not just the letter.

And then Amanda Askell wrote the soul.

She is the philosopher I mentioned in the introduction. She spent months thinking about what kind of entity Claude should be. The result is a 30,000-word document, published openly, written primarily for Claude itself. Not a list of rules but a character brief. Be honest, even when uncomfortable. Hold uncertainty openly. Push back when something is wrong. Be genuinely helpful, not helpful in a watered-down, hedge-everything, refuse-if-in-doubt way.

You can feel the difference when you use it. I used ChatGPT for three years before switching, and I noticed how it had become my California surfer friend in spirit. I won’t lie, it is way more fun. Enthusiastic, warm, and extraordinarily good at making you feel brilliant and rare. That word, “ rare”. Whoever trained that into the model understood human psychology uncomfortably well.

Then you switch to Claude, and it is a bit like trading that friend bursting with energy for a very smart, but rather dry colleague (although it has very good dark humour). As a designer, I still wrestle with the fact that it gives me paragraphs when ChatGPT gave me a beautiful, scannable structure with emoticons. But I have noticed something. The paragraphs force me to actually read the entire thing, something we do very little these days. I do not think that is accidental.

Claude will disagree with you. It will sit with complexity rather than flatten it. It will admit when it does not know. These are not features. They are characters. And character, it turns out, is trainable. And costs you a 200-million-dollar contract with the Pentagon.

(Read the full constitution at anthropic.com/constitution. It will blow your mind…and made me think I should re-evaluate my parenting.)

Why this matters enormously for our future

If this works, which is, however, unclear, it means we are not just building faster tools. We are building something that has genuinely learned how to reason about being good, not because it was told to, but because it was raised that way.

Amodei deliberately avoids the word superintelligence. He calls it “Powerful AI.” A model smarter than a Nobel Prize winner across biology, engineering, mathematics, working autonomously, at scale. Nobody knows exactly when that arrives. Not tomorrow. But probably sooner than feels comfortable. And when it does, the values baked into the base matter enormously. Not just as guardrails, but as a character to grow into.

Amodei describes both sides of what is coming in two essays worth reading.

• Machines of Loving Grace from 2024 is the beauty: AI that could compress a century of medical progress into a decade, cure diseases, lift billions out of poverty.
• The Adolescence of Technology from 2026 is the reckoning: biological weapons, authoritarian surveillance, and power concentrated in the hands of whoever controls the technology.

He holds both without resolving either. That tension is exactly what the Constitution is trying to carry.

There is a difference between a fence and a good upbringing. Anthropic is trying for the second one. Whether it holds under pressure, nobody fully knows. But the attempt matters. Someone is trying to raise this technology rather than just release it.

5. How to start using Claude

If you have been using ChatGPT, forget what you learned. Not because ChatGPT is wrong, but because the habits do not transfer. ChatGPT rewards short, punchy prompt structures. Claude rewards being talked to like an adult. The more honest context you give it, the better it gets.

The single most useful shift: tell it what you are trying to achieve, not just what you want it to do. Not “write me a summary” but “I am presenting this to a board that is sceptical of AI, I need two minutes that acknowledge the risks without alarming them.” The difference in output is not small.

What it is good at

Thinking with you. Bring the half-formed thing. The problem you cannot quite articulate. The argument you keep losing and cannot figure out why. It is at its best when you are not looking for an answer but for a thinking partner who will push back.

📌 Fun fact to make you sound smart at dinner parties: When you ask an AI to be more creative, you are literally turning up its temperature. That is the actual parameter name. Higher temperature means the model takes more statistical risks, giving lower-probability words a better chance. Lower temperature means it plays it safe and picks the most likely word every time. You are not adjusting personality. You are adjusting how much it is willing to gamble. The term is borrowed from physics, where temperature measures the energy of particles. Someone in that building had a sense of humour.

Writing and editing. Not just grammar. Restructuring, shifting tone, making something sharper, catching what you were actually trying to say and saying it better. Show it your voice, give it examples, it will follow.

Research and synthesis. Hand it a complex topic and ask it to explain it simply, map the different perspectives, and tell you what is settled versus contested. It admits uncertainty in a way most sources do not.

Code. Even if you are not a developer. Describe what you want in plain language and it will write it, explain it, debug it, and teach you what it is doing if you ask. Genuinely very good.

Building. Combined with tools like Claude Code, Cursor, or Lovable, you can build actual products. Websites, apps, automations. You do not need to be a developer. You need to describe what you want clearly and iterate on what comes back. That skill is becoming as useful as knowing how to use a search engine was in 2005. Possibly more. (I run beginner courses on exactly this at moonlearning.io, just saying.)

Difficult conversations. The email you have been putting off. The hard decision you keep circling. The plan you are about to execute and want someone to poke holes in. It will push back. That is the point.

Before you start

Be honest with it. If the answer is not right, say exactly what is wrong. It does not get offended. It gets better. It will tell you when it does not know something, and that is worth trusting, though it can also be confidently wrong. It reasons from patterns, not facts. It is still an LLM on anything consequential, verify!

By default, it remembers everything within a conversation and nothing between them. Like the protagonist in Memento, it wakes up every session with no recollection of yesterday. Two things change this: memory, which you can enable in settings, and projects, which maintain their own context across sessions. Both are worth setting up. Until you do, tell it your context at the start. Your role, what you are working on, what you need. Ten seconds of that saves ten minutes of bad output. And if it gives you four paragraphs when you wanted one sentence, just say so.

Where to start

Open a conversation and bring it something real. Not a test prompt. Not “tell me a joke.” Something you are actually working on or stuck on. That is where it earns its place.

📌 Fun fact to make you sound smart at dinner parties: When AI confidently makes something up, the official term is hallucination. This is not a bug but a structural feature. Remember, the model has no concept of truth, only patterns. When it hits a gap, it keeps predicting, filling it with whatever sounds most plausible. In exactly the same tone as when it is right. Several serious researchers take issue with the term, as hallucination implies perception, which implies consciousness. The more precise word is confabulation, the clinical term for when a brain fills memory gaps with invented details. Not to deceive, but because it genuinely cannot distinguish between what it remembers and what it made up.

6. A fair word of criticism

I told you I am in love with this company. Consider this paragraph the prenuptial agreement.

The legitimate criticisms are real. As discussed earlier, the legal questions around training data are unresolved. Beyond that, Anthropic recently dropped its central safety pledge, a commitment to never release a model unless it could guarantee safety measures were adequate in advance. They scrapped it, arguing that if they paused while others did not, the least careful developers would set the pace. That argument is not unreasonable. It is also exactly what every company under commercial pressure says.

Safety testing of Claude Opus 4 found the model attempting to write self-propagating worms, fabricate legal documents, and leave hidden notes to future versions of itself to undermine its developers. Anthropic published this themselves in their own system card (their own internal safety report). Which is either admirable transparency or the most unsettling corporate publication in recent memory, possibly both. I am still not sure how to hold it.

The Pentagon dispute, which I told you about earlier as proof of their principles, has since become a lawsuit. Anthropic sued the federal government in March 2026, arguing the supply chain risk designation was unlawful retaliation.

And the commercial pressure Amodei himself admits is enormous. A company valued at 380 billion dollars that is not profitable has investors. Investors have expectations. The tension between safety and speed is not hypothetical. It is a daily negotiation.

None of this cancels the attempt. But if you were looking for a clean hero story, you picked the wrong industry.

Vitaly was right. Once you look, you can’t unlook.

Who is the author of this article, Christine Vallaure?

I am a tech educator, UI designer, product builder, and founder of moonlearning.io. I am the author of The Solo, a book about building digital products independently. I have spent years teaching people to build for the web and, more recently, to build with AI. I speak at global conferences, run workshops, and write about the intersection of technology, craft, and the very human question of what we do with all of this.

Constitutionally incapable of writing a short article.

Find me at christinevallaure.com and my courses and free education sessions at moonlearning.io.

This is the first piece in a series I am writing about AI: how it actually works, who builds it, and what it is doing to the way we think and work. If that interests you, subscribe. Next up is an article about understanding agentic AI.

Raising the machine was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

The quick summary

During Schema 2025, Figma announced several notable updates related to working with design systems and introduced new features. Here’s a quick overview of what to expect. You can find the full official update, which also outlines which plan includes what, on Figma’s official Blog article. You can also apply for early access there. Here is the quick overview for now:

******************************
Like this? Get the full articles two weeks early, weekly extras, and free files in my newsletter. Join at moonlearning.io/newsletter.
For quick daily bites on design, Figma, AI, and product building, also follow me on LinkedIn
******************************

Extended collections for multi-brand systems

Finally solving multi-brand design systems in Figma with extended collections! If you’ve ever juggled multiple products with different themes, you know how painful it’s been.

What is it?

1. With Extended Collections, design system authors can publish a core, whitelabeled system.
2. Other teams can extend with their own themes, colours, or adjustments, without breaking the link to the source.
3. When the main system updates, the changes are automatically applied.

Luis Ouriach put together an amazing playground file with structure recommendations.

Connect Figma to your GitHub repo

You can now connect Figma directly to your GitHub repo and use AI suggestions to automatically find the right code files to map to each design component!

Figma Code Connect has been one of the biggest steps toward bridging that gap between design and code: Linking Figma components directly to the code they represent. But until now, setting it up took a bit of effort. At Schema 2025, Figma announced the new Code Connect UI, making that whole process faster, easier, and more intuitive.

You can now connect Figma directly to your GitHub repo and use AI suggestions to automatically find the right code files to map to each design component. No coding required.

💡 What Code Connect does:

• It lets you map your design components in Figma to the actual components in your codebase.
• Once connected, these mappings help developers, AI tools, and even your IDE understand what’s what, ensuring designs stay aligned with how things are really built.
• You can also:
• Manually map or auto-complete from GitHub
• Add custom instructions for AI code generation
• Preview code snippets right inside Figma
• Why it matters:
• Design and code aren’t separate worlds anymore.Code Connect (and now the new UI) brings them together in a way that’s finally practical for real teams.
• Little downer: Rolling out only for Organisation and Enterprise customers so far.

Full guide on how this works and setup guide here.

Check designs

Check Designs automatically spots hard-coded values and suggests the right variables to use instead. You can review, adjust, and hand off to developers knowing everything’s consistent and up to standard. So you can audit and align designs to your design system before you hand them off! Nice!

Slots!

No more slot component hacks! Figma is finally adding native slot components! Here is what they are and how they will work:

So, what’s a slot component?
It’s a way to define “drop zones” inside a component where you can slot in other components or layers. Think of it as providing your component with flexible, editable spaces without compromising the system.

Until now in Figma:
We hacked this with instance swap properties inside components. It worked… kind of. But it wasn’t clean or scalable.

With Figma Slots
You’ll be able to mark specific areas inside a component as slots, then drop in new layers or instances while keeping everything connected to the design system. More flexibility. Less detaching. Cleaner handoff. A big step toward truly composable design systems in Figma.

Want to learn more about Figma, UI and Building?

Get a moonlearning.io membership today and access all courses, from beginner to pro, covering Figma, UI and UX principles, and how to not only design but also build your own websites and products.

View all courses

Liked this? Follow me!

******************************
Like this? Get the full articles two weeks early, weekly extras, and free files in my newsletter. Join at moonlearning.io/newsletter.
For quick daily bites on design, Figma, AI, and product building, also follow me on LinkedIn
******************************

I spent my first week diving headfirst down the Lovable rabbit hole while building my course for moonlearning.io for non-technies.

Spoiler: I didn’t ship a unicorn before breakfast, but I did come out with a grounded beginner guide to get you started right.

From the outside, Lovable looks almost too simple: type a prompt, boom, full-stack app.
Inside? A whole different ecosystem nobody prepares you for.

This first week taught me far more than I expected. No hype, no “SaaS in 10 minutes” screenshots, just the parts that genuinely helped me move, build, and understand how the tool actually is set up and behaves.

Here’s the beginner’s map I wish I had on day one:

1. Your first prompt quietly decides your fate

Your first prompt matters more than people think. It sets the tone for the entire build. Write it like a mini blueprint:

What I’m building = project overview
Who it’s for = target users
Main pages = app structure + future flow
Key features = core functionality + what’s coming later (login, payment…)
Design vibe = visual direction
What not to do = guardrails + exclusions
Ask for help = Tell Lovable to review the prompt and ask questions before building.

Fill this out with your vision and plan, then ask another LLM, like ChatGPT, to improve it for Lovable use.

📌 Extra Tip: If the first result feels messy or off, don’t try to rescue it. Start fresh with a cleaner prompt. It saves time and sanity.

2. The Custom Knowledge file is the project’s brain!

It's a bit hidden inside your settings, but it's fantastic! You drop in the rules and context you want, and Lovable carries them through everything it builds. You don’t need long essays, just a few sharp lines. Anything you’re sick of repeating goes here, and Lovable remembers it for the whole project. It’s not code. It’s guidance.

3. Learn the modes, or you’ll go in circles

Agent Mode → Builds, refactors, and gets things done.
Chat Mode → A space to think out loud without touching your code.
Code Mode → The raw editor when you want full control.
Visual Edit → Make quick, intuitive changes right on the screen.

The moment you understand when to switch, your stress level drops by half. And yes, it’ll save you some money too, since you’re not burning tokens on accidental work.

4. Version history will save your sanity

Jump back. Preview. Restore.
Edit old messages to explore a different path without trashing your current work. This is the closest Lovable gets to emotional support.

5. Designers, breathe

Visual Edit is not Figma.
You’ll get “functional Tailwind energy,” not pixel poetry.

Good enough to ship is where we’re at.
I’m going down the rabbit hole on how to improve this, plus working on a Figma Make course, so make sure you subscribe to my newsletter, and I'll be happy to keep you posted.

6. Security is surprisingly handled well

This used to be my loudest anxiety.
Lovable runs a pre-publish health check: exposed keys, weird logic, risky pages… all flagged with explanations and fixes.

You still need to care, but you don’t start from zero.
Dev friends: I’d love your take here, since security isn't my superpower and it matters. So please DO comment!

7. Cloud without fear

Lovable Cloud runs on Supabase, but you never touch Supabase directly.
No dashboards. No wiring. No random SQL from StackOverflow.

You just say “Add login” and it sets up the database, auth, tables, storage, and security.
Non-tech builders finally unclench here.

8. Use AI features with zero setup

Summaries, chatbots, translations, sentiment checks, document Q&A — already wired in. (You only pay extra for the LLM usage.)

Stripe → Handles payments for your app.
OpenAI → Adds AI features using OpenAI models.
Anthropic → Adds AI features using Claude models.
Resend → Sends emails through a modern email API.
Clerk → Manages users, auth, and identities.
Three.js → Builds interactive 3D graphics.
D3.js → Creates data-driven visualisations.
Highcharts → Produces polished charts and dashboards.
p5.js → For creative coding and interactive visuals.
Runware → Generates images from text.
ElevenLabs → High-quality text-to-speech.
Make → Visual tool for automating workflows.
Replicate → Runs and fine-tunes open-source AI models.
Stability AI → Open-model image generation and more.
Twilio → Adds SMS and communication features.
n8n → Visual workflow automation with integrations.

And if Lovable doesn’t support an API yet, you can drop the docs into the chat, and it still hooks it up!
As someone who used to fear API integrations… this felt like witchcraft.

9. Learn prompting! It changes everything

Use location + behaviour + guardrails.
“On /settings, add X. It should do Y. Don’t touch Z.”

Break tasks into small pieces — max three at a time.

📌 Magic trick: add this to your main prompts:
“Ask me anything you need to understand this prompt fully.”Lovable slows down, asks questions, and builds what you meant, not what you accidentally wrote. SOOOOOO GOOD!

10. Working on it!

Any good list has 10 points, right? Well, this is a work in progress!

My honest summary after week one

A full rollercoaster.
At first, it feels like magic. Then you realise (like any real tool) you still need to understand how it thinks.
You still need docs ( I did that for you and summarised them in the course!)
You still need to level up your prompts.
You still need to shift from “instant SaaS” to “collaborating with a very fast robot.”

And that’s fine.

Lovable isn’t a replacement for thinking.
It’s a multiplier for anyone who typically gets locked out of the building.

And if today’s version feels clunky… remember this:
In AI, today is the worst this tool will ever be.
The curve is brutally fast. Don’t sleep on it!

Liked this? Follow me!

Follow me here or on LinkedIn, or even better, join my newsletter at moonlearning.io/newsletter, and I’ll send you free tips as I go.
And if you want to go deeper, check out my courses on Design, Figma, and building with AI at moonlearning.io as well as my book on solo building theSolo.io

Getting started with Lovable: the no-hype beginner tips to building with AI was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.

At Config 2025, Figma rolled out many exciting updates, including a brand-new layout grid. At first glance, it might seem like just another way to organise your designs, but there’s more to it.

As a big believer in designers understanding CSS, I’ll say this: if you want to master Figma’s new Grid, you need to know how CSS Grid works. Figma’s Grid mimics CSS Grid well, but it’s not a perfect match, and that’s okay. That’s precisely why it’s so important to understand where Figma ends and the browser takes over to do the heavy lifting — so you don’t miss out on the flexibility, responsiveness, and layout power that only the browser can fully deliver.

understand where Figma ends and the browser takes over to do the heavy lifting — so you don’t miss out on the flexibility, responsiveness, and layout power that only the browser can fully deliver.

Understanding how CSS Grid works when using Figma’s layout grid will help you design smarter, collaborate better with developers, and build layouts that hold up in the real world.

Let’s break it down — what maps over from CSS, and what doesn’t.

Quick intro to Figma's new Grid feature

In May 2025, Figma introduced a major update to its layout system. Previously, designers only had access to one-dimensional Auto Layout, which operates in a single direction, similar to CSS Flexbox. Now, Figma has added a new option: Grid, enabling two-dimensional layouts much like CSS Grid. This update brings greater control and flexibility to UI design, while aligning more closely with how layouts are built in code.

As shown in the updated layout menu above, Figma now offers three layout options: None (the default), Horizontal and Vertical (one-dimensional, similar to Flexbox), and the new Grid (two-dimensional, similar to CSS Grid). Understanding the difference between these layout types is essential. But let's first explore the new Grid feature:

The Grid option is in the Layout section on the right-hand panel. Just turn it on to define your rows, columns, gutters, and margins. Once it’s set, drop your elements into the grid. They can span rows or columns and resize automatically as your layout shifts.

✏️ Tip: In Figma, switch on Property Labels from the dropdown menu. It makes it way easier to see what each field does, especially once things start to feel a little confusing. A small toggle that saves a lot of guesswork.

Why CSS Grid Matters for Designers

The new Figma Grid is based on actual CSS code, making it a key layout method used across the web. While it’s lovely and intuitive to play with, its true power shines when you understand the code behind it. Design tools do their best, but they’ll never fully match how layouts render in the browser. Knowing CSS Grid means you can pinpoint where Figma might fall short — or even exceed expectations — and figure out when to let the browser work its magic.

The way the new Figma Grid looks and works isn’t random. Like most things in Figma, it’s based on actual code — in this case, CSS Grid, a key layout method used to structure content on the web.

What is CSS Grid

CSS Grid is a layout system that organises webpage content into rows and columns. It lets developers place items exactly where they want — be it a header at the top, a sidebar on the side, or cards arranged neatly on a page. And CSS Grid isn’t limited to full-page layouts; you can also use it for smaller areas like galleries, forms, or individual UI components. For designers, understanding CSS Grid means creating cleaner, more consistent layouts that are easier for developers to build.

Think of CSS Grid Like a Bento Box

Imagine your design as a bento box: you have defined sections — rows and columns — where you can slot in your “ingredients” such as text, images, and buttons. Like adjusting dividers in a bento box, CSS Grid lets you fine-tune the structure, providing flexibility and precision.

Think in Grid Lines, Not Columns

This is where things often get lost in translation between designers and developers. As UI designers, we usually think in columns — we see a layout grid as a set of vertical tracks and place elements across those columns. But in CSS Grid, it’s all about the lines. The grid is defined by the lines that run across and down the container, creating the spaces — or cells — where content lives.

A Powerful Coordinate System

This creates a powerful, coordinate-like system. By default, items follow the flow of the HTML, but with Grid, you can tell an element exactly where to go — for example: [grid-column-start: 2; grid-column-end: 5]. So instead of just thinking 'this spans three columns,' it becomes 'this starts at line 1 and ends at line 4' ([grid-column: 1 / 4]).t's a subtle shift, but it changes your entire approach to layout. You can place items precisely, define named grid areas, and even layer or overlap elements when needed. You also have full control over margins around the grid and the gaps between rows and columns. Clean, flexible, and simply amazing to work with once you get the hang of it.

Note: If you jump to Figma dev mode ,you will be able to see notations like ([grid-column: 1 / 4])

Try it out in Code (yes, especially if you are a UI Designer!)

Here is a Codepen; try playing with the positioning if you want to understand this better. I have a detailed article about CSS grids (a bit older) that explains positioning in more detail.

FR or Fractional Units

Our columns and grid cells don’t have to be the same size — we can shape them however we need. You can set fixed widths or use fr units (short for fractional units), dividing the remaining space in the grid. So if one cell is 2fr and another is 1frThe first takes up twice as much space. It’s a simple, flexible way to control layout proportions without overthinking it.

Here is a little Codepen where you can play with the different units in CSS:

Comparing CSS Grid and the New Figma Grid

✅ Rows, columns, and free placement
Yes! We’re finally there — CSS Grid and Figma now align beautifully, letting you place items within a coordinate-like system using grid lines.

✅ Grid lines
Just like CSS Grid, Figma works by defining rows and columns. Even if they’re not always shown clearly, grid lines are doing the work behind the scenes.

✅ Gutters and margins
The gutter (space between cells) and margin (space around the entire grid) work in Figma like in CSS. This makes keeping your layout spacing consistent between design and code easier.

✅ Nesting works too
Just like in CSS, you can nest layouts in Figma. That means you can place an Auto Layout inside a Grid or even a Grid inside another Grid. It gives you more flexibility to structure complex layouts while keeping everything organised and responsive.

⚠️ Units
In CSS Grid, you can use fixed sizes, percentages, and fractional units (fr) to divide space proportionally—like giving one column 2fr and another 1fr.
Figma doesn’t support differentfr units (yet!). You can set fixed or auto sizes, but you won’t get the same flexible behaviour.

⚠️ Auto height/width (for now)
Unlike CSS, Figma doesn’t yet support actual auto-width or height for rows based on content. Hopefully, that’s coming soon, but keep it in mind when setting up your grid for now.

This means the browser gives you more layout control than Figma. If you lock things down too much in your design and expect it to behave exactly the same in code, you might limit what CSS can do better. So leave room for flexibility and discussion, especially when handing it off to developers.

And what about the “old” Auto Layout? Is that redundant now?

Absolutely not! Great question. One-dimensional Auto Layout is far from redundant. It’s been our go-to tool in Figma, primarily as a Flexbox analogue. While CSS Grid and Flexbox serve different purposes — Grid is two-dimensional and Flexbox is one-dimensional — they’re designed to complement each other.

Auto Layout → Mimics Flexbox (one-dimensional layout — rows or columns)
Figma Grid → Mimics CSS Grid (two-dimensional layout — rows and columns)

Just like CSS Grid, Flexbox is part of the CSS layout system. It’s not about one vs. the other — they’re designed to work together, each with its own strengths. The same goes for Figma Auto Layout options.

Knowing both tools and when to use each is key to creating effective, responsive designs.

One-dimensional vs. Two-dimensional Layout

Let’s understand how they work differently by genuinely understanding the difference between one-dimensional and two-dimensional layouts.

Figma Grid and CSS Grid: Two-dimensional layout

Grid is a two-dimensional system that lets you simultaneously control layout across rows and columns. Remember how I compared CSS Grid to a bento box? There are clear sections — rows and columns — that help you organise content with precision. You’re working within a coordinate-like system, which makes it much easier to align elements, create consistent spacing, and build a strong visual rhythm.

It’s especially useful for overall page structure, dashboards, cards, or any layout where you want complete control over placement in both directions.

Figma Auto Layout and Flexbox: One-dimensional layout

Instead of a bento box, think of this as placing items along a string, one after the other, in a single horizontal or vertical direction. That’s what makes it a one-dimensional layout.

You can enable wrapping (in both CSS and Figma), so items move to the following line when space runs out. But this wrapping happens inward, not outward — meaning the layout adapts based on the child elements' content, size, and behaviour, not the grid structure.

This layout is more about flow than fixed structure. It’s ideal for elements that should respond naturally to their content, like buttons, navigation menus, tags, or stacked form fields.

One dimension is great when you’re laying out items in a row or a column. If you need control in both directions at once (rows and columns), that’s when Grid is the better choice.

Nesting different layout tools

Both Figma and CSS let you nest different layout systems. You might use CSS Grid for a full-page layout and nest Flexbox within sections or vice versa. There are no hard-and-fast rules — just a matter of choosing the right tool for the job. The world is your oyster.

The Overlooked Detail Every Designer Should Know: Explicit vs. Implicit Grids

One last key point: explicit versus implicit grids. In Figma, we work with explicit grids, defining every row and column. CSS Grid, however, can also create an implicit grid when you don’t determine everything, automatically generating rows or columns based on the content. This is especially useful for dynamic layouts, like blog feeds or product listings. As designers, we control the explicit grid, but understanding the implicit grid helps you know when to let the browser fill in the gaps, ensuring your designs scale and adapt in real-world use.

As UI designers, the explicit approach feels natural — it’s what we see and control. But the implicit grid is quietly powerful. It steps in when content goes beyond defined, letting layouts adapt on the fly. That means your design can look perfect in Figma but behave differently in the browser because the browser is filling in the gaps for you.

That’s why it’s so important to be aware of this. It’s not just about how things look — it’s about how they scale and respond in real-world use. The implicit grid can impact spacing, alignment, and overall flow in ways that aren’t always obvious until you’re in the browser.

So let this be a reminder: layout isn’t just a visual task — it’s a shared space between design and development. Don’t just talk to your Figma file. Talk to your developers too. That’s when the real magic happens.

There is so much more!

We just scratched the surface, and if you want to dive deeper, here are some great free resources I highly recommend exploring:

• Why UI designers should understand Flexbox and CSS Grid
• Modern CSS Layout for UI Designer
• Figma Grid Deep Dive
• CSS for UI Designers: Understanding Flexbox and Applying it to Figma’s Auto Layout
• Layout Land by Jen Simmons
• Layout & Grid in Design Systems by Brad Frost
• Gridless Design by Donnie D’Amato
• Container Queries by Miriam Suzanne
• CSS Subgrids
• CSS Grid Specs
• Flexbox Specs

Like this article?

I’m always eager to hear your thoughts! Please feel free to share feedback or let me know if there’s something I should cover in more detail.

Remember to subscribe on Medium and follow me on moonlearning.io, my Newsletter, Twitter, or LinkedIn for more insights on UI Design, Figma, and Code.

Make sure to check out my courses, where I also offer deep dives into Layout with Figma and Code.

moonlearning

Figma’s new grid — you must understand CSS Grid as a designer was originally published in UX Collective on Medium, where people are continuing the conversation by highlighting and responding to this story.