My terminal setup these days is cmux layered on top of Ghostty, so I can run multiple workspaces side by side without losing my place. Most of my actual work happens there now, as the primary surface.

MC Dean spent real time building UIs for her designpowers agents, looked at what she’d made, and tore them down:

I’d taken something that was direct, alive in a particular way, that would show you its thinking if you let it, and I’d dressed it up. Made it presentable. Wrapped its reasoning inside a crisp ui. In doing that I’d introduced distance between the person using it and the thing they were actually talking to and trying to collaborate with. I’d made it more comfortable, predictable and less true. I killed the delight of using designpowers.

Dean on why she killed it:

The GUI was scaffolding. Brilliant, necessary, world-changing as an innovation, but nonetheless created around a fundamental limitation so invisibly useful that we forgot what it was for.

The scaffolding was for humans who couldn’t speak the machine’s language. When the machine starts speaking ours—even partially, even just inside certain conversations—the scaffolding becomes friction for anyone trying to learn how the underlying system actually thinks.

Dean then connects this back to design craft, instead of letting it become a “designers should learn the terminal” finger-wag:

Designers are really good at this important way of thinking already. Every time you decided how an error message should make a person feel. Every time you chose what to surface and what to hide. Every time you designed for the person who didn’t fit the assumed user, you were encoding values into a system. That work doesn’t go away when the interface does. It moves upstream, into the reasoning layer itself, and it has no canvas. That’s design literacy for the world that’s coming.

Dean’s argument pairs with the other end of the same expansion: designers gaining authorship downstream in the code. The easing curve and the hover state at one end; what the agent gets to surface and who counts as the assumed user at the other. The reasoning layer is the upstream end without a canvas to hide behind.

Nick Babich asks if the old surface still earns its place. Dean is pointing at where the new surface already is.

Dean closes with:

We are early enough that the agents are still legible. You can still watch one think. You can still feel the shape of how it reasons before it’s been wrapped in chrome and shipped with a logo.

That window is why I bother with cmux at all. Ghostty by itself is already a genuine pleasure to use; cmux lets me keep a Claude Code session running per project without losing context when I switch. Just enough plumbing to make watching agents think a habit rather than a stunt. Dean’s right that the legibility won’t last. Worth being here while it does.

Nick Babich, writing in UX Planet, takes inventory of where Figma still earns its place once teams stop treating the mockup as the deliverable:

One thing is clear: the conventional process in which UI and UX designers spend hours and days pushing pixels to create perfect layouts is no longer the reality for many organizations. The reason is simple: in the AI era, time-to-market has become a critical metric, and most companies would rather ship a “good enough” product quickly than spend extra time perfecting every detail.

The concept of Figma as a design tool originated from the conventional design process. You could say that Figma is an almost perfect design companion for designers who follow a traditional UI/UX workflow.

But the problem is that the conventional design process is no longer the reality for most organizations.

Organizations that embrace rapid prototyping are switching to tools that allow them to build and ship quickly. Instead of starting with static UI mockups in Figma, they jump straight into the prototyping phase using tools like Claude Code. In this phase, teams create coded prototypes that later evolve into fully functional products.

Figma’s role is narrowing from everything-tool to exploration-and-iteration tool, and narrowing is not the same as dying. Babich is now drawing the lines around what that specialized future actually looks like: design systems (especially the ones already living in Figma), complex enterprise workflows with real business logic, and the brand and visual-identity work where taste is the whole point.

On Figma Make, Babich is blunt:

But the problem is that Figma Make is still nowhere near tools like Codex or Claude Code in terms of output quality and overall user experience. Claude Code and Codex are significantly more capable, flexible, and comfortable for rapid product development workflows. Even for simple tasks like creating a prototype of design imported from Figma, Make tends to add a lot of visual defects.

I scored Figma Make 58 out of 100 at launch. It has improved since, but Babich is right about the gap. Make is competing against tools that were born for code generation against a working repo; Make was retrofitted onto a vector editor. That difference shows up in every prototype that looks fine until you zoom in.

On design systems, Babich:

In other words, you don’t necessarily need to maintain your design system in Figma; as long as you can provide access to a GitHub repository containing your design system, you’re in a good position to generate consistent interfaces.

If the design system can live in the repo and the agent can read it directly, the Figma library becomes a mirror rather than the source. That doesn’t kill the Figma file. It does change who has to maintain it and why.

Open four agent windows at once and the day disappears in a way that feels productive but isn’t. David Hoang, writing in Proof of Concept, puts it plainly:

At times, HITL [human-in-the-loop] agent orchestration feels addictive like Candy Crush or scrolling social media. Every prompt shows a stream of tokens and visible progress being made. You sit and wait to hit the number 2 or continue prompting. Instead of doom scrolling, you’re doom building; a sense of productivity which leaves you not doing anything else.

To be abundantly clear, I’m not against HITL and it’s a great way to build. What I’m saying is the massive productivity gains take a toll on you. I’ve shipped real work this way; being locked in for entire afternoons and evenings to prompt sessions. Sometimes I get good outputs and other times I don’t get anything valuable.

The orchestration tax is like the coordination tax at work. I’m feeling like I’m building but really air traffic controlling in parallel. You are reading partial outputs, deciding which to merge, which to discard, which to re-prompt. It’s a job, and an important one, but it’s not the deep work in design, writing, or thinking I need to do. That is a real job. It is not, however, the same job as design or writing or thinking. It uses a different part of you and it depletes a different reservoir. By the time I sit down to actually draw something or write a paragraph that matters, the reservoir is empty.

I orchestrated my way out of having anything to say.

Hoang’s analogy to coordination tax—the meeting load that eats the day at any tech company—is exact. Watching a token stream and deciding what to keep is real work. It is not the work you sat down to do. Orchestration spends from the same reservoir or account that making spends from, and you do not feel the withdrawal until the end of the day when you go to write the paragraph and there is nothing in the tank. Hoang’s tactical answer is to switch defaults: human-in-the-loop for the few things that benefit from your synchronous attention, human-on-the-loop for everything else, with a real review block on the calendar.

The shift is from watching to bracketing. Agents need start conditions and end conditions, not a babysitter in between.

Brandon Harwood opens with Picasso’s Guernica. He asks you to look at the painting, then tells you the story behind it—the bombing of the Basque town, the civilian deaths, Picasso’s intention to communicate that horror—and asks you to look again.

If you didn’t know the story of this painting beforehand, now you do, and it might strike a different chord, if just slightly. The details of the painting now have the context that shows us what Picasso was thinking when he painted Guernica. […] It’s this kind of context that drives meaning in art. Guernica is not just a painting. It’s communication.

Harwood uses it to draw a line between what AI can generate (the aesthetics of a thing) and what humans build (the context that makes a thing communicate). His answer: instead of asking AI to make meaning, design around the fact that it can’t.

Meaning Machines are, at their core, “signifiers, randomized into a fixed grammar, and read for new meaning.” […] The randomized signifiers are the contextual data surrounding our creative pursuit, the data the AI is trained on, and the relationships built on that data through its training. These signifiers, the data, are then placed into a fixed grammar through agentive interaction and/or agentic actions, and the user can then interpret the result to stimulate their creativity, build new meaning, or explore ideas they might not have considered before.

Tarot doesn’t know what your week looks like. Oblique Strategies doesn’t know what song you’re stuck on. The cards work because they hand you raw material and you do the interpretation. Harwood’s claim is that an LLM, used right, can sit in that same chair. Provoke the human. Dr. Maya Ackerman calls this same arrangement “humble creative machines”: the AI is not the creator, it’s the prompt the creator responds to.

Harwood breaks co-creative AI into three roles:

The Puller: The AI system gathers information about the context the user is working in through active question generation and passive information collection on the works. […] The Pusher: The AI system uses some/none of this context to synthesize considerations for the user to employ throughout their creative journey. […] The Producer: The AI system creates artifacts for use as elements of the users’ larger creative output.

The Puller / Pusher / Producer vocabulary is what I wish more design teams had before they shipped their first AI feature. Each role is a constraint, a way to keep the human in the chair the work actually belongs in. Most AI tools for creatives flatten all three into one button that produces a finished thing. Harwood’s whole argument is that the finished thing is where the meaning has to originate; it can’t be the destination.

Peter Yang spent the last few months running OpenClaw, Hermes, Claude Code, Codex, and Gemini through ten capabilities he thinks a personal AI agent needs to handle. The headline is in his subtitle: nobody has won yet.

Yang on OpenClaw, an open-source personal-agent platform:

I estimate that 10% of my time with OpenClaw is spent fixing it instead of using it. Examples: It forgot it had access to edit Google Docs. It randomly started using a robot voice instead of the one I like. It breaks half the time after every update.

He switched to Hermes (a newer personal-agent platform from Nous Research) anyway:

If OpenClaw’s maintenance tax is wearing you down, give Hermes a try. A week in, it’s been more reliable for me.

Yang’s full comparison of Claude Code, Codex, and Gemini—plus the stack he ends up running—is in the post. His advice for the rest of us:

Pick one or two agents that work for you based on the pros and cons above and just commit.

His promise to anyone who picks one and stays:

Once you have an agent that’s available 24/7 and can actually get work done for you, you’ll never go back to a regular AI chat interface again.

Luke Wroblewski shared his notes from the Design Futures Assembly, a gathering of about a hundred senior designers and leaders from AI labs, big tech, and startups in San Francisco:

When everyone can ship, you get a different kind of problem. One design leader described it perfectly: they let everyone build and push whatever they wanted. And you could feel it in the product, because nothing made sense together.

This is the part of the AI-in-design story that the toolkit numbers obscure. Wroblewski reports roughly half of designers had shipped AI-generated code to production this year, and that the typical designer’s toolkit had doubled in size over twelve months. Those are real numbers. But once production stops being the bottleneck, the bottleneck moves. A single word surfaced repeatedly:

Several people at the assembly used the word “editorial” to describe where design leadership is heading. Less about making the thing, more about deciding what gets made and ensuring it all holds together. The skill of saying no is becoming one of the most important skills in the profession.

The “saying no” line echoes something Chad Johnson wrote a few weeks back: the designers who shape direction “learn to say no with evidence and to disagree without drama.” The Assembly’s framing makes that posture mandatory at a portfolio level, not just on individual features. One tool company founder, Wroblewski notes, preferred “coherence”: the sense that a product came from one shared point of view. I like that word better too. Coherence describes the thing the user actually feels.

Thariq Shehzad, on the Claude Code team at Anthropic, has switched from markdown to HTML as his default agent output format. The reasoning is more honest than a format-war argument would suggest, because it’s about what humans will actually read. He opens by acknowledging what markdown was for:

Markdown has become the dominant file format used by agents to communicate with us. It’s simple, portable, has some rich text capability and is easy for you to edit. Claude has even gotten surprisingly good at using ASCII to make diagrams inside of markdown files. But as agents have become more and more powerful, I have felt that markdown has become a restricting format.

Then the pivot:

As Claude is able to do more complex work, it is also writing larger and larger specs and plans. In practice, I’ve found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it. But HTML documents are much easier to read, Claude can organize the structure visually to be ideal to navigate with tabs, illustrations, links, etc.

When the spec gets long enough that you stop reading it, you’ve quietly moved from review to rubber-stamp. Shehzad’s answer isn’t to ask Claude for shorter specs. It’s to make the artifact something a human will actually open, scroll, and share. A controllable, shareable artifact is most of what made personal computing legible in the first place; HTML is the format that already does it.

He puts the trade-off honestly when the obvious objection comes up:

While markdown often uses fewer tokens, I’ve found that the added expressiveness of HTML and the much higher likelihood of me reading it means I get overall better output. With the 1MM context window in Opus 4.7, the increased token usage is not really noticeable in the context window.

And the close is the real argument:

The real reason I use HTML is that I feel much more in the loop with Claude. I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I am happy to say instead that I feel more in the loop than ever before when using HTML.

Owen Williams, a design manager at Stripe, sat down with Claire Vo on How I AI to walk through Protodash, the internal prototyping tool he has spent the last eighteen months building. What sticks is what Protodash has done to the handoff. Williams, describing the Radar fraud-detection team:

They literally have a pull request of a prototype that I had I see an engineer working on and I’m like this has never happened ever in my career as a design manager. They’re like “I’ll just use the prototype as the source of truth” and they can just take it and do that. There’s a huge change — not having to red line a Photoshop file or all of that stuff.

That’s the part that matters. The prototype is the code, in the same components, ready to be picked up. Protodash gets there by constraining generation: a bundle of Cursor rules, a router and chrome scaffold, and Stripe’s design system (Sail) exposed via an MCP server. The off-the-shelf tools—v0, Cursor by itself, Claude Design—produce what Williams calls “blurple slop” because they hallucinate components. Wire the generator to the actual system and the output stops looking like a Tailwind demo and starts looking like Stripe.

The fidelity jump changes the room, too:

It’s sort of been this very transformative thing because all of a sudden I’m sitting in these design reviews and it’s so convincing that I’m like, is this the real product or am I looking at something fake?

This is what Tara Tan predicted: the moat in AI design tooling is the design-system graph, and whoever makes that graph machine-readable for agents wins the enterprise. Stripe just did it, internally, with a homemade stack, meaning it’s really an uphill battle for anyone trying to make a generic tool for this use case.

The interesting thing is who shows up to use it. Williams says Protodash is now used more by PMs than designers; PMs paste a PRD from Google Docs and get back a working flow before designers are pulled in. That tracks with the Figma Make case studies — PM-led prototyping isn’t theoretical anymore.

Williams is clear-eyed about what the tool can’t do:

How can I make sure that the tool knows enough to be dangerous? It gets to 80%. But like that taste, that craft is like, that’s why designers will always exist, in my opinion. Like they know how to elevate the experience. Like this thing knows how to use the components. The components are well designed, but it’s not going to be perfect. And we are here to steer them.

Talking to Peter Yang, Ravi Mehta—former CPO of Tinder, now teaching AI prototyping at Reforge—walks through a live demo of building the same Spotify-style genre page three different ways. The first attempt uses a short functional prompt and produces something that, in Mehta’s words, kind of feels like AI slop. The third uses what he calls a full-stack context bundle: a functional spec, a 20-minute Figma wireframe, and a JSON file of real album data pulled together in Claude with an MCP server. The output is night and day.

His definition of the shift:

Context engineering is designing and building systems that provide an AI model with the right information and tools to accomplish the task. And I think a lot of the common mistake I see with prototyping is people don’t think about context within that 360 degree way. And as a result, people just, you know, write a quick prompt or a quick little mini spec and expect the prototype tool to be able to create something as high fidelity as what they used to create before when they had all of these different artifacts that are a critical part of the product lifecycle.

That definition will sound familiar to anyone who saw Philipp Schmid’s framing of context engineering when it first circulated. Same emphasis on “right information and tools.” It’s the working definition the field has settled on. What Mehta adds is the concrete answer to “okay, what are the three things you actually have to assemble?” Functional context (a spec), visual context (a wireframe), and data context (real structured JSON, not lorem ipsum). Skip any of them and the prototype either looks generic, behaves wrong at edge cases, or breaks suspension of disbelief the moment a real customer touches it.

The piece I want to underline is his defense of visual thinking, because the “designers are obsolete” takes haven’t stopped, and Mehta gives them a clean rebuttal:

So if you start to think differently about the different types of context that are available, you can actually get much more specific and have a lot more control over what gets built and build something that’s a lot more robust. This is functional context. The next level that is really important is visual context. […] And so here, I very quickly in Figma, just taking 20 minutes, done a wireframe, and sort of outlined what I want this interface to look like. […] The prototype needs to have a level of fidelity that’s hard to get with sort of traditional prompting techniques.

Twenty minutes in Figma, then a short prompt that says “use the attached wireframe.” A wireframe does what a 17-page PRD and three rounds of trying to describe a layout in English to the model can’t. The wireframe is part of the input to the deliverable now.

The corollary cuts the other way too. If the wireframe is now an AI briefing document, the people who can produce a decent one in twenty minutes have a real edge over the people who can’t. That’s still designers, still us. It’s just that the wireframe now feeds the model directly, not only the engineer reading the spec next sprint.

I wrote about this whole family of files in my recent newsletter: DESIGN.md, SKILL.md, SOUL.md, the markdown artifacts you write so an agent can read them. Nick Babich has the practitioner walkthrough for the DESIGN.md flavor of it, specifically the version that Google Stitch reads when it generates a screen. He describes the format directly:

DESIGN.md is a markdown file with two layers: YAML front matter that contains machine-readable design tokens (exact hex values, font properties, spacing scales) and Body that features a human-readable design rationale.

The two-layer split is right. The YAML is the part the agent can’t argue with: primary: "#d97706" is #d97706. The body is where you tell the agent why, and it has to be written like prose, not a config file. Babich’s philosophy section is where I’d point a designer who’s about to write their first one:

Unlike a traditional specification that often has very specific details that designers should follow when crafting a new design, DESIGN.md is less prescriptive in its nature. It creates a solution foundation for AI tools (colors, typography, corner radius) while providing enough freedom to alter the format for domain-specific needs. Another thing is that DESIGN.md is a living artifact, not a static config file. It should evolve as your design evolves.

The “less prescriptive” line is counterintuitive. You’d think the whole point of feeding rules to an agent is to be more prescriptive, not less. But Babich is right about the shape: pin down the tokens, leave the application loose, refine the file as the agent surfaces edge cases you didn’t think about. These files hold what we used to keep in our heads and call taste, and you don’t write taste like a requirements doc. You write it like a brief, and you keep editing it.

PJ Onori built a tool that A/B tests his design system against AI agents, and he’s careful to say it isn’t impressive:

Two groups of agents get spun up, and both are given the same prompt to make an interface. One group’s given the old design system. The other is given our new one. Each agent provides feedback on problems faced after it’s done. Once all agents finish, the builds are evaluated on a bunch of crap and a report is generated.

The list of what the tool measures is long: timing, lines of code, code variance, fix attempts, components used, accessibility, performance, inline styles, visual diff, token usage, agent feedback. Onori, on the test he ran when he wasn’t sure his documentation was actually doing the work:

I was starting to question if documentation was making things better. Maybe component improvements was doing the heavy lifting–who knows? So, I ran a couple tests without documentation… The documentation was clearly the heavy lifter. […] Documentation is essential for systems that agents don’t have a lot of reps with. I’ve started to add a “For agents” section in the docs. That section is the dumpster for “get it in your silicon head” training.

The “For agents” section is a small idea with a real implication. Documentation has historically been written for one audience. Now there are two, and as Onori says elsewhere in the post, the second one needs “the same damned point” repeated five or six times and doesn’t care if the prose is ugly. His instinct is to wall that off so humans don’t have to read it.

Onori is publishing measurements where most people are publishing takes. That’s the missing piece in the design-system-as-moat argument: somebody actually testing whether agents do better with a well-built system than a worse one, and showing the numbers. Onori, on the closing caution:

There’s a lot of noise in the output, feedback, and analysis–otherwise know as everything. That noise compounds fast. Think of the telephone game–then think about what that’d do to a design system. […] Feedback needs to go through a BS filter. […] The feedback part of the analysis is helpful. Make no mistake. But it needs to heavy interpretation.

The telephone game is the right picture. A design system that updates itself based on agent feedback that’s been generated by other agents and analyzed by a third agent is going to drift somewhere strange in a small number of iterations, and nobody on the team will be able to reconstruct why. Onori’s tool stops short of that on purpose: it produces measurements, and a person reads them.

Nick Babich on agents in UX Planet. A useful pair to his earlier writeup on Claude skills, since the two words get used interchangeably and they are not the same thing. Babich opens with the plain-language version:

Think of an AI agent as a program you run when you need to solve a particular problem in design. For example, you can create an AI agent that helps you with usability testing, code review, UI/UX audit, etc.

A program you run is the right mental model. A skill, the way Babich described it in his earlier piece, is a recipe: a markdown file Claude reaches for when a task matches. An agent is what runs once Claude has the recipe in hand. It carries state across steps, picks tools, reports back.

Babich’s four attributes of a well-designed agent get at that distinction without saying it out loud:

1. Good clarity (intent alignment). A strong agent understands what success looks like, not just the task. This understanding helps it translate vague prompts into clear objectives.
2. Context awareness. Good agents maintain and use context effectively. Not only do they remember previous steps, constraints, and user preferences (which is well-expected behavior nowadays), but they also adapt output based on the environment (tools, data, stage of workflow).
3. Tool orchestration. Agents can perform the workflow autonomously and they have the ability to use the right tools for a task at hand is what makes an agent so powerful. Well-crafted agents can chain tools together into workflows, and they don’t overuse tools when simple reasoning is enough.
4. Explainability (transparent reasoning). When you interact with an AI agent, you need to understand why something happened. Thus, an AI agent should provide a rationale behind decisions surface assumptions, and trade-offs.

Context awareness and tool orchestration are what separate an agent from a prompt template. A skill can ship intent alignment and explainability in plain markdown, but state across steps and the ability to chain tools require a runtime. That’s why Babich’s specs include Boundaries sections and “When Not To Use It” blocks: a stateful, tool-using program needs guardrails that a one-shot prompt does not.

If you haven’t built one yet, his five specs—Research Synthesizer, Competitor Intelligence, Problem Definition, Idea Generation, UX Flow Designer—are a clean starter pack. Pick the one closest to a workflow you already do by hand, and notice how much of the spec is about what the agent will not do.

Tommy Geoco spent ninety days and $13,100 tinkering with OpenClaw. His agent runs his capture loop, prepares his meetings, codes the survey for the state-of-prototyping report his studio shipped, and distributes his content across ten platforms. Tom describes the harness like this:

When you install OpenClaw, it is like a starter kit project car. It is a car frame with a swappable engine. The engine being any AI model you choose to use. It is basically a folder that you install onto your computer that contains about seven markdown files. […] When you stop thinking of a custom agent as just a chatbot and start thinking of it like an operating system, some useful questions are going to start to pop up like where does the memory live? What is the source of truth? How do I enforce my rules better? What should stay manual?

The seven files are plain text. soul.md holds the agent’s voice and judgment, agents.md defines permissions, memory.md handles long-term recall, and four others cover identity, the user, tool instructions, and a heartbeat. Tom layers an Obsidian vault on top as long-term knowledge and Slack as the chat surface. Tom on what actually limits an agent:

The agent’s limitations aren’t just about the model. They’re a lot more about the system that you have built around it because you can’t control the quality of the model, but you can control the quality of the system. […] The most important part of my setup is the knowledge vault. This is my alternate memory, and it is built around the work that I actually do.

Geoco says curation is what keeps the whole thing from drifting. The agent runs the loops on top of a vault Geoco curates, and the taste lives with him; the model itself is interchangeable. The challenging part is somewhere else entirely:

The most challenging part of this whole thing is the unlearning. Many of us have old habits that have calcified into our brain. It is why my 17-year-old is able to run laps around us. He has no baggage about how things are supposed to work.

Geoco is right that the unlearning is where the difficulty lives. The harness is just markdown and the model is rented; the orchestration skill Benhur Senabathi described as what designers actually picked up in 2025 is what you practice through the unlearning. Geoco closes the video by saying nobody’s harness is right and everybody’s works for them, which sounds about right to me too.

Maggie Appleton, staff research engineer at GitHub Next, wrote up her recent talk on agentic AI productivity. (Video here if you’d rather watch.) Her central claim comes early:

I call it this “one man, a two dozen claudes” theory of the future. The pitch here is that one person with a fleet of agents will do the work of an entire team of developers. The main problem with this dream is it assumes software is made by one person. All these tools are single player interfaces. […] Software is not made by one person in a vacuum. It’s a team sport. Everyone building it needs to agree on what they’re building and why.

The single-player critique is the missing piece in most AI productivity takes. Most demos of a coding agent show one engineer at a terminal. Designers face the same situation with AI prompt-to-code tools. Collaborating isn’t as easy as sharing a Figma link. That’s the actual gap in current tooling, and it’s downstream of the single-player assumption.

Appleton’s second move:

Implementation is rapidly becoming a solved problem, right? Writing code is now fast, it’s getting cheap, and quality is going up and to the right. The hard question is no longer how to build it. It’s should we build it. Agreeing on what to build is the new bottleneck. […] When production is cheap, opportunity cost becomes the real cost. You can’t build everything, and whatever you pick comes at the cost of everything else.

When production is cheap, picking what to make becomes the whole job. The cost difference between two engineering paths is now nearly zero, so the choice between them carries all the weight. Teams that miss this will end up shipping volume and mistaking it for productivity.

A talk like this could be about tooling, and Appleton does walk through Ace, GitHub Next’s prototype multiplayer workspace, in some detail. But the more important argument is about what you do with the hours you free up. Going faster is not the prize. Appleton:

We have an opportunity to not just go faster and build a giant pile of the same crappy software. But instead to make much better software through more rigorous critical thinking and better alignment in the planning stage. By doing more exploration, more research, and thinking through problems more deeply than we could have before.

The reclaimed hours are an opportunity, but they are also a test. Do you spend them shipping more, or do you spend them shipping better? The first answer gets you the giant pile. The second takes work the agents cannot do for you.

Appleton closes on craft:

Many people are now realising that in a world of fast, cheap software, quality becomes the new differentiator. The bar is being set much higher. Craftsmanship is what will set you apart from the vibe-coded slop. But craft still costs time and energy. It is not free, and in order to buy the time and energy for it, you need to do fewer things better, which requires strong alignment.

Karri Saarinen, Linear’s co-founder, calls out the confusion that most of the new design tooling is built on top of:

Design keeps being misunderstood in our industry. New tools keep promising to generate interfaces faster, move words to product instantly, or collapse design directly into code. The assumption behind them is clear: that design is the act of producing. That is the misunderstanding. The hard part of design is rarely generating the form. It is understanding the problem well enough to know what and how something should exist at all.

What I appreciate about Saarinen’s argument is that he doesn’t stop at the diagnosis. He reaches for Christopher Alexander’s Notes on the Synthesis of Form and recovers a vocabulary term the industry has been missing:

Christopher Alexander came closer than anyone to naming this clearly. In Notes on the Synthesis of Form, he describes design as the search for a good fit between a form and its context. Context, in his sense, is not a background condition. It is the full set of forces that make a problem what it is: human needs, technical constraints, conflicting requirements, habits, edge cases, and relationships that are easy to miss until you spend time with them. Bad design appears where those forces remain unresolved. Good design appears where those misfits have been worked through carefully.

Context as forces, not background. The current generation of prompt-to-code tools, including Lovable, Figma Make, and Claude Design, is very good at producing a plausible form against a thin slice of context. Saarinen describes the symptom directly:

You can already see the result in products that look polished, ambitious, and impressive at first glance, but begin to unravel the moment you actually use them. They feel brittle, poorly integrated, and full of decisions that were never fully worked through. The form is there. The fit is not.

That same bottleneck shows up on the workflow side: production speeds up, judgment doesn’t.

Saarinen’s closer:

The risk is mistaking generated form for solved problems.

That is the mistake to watch for, in your own work and on your team. Design is what happens when someone takes the time to understand the forces and works the misfits out of the form.

Here’s a quickie. Interaction developer David Aerne created a fun, Tempest-inspired Unicode character explorer called Charcuterie. Click a character to see visually-similar ones. You can even draw a symbol in the box in the upper left corner. Super fun.

Tara Tan surveyed more than a dozen AI design tools for The Review. Her field audit sits alongside the design-process compression argument:

In working with these tools, one insight emerged for me: the tools that understand your design system produce better output than the ones that don’t. […] The competitive moat in this market is not generative quality, which is commoditizing fast. The moat is the design system graph: the tokens, components, spacing scales, typography rules, and conventions that make your product look like your product and not a generic template. Whoever makes that system machine-readable for agents will win the enterprise.

That’s the operational reason my proposal for an agent design team hinges on a rock-solid design system. What distinguishes output across the tools Tan surveyed is whether the generator respects your existing design system or treats every request as a fresh mood board.

Tan’s other finding is the role-shift:

The same shift is happening in design. At Uber, Ian Guisard didn’t stop being a design systems lead when uSpec automated his spec-writing. His job shifted from producing documentation to encoding expertise, writing agent skills, defining validation rules, deciding what “correct” means for each component across seven platforms. The human became the system designer, not the system operator. […] The canary is singing. And the song is about the work shifting from execution to judgment, from operating the system to designing the system itself.

Same title, different job. Ian Guisard’s taste still matters; it lives in the skills and validation rules now, not the deliverables. That’s “follow the skill, not the role” made concrete. Guisard used to write specs; now he writes the rules the system follows to validate them.

The infrastructure is catching up to the process. Tan’s implicit prescription is straightforward: make the design system machine-readable, win the enterprise. Some of that tooling is already out in the open. Southleft’s Figma Console MCP (which Uber’s uSpec is built on) lets agents operate on tokens and components without a custom platform.

But tooling alone isn’t enough. Most of us aren’t Uber. The path for teams without a dedicated design systems lead still needs someone to do the work Guisard did: encoding the expertise and defining what “correct” looks like across platforms. That’s where the next round of tooling needs to land.

Specialization is the whole game. Give an agent a specific role and clear constraints, and the quality of the output changes completely. I’ve been learning this firsthand with Claude Code skills.

Marie Claire Dean took that principle and scaled it into an open-source system called Designpowers. Her reasoning:

Most AI tools give you one assistant. You ask it something, it answers, and you figure out what to do next. That’s not how design teams work.

Design teams work because a strategist thinks differently from a visual designer, who thinks differently from a content writer, who thinks differently from someone doing accessibility review. The handoffs between those perspectives are where the work gets better. The friction is productive.

Her team of ten covers the full pipeline from discovery through shipping, with dedicated specialists for strategy, visual design, content, motion, accessibility, and critique. All sharing one design state document, with the human directing.

On what she learned building it:

The act of encoding a design process forces you to decide what the handoffs actually are. When does strategy end and visual design begin? What does the content writer need from the strategist before they can start? What happens when the accessibility reviewer and the design critic disagree?

That’s the same clarity I’ve found writing Claude Code skills: what does this agent need to know, and where does its scope end? On where the human stays essential:

The idea is simple: agents can verify that a design is correct, aligned to the brief, accessible, consistent. They can’t tell you whether it’s beautiful. That’s your job.

The full system is on GitHub.

Nate Parrott, a product designer at Anthropic, in an interview with Ryan Mather for AI Design Field Guide:

More Google Docs than you’d think. More Slack posts than you’d think. I meant what I said earlier: I think that this is the era of designers who design with words more so than designing with pixels.

Parrott describes a content design team whose job is making alien concepts legible:

We have several people at the company on the design team whose job is content design. Their job is basically to look at concepts which are very alien, and figure out how to make them legible to human beings. They don’t draw any pixels, but their work is really important because they are literally thinking about the words we use to describe and the mental models we expect people to put on that will make this stuff work.

The Figma work, Parrott says, is “the easy part.” He uses Anthropic’s design system, drops in components, and moves on. The hard work is upstream: expressing the ideas, figuring out the right language, talking to users. The production of screens has become the smallest slice of the job.

Jenny Wen described designers at Anthropic shipping code, prototyping against the live model, stretching into PM territory. Parrott is describing the same shift from a different angle. The deliverable used to be the mockup. Now the deliverable is the thinking that precedes it.

Stripe design manager Kris Puckett, speaking on Michael Riddering’s Dive Club, spent the first half of the conversation demoing metal shaders, custom ocean animations, and a full iOS reading app he built with Claude Code. Then he stopped himself:

AI native has to be beyond just “I made a really cool shader” or “I made this dither effect that every other person is making.” I was doing that today and then I was like, “Oh my gosh, this is… why am I doing this? There’s a hundred of these that are way better than what I’m making right now.”

So what does AI-native design actually look like? Puckett’s answer is “soul”—the quality that makes work feel specifically, unmistakably yours:

I think what people are going to be desperate for is more of that human side of things. They’re going to be longing for […] an era they’ve never experienced because they’re younger, that MySpace generation where your MySpace page was deeply personal to you. My MySpace page was complete custom Kris Puckett perfection at that time. And I think that we’re going to want to see that come back. And I think people are going to want more of those—your portfolio looks and feels like you.

“Soul” is doing a lot of work as a concept there. What Puckett is describing sounds a lot like taste—the ability to make something that feels intentional and specific rather than procedurally generated. His workflow backs that up. Being contrarian, he explicitly rejects the “let the agent run” approach:

I want off that cycle. I do not want to be riding that bike race with anyone else because that’s not how I view these things. They are a force multiplier, but I want them to be focused. I want it to be something that I feel is still authentically me.

What unlocked all of this for Puckett wasn’t technical skill—he’s a designer, not an engineer. It was admitting “I don’t know” and starting anyway. He’d been dreaming of building his own software for 20 years. Claude Code’s blinking cursor was enough to get him started.

Figma is opening its canvas as a writeable surface for AI agents. Matt Colyer, product director at Figma, on why this matters:

Design decisions—from color palettes and button padding, to typography and interactivity—have always defined how products take shape. No matter how small, those decisions add up. They make your product and user experience stand out from the rest. To date, AI agents haven’t had this context, which is why so many designs created by AI often feel unfamiliar and generic.

The fix is beefing up skills files, by encoding a team’s design decisions, conventions, and sequencing rules. Agents read them before they touch the canvas. The use_figma tool lets Claude Code, Codex, and other MCP clients create and update assets tied to your design system. Colyer on what that changes:

Your conventions are no longer static documentation. They become rules agents follow as they work—applied through components, variables, and the structure you’ve already defined.

The detail worth paying attention to is what Colyer describes as a self-healing loop. When an agent generates a screen, it screenshots the result, checks it against the design system, and iterates. Because it’s working with real components and auto layout, those corrections compound through the system itself, not just the pixels on screen.

It’s free during beta, with plans to move to a paid API. Figma is finally joining the party as Subframe, Paper, and Pencil all offer this workflow already.

Gui Seiz designs at Figma. His team uses Claude Code to bridge design and code. And he still reaches for the canvas when precision matters.

Seiz, speaking on Claire Vo’s How I AI podcast:

I don’t think we’re there yet in general with these code tools in terms of the precision editing that you want to do. […] I think still the gold standard for me is just being able to drag stuff around. And you can do a lot with a click that would take you a hundred words to write and to really precisely nail. No one wants to prompt for the exact hex code or the shade of yellow and that kind of stuff. That’s just easier to just quickly do and directly manipulate.

Seiz isn’t anti-AI. His team pulls production code into Figma via MCP, edits it visually, and pushes it back to the codebase. He’s bullish on what that does to the old workflow:

It’s definitely changed our workflows in a way that it’s really blown up what a workflow even is. Before, for the majority of our careers, we’ve had a very linear, agreed-upon workflow where you increase fidelity as you go on. Because it’s really expensive to work in code, and it’s really cheap just to trade ideas and sketch them out. But AI basically collapsed that, and it’s just as cheap to riff in code as it is to riff in design.

The cost of exploration collapsed. The need for direct manipulation didn’t. Both can be true.

I’ve argued that design tools should be canvas-first, not chatbox-first. Jeff, writing in Abduzeedo makes the case for the opposite:

Designers have always borrowed from developers. Version control, component systems, token-based design — these ideas crossed the aisle from engineering and reshaped how visual work gets done. Vibe designing follows the same logic. Instead of opening Figma and reaching for a drag-and-drop panel, designers drop into the terminal. They prompt an AI model directly from the CLI, pipe the output into a file, and iterate without ever touching a mouse.

He isn’t theorizing. He published this article using browser automation and AI, with minimal manual clicking.

I don’t think the answer is CLI or canvas. It’s both. Designers are visual thinkers—that’s the cognitive foundation of the discipline, not a limitation to engineer away. Going fully terminal assumes we can be retrained to work without seeing what we’re making, or that the profession will attract people with entirely different skills.

What does look right is the plumbing underneath. Jeff on Paper.design’s MCP integration:

Its canvas is built natively on web standards — HTML and CSS — which means AI agents working through Paper’s MCP server can read and write design files directly. Tools like get_screenshot, get_jsx, write_html, and update_styles give Claude Code or Cursor direct read-write access to the design canvas.

HyperCard figured this out in 1987: direct manipulation on top of a scripting layer. The tools are finally catching up, with AI as the scripting engine.