I wrote about who killed Google Reader because Reader’s shutdown felt like losing a whole way of using the web: the curation layer, the accidental social network, the daily habit. Matthew Guay, editor at Buttondown, is interested in the part that survived. His answer is blunt: nothing important died.

The feeds walked out intact: three million people moved to Feedly in two weeks, and the content never left the blogs. Guay’s point is that we were mourning the right thing—the curation layer, the accidental social network—at the wrong level of the stack: the aggregation service, not the open protocol underneath it.

Not an iota of data was lost, as the content that filled the feeds lived on individual blogs and websites. Google+ users wouldn’t be so lucky, six years later, when that network too was shuttered, taking with it their non-portable social graphs and ephemeral posts.

That contrast is the spine of the piece. Google+ and Google Reader died the same administrative death, both casualties of the same corporate pivot, but they died completely different technical deaths. Reader’s users lost a habit. Google+ users lost everything. The portability of the underlying protocol made the difference, and it’s why early RSS developer Dave Winer could be so clear-eyed about Reader’s shutdown at the time:

“I won’t miss it,” said early RSS developer Dave Winer more cantankerously—or, perhaps, more clear-eyedly—of Google Reader. “Never used the damn thing. Didn’t trust the idea of a big company like Google’s interests being so aligned with mine that I could trust them to get all my news.”

But that’s the thing about RSS. Winer didn’t need to love Reader for people to follow his writing there. And when it went away, those same readers could still follow him directly, could still read the words on his site that yesterday they’d read under Google’s auspices.

Designer and author Marcin Wichary picked up the same portability-survival thread in his blog Unsung, marking the 13th anniversary, and he quoted my February post in the process. His read: “I am worried about the open web, but excited seeing some resurgence in RSS usage, and more and more people wanting to come back to the feeling of control, care, and intentionality that using Reader represented.”

That resurgence Wichary is watching is what Guay’s closing points toward, too:

It was the open protocols, the RSS feeds and email, that alone offered a direct connection to your favorite writers and publications, unmediated by algorithms. Sure, they didn’t come with built in sharing features, they were harder to discover, they required more work to turn into a community. But once you did find them, they were sticky, a connection no one other than the publishers themselves could take away.

This blog is my version of that direct channel: a website, built one reader at a time, outside the platforms that decide what gets seen. I still miss Reader’s curation layer. The win is that the open-protocol layer underneath it—RSS, personal blogs, the direct connection—survived anyway.

We haven’t talked too much about AI and e-commerce here on this blog, but as much as any other area in our digital life, AI agents will change how we shop online.

Elizabeth Pizzuti, writing on the Automattic Design blog, explains the two definitions for how “agent” can be used in the e-commerce context.

The word “agent” is overloaded in 2026 commerce.

Two unrelated things share it:

1. Agentic commerce: AI shoppers buying from stores.
2. Agentic merchant operations: AI workers operating for the merchant.

The distinction matters because the two sides ask designers to make different things legible. On the machine-buyer side, Pizzuti’s first principle is basically agent readiness applied to commerce:

AI agents don’t browse websites like humans, they read structured data from the backend. Considerations here include providing an “AI readiness” score or dashboard for a clear, visual indicator of product catalog health, and a preview of how the AI agent sees that data. This demystifies the structure and allows the merchant to see exactly what an algorithm is evaluating. Additionally, make sure that context is part of the catalog—blog posts, buying guides, FAQs, and reviews all determine sentiment and trust and should be linked to the product schema.

For merchant-side coworkers, the problem flips. The interface is there to help a human judge whether the system did the right work. Pizzuti on the interface merchants use to judge and approve the agent’s work:

Designing for trust means exposing the agent’s backend homework. A merchant will never click “Approve” out of blind faith, especially in high-risk areas like pricing or inventory replenishment. Every automated recommendation must include the underlying context and trigger. Instead of “Drop price of item X by 10%”, the UI should show the reasoning chain:

• Observation: Competitor price drop detected.
  • Impact: Your listing’s conversion rate fell by 14% over the last 48 hours.
  • Reasoning: Lowering the price by 10% restores your competitiveness while preserving an 18% net margin.

That’s the right design shape for AI coworkers: controllable over perfect, with proof of work, a visible undo path, and enough context for the merchant to approve the change without pretending the system is magic.

Nolen Royalty, a software maker who writes at eieio.games, gets at a problem with AI-generated work that shows up before judgment: the effort signal. His examples include tldraw, the collaborative drawing tool, closing AI-generated pull requests, warm-cream Claude websites, and record collecting, but the point is simple. Polish used to be a proxy for care. Now it isn’t.

What software (and writing, to an extent) is missing now is legibility of effort - the ability to tell at a glance whether something took a human meaningful work.

Until recently, “someone cared enough to write this” was an ok heuristic. Plenty of writing on the internet was bad, but you could convince me that you cared about something just by writing it down.

Of course, generating plausible-looking text - or a plausible-looking website - is trivial now.

For designers, that broken proxy is already visible on the surface. We can all spot the default Claude style now, which is funny until you realize that a visual pattern has become an accusation about how much thought went into the site.

There’s nothing objectively wrong with making a website with a warm-cream background and hero text in a sans-serif font with a single accent word that uses an eye-catching color and a different font.

But when I see a website that has the default Claude style I assume that the author put ~no thought into how the site should look. And I often assume that the author didn’t put too much thought into the rest of the site either.

That’s not fair of me! But “someone made this website” is no longer enough to tell me that the website was important to them. So “default Claude style” is one of my new heuristics.

Taste sounds less mystical when you put it this way. A designer doesn’t make a screen human by avoiding beige or picking a stranger typeface. The work is in the decisions: why this hierarchy, why this contrast, why this interaction, why this amount of friction.

The proliferation of digital music and streaming made having a music collection easy and frictionless. And so a subculture evolved to re-add that friction.

And in small ways I think you see the same things happening now.

I’ve seen people joke about adding typos to emails to prove that they wrote them. MS Paint-style image macros read as more human than detailed, funny images (the image could be AI slop). Websites that look intentionally bad are more interesting than websites that look beautifully bland.

The easy story about AI in creative work is that it closes distance: idea, prompt, output, iteration, all compressed. It’s Nice That gets at the more designerly version of that question by putting creative technology’s appetite for “happy accidents” next to design’s need for control:

“From the technology approach, the metaphor I equate it to is the classic ‘happy accidents’ you have when you are in a design tool,” Seth says, finding expected moments of creativity. “The best happy accidents aren’t just between a person and a tool; they happen between people.” It’s perhaps in this notion that co-creation is at its most visible, not in the technology itself, but rather in the conversations and unexpected developments that occur when people with different perspectives work closely together. For Talia, however, this isn’t the case. “Nothing we do is experimental by nature,” Talia says, “everything is incredibly controlled – or, better yet, ‘designed’,” stressing the importance of the role of the designer and the meaning behind design itself. “Design is about creating solutions; there is a sense of control, there is a purpose, there is a function,” she continues, “even the beauty is controlled to a degree.” An example is the generative motion graphics system that Talia created, in collaboration with Mother, for the Crypto coin USDC.

Designer and coder Talia Cotton’s line clarifies the whole piece: “controlled – or, better yet, ‘designed’.” Cotton’s point is that the speed of generation only makes the designer’s eye more important, because someone still has to decide the boundaries before the machine starts producing variations.

Cotton’s USDC system makes that concrete:

Within the visual identity, Talia developed a custom tool that generated guilloché patterns, in reference to the historical patterns used in traditional finance. Alongside set, systematic parameters – including height, width, density, and speed – Talia had to create algorithmically constrained rules within those limitations. “As you adjusted one parameter, another parameter would automatically change its available range,” Talia says, “that ensured every possible output looked good.” As Talia suggests, especially considering the ease with which people can generate things, the “designer’s eye” is now more important than ever. “The designer’s job is to create an airtight generative system that considers every possible case and every possible output,” she says, “so that every single output always looks great, no matter how different it is.”

Karo Zieminski, in her newsletter Product with Attitude, is writing for builders, founders, and PMs, but the design translation is straightforward: AI fluency without critique is just a faster way to lose your ability to evaluate the output for yourself.

She draws the distinction:

Plain AI literacy means knowing how to use AI tools. It means learning to prompt, create automations, and bring AI into your workflows.

Critical AI literacy goes further. It adds systems awareness: understanding that AI is not just a tool on your screen, but part of a larger system of model choices, product decisions, business incentives, policy constraints, ethical tradeoffs, and human consequences.

Attitude is the posture that turns AI literacy into critical AI literacy.

That word, posture, matters. It is the same split in not outsourcing the learning: the tool doesn’t determine whether you get sharper or softer; the way you use it does.

Zieminski puts research behind that concern:

The data is on the table now. Microsoft Research surveyed 319 knowledge workers in 2025 and found that higher confidence in the AI is associated with less critical thinking, while higher confidence in yourself is associated with more. MIT Media Lab’s “Your Brain on ChatGPT” study measured the same erosion at the level of brain activity. The muscle is real, and it atrophies on schedule.

For designers, the warning is: don’t let the tool do so much of the looking, choosing, and checking that you stop building those muscles yourself.

Zieminski defines the working posture plainly:

AI with attitude means using AI with judgment, boundaries, curiosity, and scrutiny. You enjoy powerful tools without worshipping them, panicking about them, or letting them decide how you think, work, create, and learn.

Tiina Golub, writing in UX Collective, points at the right version of “personalization” for enterprise software:

I have spent most of my career working on the large-scale computer programs designed to operate and automate complex business processes for big organisations, known as enterprise software. Due to their size and complexity, these products are often slow to innovate, relying on outdated usability principles and legacy systems long after the rest of the industry has moved on. However, recent technological advances (yes, I’m mostly talking about AI) have both enabled and compelled them to evolve at an unprecedented pace. No one can tell for sure what the future will look like, but there are some clear trends reshaping the user experience of enterprise software right now.

The interesting part is not that enterprise tools should start feeling like consumer apps. That usually leads to dashboards with the user’s name on them and a recommendation panel nobody asked for. The better version is software that understands the work well enough to reduce how much process the user has to remember.

That makes AI less useful as a standalone feature and more useful as embedded guidance:

No longer a stand-alone feature, AI is increasingly woven into the fabric of the interface, deeply embedded into every workflow, and offering contextual guidance right when the user needs it.

That is the useful frame: enterprise personalization is not taste. It is role, permission, workflow state, and organizational context. The product gets “personal” when it knows what kind of decision the user is trying to make, what constraints surround that decision, and what help belongs at that exact moment.

Jenny Xie, writing for Figma, collects a set of community sketches about what AI-native software might feel like. The useful part is how concrete the sketches get: controls that appear only when they’re needed, systems that change pace when the user is overwhelmed, and interfaces that treat intent as the starting point instead of the final prompt.

Figma Weave marketing director Itay Schiff starts with creative tools:

When you’re working with a creative tool, select an element—a frame, a sentence, a scene—and state what you need to do. The right controls appear around it, surfacing only what’s relevant to that moment. No hunting through menus, no memorizing where things live. When you’re done, they disappear. Someone editing a video that feels too slow selects a clip and sees options for timing, pacing, alternate cuts, and sound bridges. You’re not losing touch with your craft, but accessing the right controls more directly, through context. This bridges the gap between how people think and how tools are structured. Creative work starts with intent—make this clearer, more nuanced, more intense—but traditional software is organized around persistent menus, panels, and modes. When users can focus on decisions rather than mechanics, the conversation shifts from what buttons we pressed to what we changed, and why.

This extends the generative UI debate from generated content into the surrounding interface: what controls appear, when they appear, and when they disappear.

Anna Oh, Head of Product and Design at Norbert Health, pushes the same idea into domains where software has to adapt to the person using it:

An intelligent system continuously adjusts how it communicates and acts based on how you respond. It offers structured guidance when you seem lost, steps back when you don’t need it, and shifts between voice, text, and visuals based on the context. It controls pacing, simplifies language, or breaks down information into smaller steps to reduce overwhelm. For decades, humans have had to adapt to machines. The mismatch between system capability and human readiness has only grown more visible as software becomes more powerful, and in domains like healthcare and education, especially with an aging global population, that gap has real consequences. As AI becomes the intelligence layer, this reverses: Systems meet people where they are, instead of the other way around.

For design teams, that means pacing, language, modality, and restraint become interface decisions, not polish applied after the workflow is done.

Tech anthropologist Jésabel DC shifts from adaptive behavior to the sensory cues that help people understand where they are in a product:

Sound, motion, and pacing are reintroduced as signals that orient you inside an experience. In the early 2000s, digital interfaces were full of these situational cues: the dial-up sound as you went online, the progress bar acting as a passage to the world you were entering, the voice announcing “You’ve got mail.” As technology became faster and more seamless, these cues disappeared, replaced by notifications engineered to grab attention rather than provide orientation. Because our users’ overall tech experience is already so dysregulating, it’s not enough to design something that isn’t overwhelming. We have to actively design experiences that counterbalance the rest of our users’ tech stack—otherwise, we risk losing users not because our product is bad, but because their nervous systems are already maxed out before they arrive. Think: always visible progress bars, sounds that mark transitions, and consistent visual language.

Sen Lin, writing in UX Collective, has a useful reference for designers who want Claude Code to fit their workflow instead of acting like a generic engineering agent:

Claude Code is an agent, and an agent is only as good as how you configure it. That’s the part worth paying attention to as a designer: Out of the box it leans engineering, but you can set it up to fit how you actually work — to understand design, respect your workflow, and carry the right capabilities — so it produces better results, faster.

A technical stack is the set of technologies you decide on before writing a line of application code. A design stack is the same idea, applied to Claude Code: the brief, the design knowledge, and the tools you hand the agent upfront.

The useful move is treating Claude Code setup as a design operation, not a prompt-writing trick. Give it a project brief, a design-system guide, and the right tools before it starts touching the work.

If CLAUDE.md is the brief, DESIGN.md is your design system translated into something an agent can read and obey. It’s a format specification that describes your visual identity to a coding agent: the exact values, and the reasoning behind them.

The file works on two layers, and both matter.

The first is machine-readable design tokens, written as YAML front matter — the exact values, so the agent never has to guess what gray-500 resolves to or which surface color a modal should use: […] The second is human-readable design rationale, written as prose — the part that explains why a value exists and how to apply it. Tokens tell the agent what primary is. The prose tells it there should never be more than one primary button per view, that a primary action is always paired with a neutral or subtle one for cancel, that button width is set by the parent and never hardcoded.

The tool/instruction split is the part worth saving:

MCP gives the agent access to tools.

Skills give it the knowledge to use those tools well.

Where MCP is access, a Skill is a markdown-based guide that teaches Claude how to perform a specific task in a specific way. It’s a set of instructions, scripts, and resources — a training manual that keeps the agent from wandering down expensive detours and burning tokens on the wrong approach.

Good checklist. The designer’s job is not just to ask Claude Code for UI. It is to onboard the agent into the product, the design system, and the working style before generation begins.

Michael Riddering’s Dive Club interview with Loredana Crisan, Figma’s chief design officer, is about how Figma wants a bigger, faster, more explicit design loop.

Riddering asks Crisan whether taste gets less defensible when everyone can make more things faster:

I actually think that what happens when everyone has the power to build is actually it elevates the need to stand out. You could buy those pretty funny or soulful congratulatory cards, birthday cards, whatever cards, and they have the message written inside. And it’s a great message. Do you just give somebody that card? You could, but that’s not what you do if you’re a good friend. That’s not how you show up. And so I think that the more software is getting created, the more articles are being written. Basically, we’re in a place where everything is getting produced at such high, high rate. And we already had trouble consuming what was already there. And so what we’re going to try to do is look for even more authenticity. […] So this is why I think it’s not taste. It’s just your point of view, your human intuition, what you want for that experience needs to come through. And then the tools that they build are very much important to help you drive that.

I think Crisan is right about the greeting card metaphor. When production gets cheap, the work that still feels made for someone will matter more, not less.

That matters for designers because AI abundance changes the filter. The scarce thing is knowing why this draft, this interaction, this bit of motion belongs in this product.

Riddering then pushes on control, which is where Crisan gets concrete about Figma’s tool bet:

The premise is that AI could get you to 70%. And this is true with motion. You could prompt your frame and then you will get the first animation set up. But then from there, you need to make it yours. So it’s almost like AI sets up the workspace. It gives you the parameters, but then you are the one that makes that thing. […] If there is a color that I want to put in my design, a color wheel will never be replaced by a prompt. So there are moments where you just want to take control yourself. […] And it’s an interesting way of working because increasingly as designers, I believe we’re creating systems, not just screens. […] Design is never done alone. Design is evolved through critique. It’s a place where one of the tools of design is other people. And so it’s really fun to be able to have AI, have agents, have the direct manipulation and direct control and your team in one space.

This is the version of AI design tooling that makes sense to me: the tool accelerates the setup, the first draft, but the product still gives designers enough control to make taste visible in the final result.

When working with AI design tools, we tend to think we need to one-shot a prompt to get everything. That, of course, is far from true. We iterate—a lot—by describing the changes we want, then waiting, and inevitably, iterating again. Crisan is describing a tool that still leaves room for the hand: sliders, variables, shared artifacts, and other people.

And she points to evals as part of the designer’s new job:

Increasingly, we’re working with non-deterministic systems, right? So a lot of what the experience is, is produced by an LLM. Previously, it could be produced by an algorithm. I worked at Meta and can tell you, we’ve had a lot of conversations about the buttons that would exist on a feed story. Those buttons are important, but when you think about what people really experience when they open one of those products, it’s the content. And so all of the conversations that we had about buttons as designers were far, far less important than the conversations that we should have had about the algorithm itself, right? And when it comes to these non-deterministic systems, how do you ensure that they meet your quality bar? There’s this thing called the evals is, on the one hand, the least sexy thing in the world, because you are now in a place where you’re trying to specify what good looks like and how systems that could either recognize that themselves or be augmented with humans that could do that. And it’s fascinating to try to do this on an unverifiable domain like design, because design is not, there’s not a correct answer to design, but there are many incorrect answers.

Figma’s own Config 2026 recap makes its strategy clear: it shipped code layers that bring editable, inspectable code onto the canvas; Figma Motion with timelines, keyframes, exports, Dev Mode inspection, and MCP compatibility; shader fills and effects generated by the Figma agent; generative plugins that let teams create canvas-native tools by describing them; Weave tools for reusable generative workflows; and a broader Figma agent with skills, connectors, attachments, and shared chats. The through-line is not one more AI feature. It is Figma trying to make the canvas the place where code, motion, generative media, team-specific tools, and agent context all live together.

The old design-tool space was mostly canvas versus canvas: Sketch, Figma, XD, Framer, whichever product made design teams move faster. Darren Yeo, writing in UX Collective, is looking at a different fight: Figma against the possibility that the canvas becomes optional.

Figma’s enterprise strength has always depended on breadth. Designers used it first, then product managers, engineers, marketers, writers, and executives followed. The more people needed to review, comment, inspect, or reference design work, the more seats Figma could sell. The same applies for the product bench, with the rapid expansion of Slides, Buzz, Sites, and now Motion and Weave.

AI complicates that logic. If an engineer can generate or inspect UI directly inside a coding environment, or if a product team can translate structured design intent into working software without opening a shared canvas or applications, the need for passive, underutilised seats weakens. Config 2026 actually confirms this tension by bringing code layers and agent workflows closer to the main product, Figma Design. In other words, Figma is acknowledging that an increasing number of people want to participate in product and code creation without relying on traditional file-based design behaviour.

That does not kill Figma’s seat model overnight, but it does chip away at the assumption that every stakeholder must enter Figma to participate or experience design. Thus, the deeper issue goes beyond whether the team has seats at the table (canvas). The table of collaboration resides in a code-native environment and workflow, where the moment of truth shifts closer to implementation, and that reduces the number of times a team needs to return to a design file as the source of record.

The handoff-is-dead argument usually shows up as a claim about what designers can do now: move closer to implementation, write production-minded specs, and stay in the work longer. Yeo adds the business-model version of that argument. If collaboration moves into code-native environments, Figma is not just losing a handoff step. It is losing the shared room that made every reviewer, PM, engineer, and executive need a paid license.

Figma is not standing still. Even before Config 2026, the company pushed beyond static collaboration and into AI-connected workflows. Features like MCP, Code Connect, and Figma Make on local code point toward a future where design data can move more fluidly into development environments and AI tools.

That is a smarter response than pretending the canvas can win by becoming a slightly better canvas. Figma’s best path is to become the system that preserves design intent, component logic, and implementation alignment across tools. In that model, Figma is becoming an operating layer.

This is also why the company’s product strategy feels more important than its individual features. A single new AI button will not change the story. What matters is whether Figma can make design data more portable, more structured, and more useful outside the file itself. Config 2026 suggests that Figma understands this, but it also shows how hard the transition is: the company still has to make the canvas relevant in a world where many teams want to begin and finish elsewhere.

Yeo’s warning is blunt: “if teams can skip past the canvas by accelerating from intent to implementation with less translation, the value of designing to handoff vanishes.” The answer he points toward is less about file ownership and more about whether design intent can survive the trip across tools. For designers, that shifts the work from drawing the artifact to making the intent durable enough for other tools to read.

The future of design is likely to be built around reusable tokens, readable structures, and tool-agnostic metadata rather than locked files that only live well inside one platform. The winning systems will be the ones that can travel between editors, browsers, codebases, and AI agents without losing meaning.

AI has made product work feel weirdly cheap in the middle and expensive at the edges. Another screen, prototype, or feature is easier to produce than it used to be. The harder work is deciding what belongs, what can be trusted, and what should never ship.

That is a different kind of leverage than pushing pixels faster.

Karolina Rojek, writing in UX Collective, names the design problem underneath the AI boom:

As technology accelerates, the limiting factor is no longer our ability to build. Increasingly, technology can help create itself. The harder question is deciding what should be built and how it should fit into people’s lives. That is a human problem, and design sits at the center of answering it-Jon Friedman said.

Design is now the discipline of deciding what should be made, who it is for, what behaviour it encourages, what it removes, what it simplifies, and what kind of relationship it creates between people and technology.

Rojek’s piece tracks Microsoft, Samsung, Shopify, Meta, OpenAI, and even the federal government elevating design leadership. That list is easy to read as corporate signaling, but the pattern is more interesting than that. If AI makes output cheaper, design has to move upstream: what should this product do, how should it explain itself, when should it stay quiet, and when should it hand control back to the person using it?

Rojek:

One of the traps product teams fall into is thinking the interface is the product.

The interface is where the user touches the product, but the experience is shaped by everything around it: onboarding, pricing, permissions, support, notifications, failure states, data policies, service handoffs, organisational incentives, and the user’s real-life context.

AI makes this even more obvious.

She puts that into everyday product terms:

Imagine a small business owner using an AI tool inside an e-commerce platform. The value is not simply whether the AI can generate a product description. The value depends on whether the merchant trusts the suggestion, understands how it affects SEO, can edit it easily, knows whether it matches their brand voice, and feels confident publishing it.

Or think about a designer using an AI prototyping tool. The value is not only speed. It is whether the tool helps them think more clearly, explore better alternatives, communicate intent, and avoid creating generic work at scale.

Or consider a citizen trying to renew a passport or access benefits through a government website. The problem is not just visual design. It is language, accessibility, anxiety, eligibility rules, documentation, error recovery, and the emotional weight of dealing with a system that may affect their life.

This is why “powered by AI” is such thin product strategy. The model is only one part of the experience. Trust, permissions, support, and failure recovery decide whether the product feels useful or feels like more work.

Rojek on craft:

AI can help generate options, but craft helps decide which option has integrity.

This is especially important because AI products can easily become noisy. More prompts. More suggestions. More assistants. More summaries. More generated content. More things asking for attention.

Without strong design judgement, AI can turn products into cluttered systems full of technically impressive but emotionally exhausting features.

Cheap output and coherence are different problems. A product can generate options all day. Someone still has to decide which options deserve to exist, which ones ask too much of the user, and which ones quietly turn into another obligation.

Brand identity is too often treated as a police manual: approved logo, approved colors, approved layouts, end of story.

In an excerpt from Taschen’s The Elements of Brand Design in It’s Nice That, the book’s authors Katharina Sussek and Jens Müller trace the longer history of modern brand design, from color and trademarks to systems that coordinate products, buildings, typography, and media:

An important impetus in design history thus emerged with the approach of the Italian typewriter manufacturer Olivetti. In the early 1930s, Adriano Olivetti (1901-1960), the son of the company founder, established the principle of working with not just the best engineers but also the most innovative architects and product and graphic designers in Europe.

Out of the totality of its designs a unique corporate identity developed over several decades, one that did not come about through following norms but through an expansive understanding of design. In the mid 1950s, IBM would follow a similar approach. The American company found itself smack in the middle of transforming from a typewriter manufacturer into a world-leading computer supplier. The architect and industrial designer Eliot Noyes (1910-1977) was appointed as the consulting director of design. In developing a holistic corporate image for IBM, he gave contracts for projects to the leading figures of mid-century design, including Charles and Ray Eames and Eero Saarinen. As the graphic designer, he hired Paul Rand (1914–1996), who started by overhauling the logo and moved on to developing a comprehensive identity based on a set of guidelines for use across all media applications of the company – from the printed matter to the labels on the machines.

That’s the part of brand strategy that gets flattened when identity systems become enforcement instead of expression. Consistency matters, but Sussek and Müller are pointing at something bigger: a company making its values visible across everything it touches.

They cite a 1967 corporate-identity text:

An idea that bubbled up in many places simultaneously at the end of the 1950s was the concept of a coordinated design, or a house style, as it was initially often still called in the literature of the time, before terms like corporate design or brand identity caught on. In the book Design Coordination and Corporate Image, which in 1967 was one of the first reference texts on the subject, a new understanding of the systematic approach to the standardisation of design was described using examples from the United States, Japan and many European countries. In their introductory text, the two authors, FHK Henrion and Alan Parkin, developed a remarkably prescient vision of modern brand design: “There is a tendency to regard a house style as a static, once-and-for-all set of rules. But market situations and corporations themselves change continually; and these changes should be expressed visually,” [it says in the book.]

In reality, though, most of the corporate design systems of the 1960s were extremely rigid due to analogue production processes. Standardised layouts were at the time seen as an important guiding element for a brand. Usually once the position and size of the logo was fixed in each medium this did not change. This indeed created a high level of visual congruity, but it did not necessarily lead to a dynamic perception of the company. Furthermore, the designers who had the task of implementing the designs across various media found that these too stringent rules often got in the way of good graphic solutions. By the 1970s, establishments from outside the commercial world also discovered the merits of a consistent visual appearance. Cultural institutions like museums, libraries and music festivals were especially fertile ground for highly creative solutions which had the advantages of a high recognition factor combined with a distinctive graphic signature. What initially developed in the Netherlands was known as ‘public design’, which placed a focus on functional solutions accessible to the general public.

That tension still feels familiar. A good system gives teams a shared language without confusing the manual for the work.

The trap is that the guide becomes a substitute for judgment. You can follow the rules and still make something that feels dead, because the rules only preserve decisions someone else already made. The next application still asks for taste.

Later, the authors make the AI connection directly:

In recent years, with the wide availability of artificial intelligence, another phase of the digital age has begun. For visual identities this has opened up a multitude of new playing fields. Examples shown here give an impression of how brands use these fresh possibilities – whether to achieve a new dimension of modularity or as a highly effective tool for creating solutions in line with the brand. At the same time, design as a profession has been challenged yet again, along the lines of ‘Can’t we just use AI instead?’. A look at the work collected in this book proves, however, that the development and redesign of brands, regardless of size, demands conceptual individuality and artistic originality. In the age of AI, these are two capabilities of designers that will become even more important, not less.

Designer and writer Christopher Butler is writing about AI, but this also lands on the mechanics of agent loops. A loop can keep running, but useful output still depends on the constraints, preferences, success criteria, and taste made explicit before it starts.

Butler, on what stays human:

The more interesting situation is the one where we keep the thinking and hand off only the doing — and what happens when we do.

What happens is more than speed. When you have to describe what you want to the agent — with enough precision that what comes back is what you actually wanted — you begin to think about the thing differently. Description, it turns out, is where the idea often actually gets made. You start by knowing roughly what you want, and the act of articulating it produces a clearer want, which produces a sharper specification, which produces a better thing. Then you do it again. The thing improves; so does the thought.

That maps to the AI bottleneck I keep seeing: production speeds up, but judgment still happens at human speed. Butler isn’t arguing for slower tools. He’s arguing that useful AI makes the thinking more explicit, not less.

The friction is part of the point:

The agent’s current maturity requires a level of input precision that a competent colleague does not. At first, this can be a frustrating blocker; we’ve depended upon a different kind of intelligence in our peers — the kind that requires no elicitation. The machine does. But in a sense, this is a gift. It forces you to think the thing through in places you might otherwise have left fuzzy.

That’s the designerly translation. The machine doesn’t infer your hierarchy, tone, edge cases, or tolerance for risk unless you put them somewhere it can use. That friction is useful because the agent forces you to specify the fuzzy parts before it starts generating the same mistake everywhere.

Butler’s word for that retained work is investment:

This system depends upon me to provide the thinking. The agent does the doing. The structure is, I think, the practical form of the argument: the systems carry the doing, and they carry it well precisely because I have spent the time to think them carefully through. We like to call this intellectual property, which I think is a bit obnoxious. It’s really intellectual investment. Every technological advance should be measured not by the measure of intellectual property it absorbs — how much it can do without us — but by how much intellectual investment is worth sowing in it.

That’s the useful correction to “AI will do the work for us.” It will, but only the part of the work that can be expressed well enough to delegate. For a design system, that means brand rules, component logic, editorial standards, and good taste have to become rules, prompts, specs, tokens, and checklists the agent can actually use.

That leaves the tool in its proper place. Using AI lazily will produce plenty of forgettable output. The more interesting use treats it as a medium that rewards the thinking you put into it.

Of course, there is tension between expressing our specs as words and spatial manipulation as visual thinkers.

Claire Vo on her How I AI podcast gives a plain-language walkthrough of agent loops in Claude Code and Codex. The episode is technical, but the useful translation for designers is familiar: define the job, give it tools, decide what good output looks like, and make the system prove it. Once an agent can run without you, the interface problem moves into instructions, permissions, and checkpoints.

And then a couple other foundational things that I think are helpful when you’re running loops. And why are these things helpful before we get into what they are? They just keep the work clean.

If you are going to be yolo-ing loops all over the place, you’re going to want some consistency in execution, you’re going to want clean workspaces, you’re going to want conflicts resolved and avoided. And so, all these things are really to make those loops effective.

And so, what are the things? They are work trees. I feel like this entire podcast could be Git 101. But work trees are just basically a way to isolate the work, especially the coding work of an agent away from other agents’ work in a sandbox. There are skills, repeated ways to do common tasks. We have a full episode on what skills are from earlier last year when they came out. Plugins and connectors, these are just the tools that your agent has access to. […] Sub agents, both Codex and Claude Code allow you to kick off sub agents. This is just a way to federate out work from the main thread, so that sub agents can do specific tasks, especially validation. And then there’s some way to track state. And essentially just think of this is like a to-do list.

The practical translation for agent orchestration: write the operating conditions around the work before asking for the artifact.

Calling it a loop makes it sound like automation plumbing. The design work is the brief: what the agent can touch, what tools it can use, and how it knows it is finished.

The employee comparison makes the loop feel less exotic:

Now, people are going to ask, “What should I use a loop for?” And when you’re designing loops or designing agents, I say this is the time for the manager. You are designing a job. And so, just imagine that you’re onboarding an employee. That employee could be an executive assistant. That employee could be a customer service agent. That employee could be a software engineer.

Every Friday, EA, I would like you to review my calendar, see who canceled on me, where I could have used my time more effectively, if there are any follow-ups, and send me a Slack to get this done. Um and I want you to do that every Friday. Guess what? You’ve just designed a loop for your executive assistant. […]

So, I really like to think about loops as designing workflows and designing jobs to be done for people. It just happens to be that you can put this intelligent agent against the loop, and then it’s ready to go.

For designers, that last sentence is the translation layer. A designer already knows this move from creative direction: clear constraints produce better work than a blank request. The only difference is that the worker now happens to be software.

A loop without success criteria is just a faster way to make someone review the same ambiguity at a higher token cost.

We all want our agents to work for us on a schedule whenever we want, doing work that we don’t want to do. It’s great. What are some of the problems? One, loops can get expensive. So, I just kicked off an automation that happens on a regular basis. It does wide-ranging work. It decides when to spin off sub agents.

And it does loop-based validation, which means it’s burning tokens until it hits a threshold that it decides is successful. If you do not write that loop well, or your validation criteria is too thin, guess what? Your agent is going to burn tokens. I think we’ve seen this with open claw in particular or some of these agent harnesses is they’re really good at loops. They’re very diligent. They get interesting work done, but man, do they love to burn tokens.

[…] Loop-based prompting is just its own thing. Goal-based prompting in specific is just its own thing because you have to be very precise about evaluation and success criteria. If you are not, you will be very disappointed and use a lot of tokens for not a lot of output.

Storied Colors is a catalog of over 250 named pigments, dyes, lakes, glazes, and digital hues, built around the story behind each color. Think of it like VH1’s Behind the Music, but for colors.

Color sites tend to slide quickly into vibes: palette inspiration and palette creation. Storied Colors is doing the opposite. It treats each color as a small research object, with source labels, status labels, chemistry, dates, alternates, citations, and a correction process.

The methodology page describes the standard plainly:

This page describes how entries are selected, researched, verified, and labelled. It is the long answer to how do you know.

I love that line because “how do you know?” is the whole product. The catalog isn’t just pretty, though it is gorgeous. It makes its trust model visible. It says what counts as evidence, what doesn’t, what gets softened when it can’t be sourced, and who is responsible when something is wrong.

Just go browse it. Pick a color, follow the citations, and notice how much more interesting a reference becomes when the provenance is part of the interface.

Jenny Xie, writing for Figma, talks with Vice President of the Pantone Color Institute Laurie Pressman about color as a cultural language, not a decorative layer. Pressman’s starting point is that color is read, not just seen:

Color is tied to our emotions and how we interpret the world. It’s a language that reflects what’s taking place in culture.

The practical questions Pressman gives designers are “What message am I trying to convey?” and “how do I use color to help me get there?” That’s the design-system version of brand strategy: what does this choice need to make legible before anyone reads the copy?

Xie follows that with examples where the same hue changes meaning across cultures, media, and materials:

Like any language, the language of color comes with its regional dialects. While black is worn at funerals in the West, mourners in the East wear white. Depending on the context, red can convey love, anger, or urgency in the West; in the East, it’s associated with luck, prosperity, and celebration. Brand and marketing teams can’t just follow color trends or assume universal meanings. “Someone seeing a product on the shelf in Japan versus France is going to have a different color sensibility,” says Laurie, “because they’ve built up certain associations.”

Pressman also brings this back to process:

Colors don’t exist in a vacuum. They show up differently depending on the material, medium, or surface. Something that resonates on a screen may look garish in person; a hue that exists in fabric dyes may not be achievable on, say, a Band-Aid. “This is why you must consider color at the inception of the design process,” Laurie advises, “so you can make decisions with full context of the material and surface finish on what it will appear.”

There are two versions of the same design-systems worry. One is about craft: AI can make an interface look considered without teaching anyone how the system works. Design-systems expert TJ Pitre pushes on the governance version: once the system is machine-legible and agent-friendly, who owns the calls the machines are allowed to make?

So when I say I have a beef with “agentic design systems,” understand that it isn’t a beef with agents. It’s a beef with one specific move that the term smuggles in, and that most people repeating it haven’t noticed they’re endorsing.

Here’s the move: handing the judgment layer of a design system to an autonomous agent loop that no human owns.

That’s the whole problem. Everything else is just tooling, and the tooling is great.

Design systems as AI infrastructure only works when the infrastructure still has an owner. Make the system machine-readable. Let agents generate, document, test, and check against it. But Pitre is correct that the library is only useful if the standards still have an accountable owner.

Strip away the Figma libraries and the Storybook instances and ask what a design system actually is. It’s a set of decisions an organization has agreed to and committed to enforcing over time. What does “primary action” mean here. When do we break our own grid. Does this thing deserve to exist as a component at all, or are we about to enshrine a one-off into the canon forever.

Those aren’t generation problems. They’re judgment calls, and they carry consequences the organization is accountable for, to its users, its engineers, its brand. A design system is, underneath all the tooling, a way of encoding collective judgment and holding people to it.

Pitre turns that into a test:

Which gives you a clean test for any “agentic design system” claim you encounter. Ask: what rejects the agent’s output, and who decided the rule it’s being rejected against? If the answer is a human-owned gate, it’s the real thing. If the answer is “another agent checks it” all the way down, you’ve built vibe coding with extra infrastructure and a more confident logo.

And that version is arguably worse than a person vibe coding in a scratch repo, because it launders drift through the authority of the system. The output looks sanctioned. It came from “the design system.” Nobody chose it.

In the end the invisible hand of the designer must still be felt.

Tom May, writing for Creative Boom, says the old bargain for independent creatives is breaking: make good work, publish it well, and the web would direct a few customers to you. The old SEO problem was already bad enough after Google’s AI Overviews, but May is pointing at the next step, where the answer is presented to the user without having to visit websites.

The web, it said, is moving “beyond the traditional search-and-click model toward a more conversational and generative web,” where brands now compete “not just for attention, but for recommendation, relevance and action”. That might sound like a boringly technical sentence, but buried within it is something very profound that affects every creative working today.

Because what it describes isn’t just a change in how Pinterest sells ads, but a fundamental change in how people find information and inspiration online. And if you’re a creative, the implications for whether you actually get work in future are huge.

May again:

Nowadays, when someone types “find me an illustrator who works in cut-paper collage for a children’s book”, AI returns an answer, not a list of links to explore. It decides who gets named, and there’s no way to influence it: no ad slot to buy, no SEO lever to pull.

And how does it reach this decision? AI platforms lean on aggregate signals: who’s already cited, listed, written about, and linked to. This favours the already-famous and the big studios with a deep web footprint, leaving the vast majority of smaller independents floundering.

It’s a virtuous circle for the former, a vicious one for the latter. The visible gets recommended, and the recommendation makes them more visible. The talented new graduate with a thin online presence isn’t in AI’s field of view, so they stay invisible forever.

For designers, that changes the portfolio from a gallery into a set of reputation signals: named projects, credited collaborations, interviews, and references that point back to a specific person or studio.

In a market where output gets easier to generate and distribution gets harder to earn, distinct judgment and identifiable work become business-development assets. The work has to be specific enough, and trusted enough, to be requested by name before an AI system is asked for a recommendation.

In this shiny new world of AI, you can’t optimise your way into a recommendation, the way you once keyword-optimised a website. Recommendation runs on reputation signals that a system can read: being named in other people’s work, on lists, in interviews, in the press, and in collaborations. So the answer for creatives isn’t to play the algorithms harder. It’s to become the name people and systems already trust enough to surface.

One part of that is to own your relationships. A newsletter list, for example, is a direct connection that no algorithm can intermediate away. A community of people who’ve chosen to hear from you isn’t subject to a platform’s recommendation logic. Look at how designers like Liz Mosley have built something genuinely resilient: a website, a podcast, templates, resources; an audience that actively follows her work rather than stumbling across it.

Another is to get cited and named, because getting talked about (positively, of course) is the new currency. This means leaning on the channels no algorithm can gatekeep: word of mouth, referrals, events, and real rooms. And in your work, aiming to be a category of one, with a style so specific it gets requested by name rather than retrieved by attribute. The creatives who get asked for by name are the ones that AI can neither replace nor substitute.

Lee Brown, Pinterest’s chief business officer, frames it this way: “The future of discovery won’t be driven by keywords alone. It will be shaped by context, taste, and trusted recommendations.” He’s describing his platform’s perceived advantage. But he’s also, accidentally, describing yours.

Murphy Trueman isn’t worried that AI makes bad design. She’s worried that it can make passable designs, enabling designers to bypass contact with the material that teaches them how systems actually behave:

UI is starting to feel disposable in a way that unsettles me. Not as a complaint about quality. Structurally.

The pace of generation means nobody dwells in a screen long enough to notice whether it’s actually considered or just plausible, and plausible is increasingly good enough because the bar for “does this look designed” keeps dropping when the tools do the designing. The decisions are still there, technically, but the attention that turns decisions into craft has somewhere else to be.

You can produce a lot of considered-looking work without any of it being considered.

This is the craft problem hiding inside the productivity story. The danger isn’t only that teams will ship screens faster. It’s that they may lose the habit of noticing the small decisions that make an interface hold together after the first glance.

Trueman gets more specific about what Figma gave her:

But the specific thing that made Figma matter to me wasn’t efficiency. It gave me a way to hold abstract structural ideas in my hands — the relationship between a component and a style, between a token and a decision, between a change made in one place and every instance that inherits from it, made visible, made editable, made something you could touch and understand by touching it. That’s how I learned to think about the work.

That’s the part I don’t want AI tools to flatten. The best design tools don’t just make results; they make relationships inspectable. You learn by manipulating the system, getting it wrong, and seeing which decision moved. Difficult to do in code and see it cascade in the product.

Pratik Joglekar, writing for Smashing Magazine, on the core UX trap in AI products:

This is the risk at the heart of designing with AI today: probabilistic systems wrapped in deterministic interfaces. The AI offers a guess, the interface presents it as truth, and the user, or the organization, acts on it.

Humans are wired for deterministic thinking. We prefer to believe that past actions determine future outcomes. Flip a coin 999 times and get heads every time, the deterministic mind assumes the coin is rigged. The probabilistic mind accepts that the 1000th flip could still go either way. That second mindset is harder to hold onto, but it is exactly what designers need right now.

Products operate in complex, nonlinear environments, and AI is accelerating that complexity. When designers and product teams treat AI outputs as the answer rather than one of many possible answers, they build fragile experiences, and in some cases, like medical diagnostics or financial forecasting, genuinely dangerous ones.

That gap matters because the interface can make a confident-sounding answer look settled. The moment a chatbot, recommendation, risk score, or AI-generated summary hides the uncertainty behind the answer, it becomes a designed claim about how much the user should trust the system.

Joglekar’s practical advice is to treat the model as a signal generator, not a decision-maker:

What you receive is not truth. It is the most statistically likely outcome given the data available. Always ask whether past data meaningfully predicts future behavior. If additional context can improve the prediction, include it. Without context, the output is just one of many possible answers dressed up as the only one.

The trust piece lines up with a recurring AI product lesson: controllable over perfect beats confident and wrong. Joglekar again:

One of the hardest things for designers is making uncertainty understandable and actionable. When uncertainty is hidden, users treat AI outputs as facts. When it’s communicated clearly, trust increases.

Ranges, estimates, and confidence indicators go a long way. A delivery window of “Friday to Monday” tells the truth about variability without misleading anyone, whereas a specific timestamp that slips erodes trust every time. A face recognition feature that says “this looks like Pratik, is that right?” sets more honest expectations than one that just labels the photo with a name.

Communicating uncertainty does not weaken trust — it strengthens it. The goal is not to eliminate uncertainty but to design for it intelligently.

A Singaporean software engineer who goes by Airing is writing for devs who can already see the AI curve from inside their own work: docs, code, review comments, all moving faster than the human capacity to verify them. The design translation is pretty direct. AI changes who can produce, but judgment stays human, and the more production accelerates, the more expensive weak judgment gets.

Over the past year, every piece of my work that I could hand off, I handed off to AI, piece by piece. The design doc — it wrote. The code — it wrote. The first drafts of documents and review comments — it wrote. What I can now run in parallel in one evening would have taken a full quarter two years ago. By rights I should be idle, but the truth is the opposite — I am busier than I have ever been. The content of “busy” has simply changed: I almost never produce anything with my own hands now. I spend the whole day reviewing what it produces.

This is the embryo of the end-state workflow. In it, there are only two things left for humans to do: review the design, and verify the result.

Notice what these two have in common: neither of them is production. They are gatekeeping.

That changes the clock as much as the craft: more time spent checking outputs, less time making the first pass by hand.

That gatekeeping word applies to designers too. When AI can generate the interface, the screen, the copy, and the prototype, the remaining work is deciding whether any of it should exist in that form. Airing says the temptation is simple: “lower your own standards.”

Read one fewer line of code. Skip one step of reasoning. Don’t ask one of the “whys.” When the little voice in your head says “eh, probably fine,” nod and let it pass. Project this forward and you can already predict the next few years: nearly every collapse in engineering quality will not be because one specific person was lazy — it will be structural. When production is infinitely fast, the verification standard becomes the only compressible variable in the system, and every incentive in sight pushes you to compress it: the boss’s expectations, your peers’ speed, the performance-review whip — they’re all telling you to let go.

But think clearly about what letting go means. The reason you have not yet been optimized away from the verification step is precisely that your standard is higher than the machine’s. A gatekeeper who keeps lowering the standard is personally building the case for their own replaceability. My stance on this has never moved: slower is fine. The standard, not one inch.

Airing refuses to make this only a productivity story. The professional risk is cognitive atrophy: forwarding the problem to the model, forwarding the answer back, and losing the stretch where judgment is formed. For designers, the warning runs through the same place: don’t outsource the taste-building, the principled refusal, or the logic of why a thing should be this way and not that way.

A real question, most of the time, does not have a deterministic answer. Cognition does not fall from the sky. It is ground out by humans through derivation, argument, and exchange — bit by bit, through a process that cannot be skipped, because that process is the human. If cognition is handed to you directly by AI — whether or not it is comprehensive, whether or not it is critical — the mere absence of that middle stretch of thinking is enough to let subjecthood retreat, inch by inch, until what is left is the silhouette of someone waiting in front of a Jenny to be retired.

AI cannot replace humans in perceiving and experiencing the world — and this isn’t a pep talk; it has a structural basis. I wrote, in an earlier essay on AI and psychological healing: human cognition is not just information processing — it is an experience interwoven from sensation and emotion. We perceive the real world through our bodies; we assign meaning through feeling. AI is unmatched at processing information and generating text, but what it lacks is precisely this dimension of experience — it can process data, but cannot experience the real world that the data represents. In one line: AI’s understanding is instrumental, not existential. It can help us understand certain facets of the human condition, but it cannot replace the insight we obtain through lived experience and inner reflection. A painting can imitate nature, but it can never become nature itself.

The reed’s entire dignity is in its thinking. Please do not hand it over.

Every product has rooms users are not supposed to spend much time in. A 404 page is one. So is an empty project, empty folder, empty collection, empty dashboard, or empty search result.

Most teams treat these as edge cases. But edge cases are where brand voice has less room to hide.

Orlaith Wood, writing for The Subtext, makes the case through 404 pages:

I love 404 pages. Or more specifically, well-written 404 pages. I screenshot them and save them in a little folder on my desktop. Sometimes I actively seek them out.

Yes, I need to get out more.

A 404 page is the best test of a brand voice. It has to:

1. Admit something’s gone wrong
2. Convey useful information
3. Ideally not bore people to death

If a brand’s taken time to craft its 404 page, it tells me they care about my experience on their website – even the bits I’m not supposed to see. It shows commitment to a consistent brand voice. And consistency builds trust.

Consistency is hard. Brand voice can break all over the place. The companies with the shiniest ad copy are often the ones with the coldest and most corporate customer service comms, or small print. But a good brand voice should be able to flex to the functional. Microcopy, with a little creativity, can be a great conduit of voice.

That line about voice flexing to the functional is the bridge into product design. An empty state has the same basic constraints as a 404: something expected is missing, the user needs a next action, and the brand suddenly has to speak without sounding like a campaign.

It is one of those tiny surfaces where product strategy, UX writing, and brand all show up at once.

The best versions do not merely decorate blank space. They make the product feel considered at the exact moment the user has the least to do.

Wood on the no-joke version:

A 404 page doesn’t have to have a joke on it, if it doesn’t fit with the brand. That doesn’t mean it has to be mind-numbingly dull, like this afterthought from Visa:

The tragic broken image. The ominous dot dot dot. The shifting of blame. From one of the biggest brands in the world. Even ChatGPT could do better than this.

It doesn’t have to be that way. Global Payments could have fallen into the same dreary, robotic trap. Instead they’ve channelled their caring expert tone of voice to lift the mood.

That little ‘we’ll get you to where you’re going’ is subtle, but it’s a nice touch to ease a frustrating CX moment. (Full disclosure: I’m pretty sure my boss wrote this, so I’m basically just sucking up here.)

That distinction matters for empty states too. A B2B dashboard probably does not need a mascot or a punchline when there are no invoices, jobs, assets, or reports yet. It may need one calm sentence that explains what happened, one useful action, and a tone that feels like the rest of the product.

Wood on the brief:

If you have a website, take a look at your 404 page now. Is it missing a trick to channel your brand voice? If you can’t tell, maybe it’s a sign that your voice needs an overhaul, or that you’re missing one completely.

Writing error page copy is rarely in the creative brief. I think it should be. It’s important to show how a brand voice reacts when something goes wrong. Just as important, if not more so, than showing it on a tote bag, or a bus stop ad, or those fake billboards in Camden.

I’d put product empty states in the same brief: not as cute copy, but as one of the few places where voice, usefulness, and trust have to coexist in ten words or less.

Everyone records videos with their smartphones, whether it’s concerts, kids, or stuff you think you’ll upload to TikTok. Truth is though, you might go back and watch those moments in your camera roll, but you’ll probably never edit them and make them into something shareable. Video editing takes a long time. Interesting things are happening with AI computer vision these days.

Ilias Haddad created an app that will index and semantically describe your videos. He made it to solve a specific problem he had:

I had 2,207 GoPro videos, and I need to rewatch them to find interesting moments from my cycling journey. I built a project to index them locally on my M1 Max using open-source ML models, search for those moments, and send the best clips straight to my DaVinci Resolve timeline.

NJ Singh built something similar:

Every AI video editor on the market assumes your footage is already labeled. Mine is IMG_*.mov and DJI_*.mp4 across folders with names like Mara june 2024 backup final FINAL. Eddie [an AI video editor,] can search by transcript, but none of these tools can find “the elephant on the hill at golden hour” against an unlabeled archive.

The AI editor is solving the wrong problem. Or more precisely, it’s solving the second problem; the first problem is the index.

Designers are used to thinking with their hands.

That sounds sentimental until you’ve spent time moving hierarchy and spacing around in a canvas. Some thinking happens because the thing on screen moves when your hand moves. It’s visual.

Quinn Keast, a designer writing in UX Collective, is getting at the cost that appears when that gestural loop becomes an instruction loop. He starts with the body, leaning on MIT design theorist Donald Schön:

Every tool becomes an extension of the user’s body. The user develops a spatial relationship with each tool.¹ In design school, we learned how to use pencils, pens, brushes, knives, and a whole bunch of materials and mediums before we were allowed to touch a computer. Mastery of one tool carries forward into other tools, but every tool has its own shape and movements that must be learned.

There’s a feedback loop where information comes back through your hands as you work and direct and change the course of creation. Schön describes this as “a conversation with the materials of a situation.”²

When the things you’re designing are themselves spatial — relationships of hierarchy and attention and movement — manipulating those things spatially is engaging with the problem directly, such that the moving is the thinking.⁴

This is why the “AI is faster” argument can feel too flat. Speed is one dimension. The other is the kind of attention the tool asks from you.

Keast’s distinction is not “old tools good, AI tools bad.” It is that the channel changed:

Big tool shifts have happened before, from the graphic designer’s drawing board to Photoshop, from hand-drafting to AutoCAD, even from Sketch to Figma. Each meant reskilling and churn and fatigue. You might argue these already introduced abstraction; the mouse is an abstraction of the pencil. But each still stayed continuous with the hand: I move, the proxy follows, and feedback still came through.⁵ The making-feel carried through each of these shifts, because the channel was still gesture.

The agent is the first shift that moves the making out of gesture and into language. I no longer manipulate a proxy whose movements mirror my own; I describe an outcome, and hand off the specifics to a system that decides them. The change is from gesture to instruction. It’s not another kind of canvas or another kind of pencil, but rather handing the pencil to an assistant and describing what you want the pencil to do.

That matters for design-to-code work because the thing we’re judging is no longer just the screen. Agents are good at producing a testable surface, but they can hide decisions that a canvas would have forced into view.

I appreciate that Keast doesn’t turn this into nostalgia for Figma. Keast brings in chemist and philosopher Michael Polanyi to name the cost of turning tacit judgment into language:

The act of prompting forces you to articulate into language what the hand knew without speaking — and, as Polanyi observed, “we know more than we can tell,” so that articulation is always incomplete.⁶

Making-feel is generative, where the thinking happens in the producing. Result-feel is evaluative, where I react to the result and how it feels to use. It’s no less engaged, but it’s a different type of engagement.

There’s two questions in my tiredness, and they have different answers.

If it’s a mismatch, in reaching for the agent when the problem wanted the canvas, will that fade, as I learn which problems belong to which layer, and prompting becomes a more well-worn tool?

Or is it a permanent cost, the tax that comes of translating tacit knowing into explicit instruction, of forcing what the hand knew into spoken words, every time, even when the agent is the right tool? That cost wouldn’t fade with skill, because it’s inherent to the tool itself.

I think it’s both — and it’s the latter that I keep thinking about.

For designers working with agents, the question is where prompting helps and where the work still needs the hand in the loop. Which I’d argue is still at the beginning.

Designer and writer MC Dean thinks most AI design demos are still asking the old workflow question: can the machine draw the screen I had in my head?

For Dean, that is too small. The useful shift is underneath it: if an agent is composing the interface, the designer’s job moves from final artifact to operating conditions.

Right now, in design teams everywhere, the same experiment is running. Someone feeds a prompt to Claude Design, or one of its cousins, and waits to see whether it can produce the screen they would have designed themselves. Some people are delighted. Some are frightened by how good it is. Some are disappointed in the results. A few are furious, and I understand why. When a machine can do in 10 seconds the thing you trained 10 years for, it’s annoying.

I want to move us off this question for now, because (nearly) all of us are asking it wrong.

Here is what we are really doing. We have been handed a tool that can grow an interface out of intent, something genuinely new in the world, and we are pointing it at the oldest task we know. Draw a fixed screen. Convert the canvas to code. Hand it down the line, faster and cleaner and with fewer late nights. Useful but look closely at what we are optimising for: We’ve been given something revolutionary, and we are using it to do old school design. A better-preserved version of the old way of doing things.

Dean’s line about “old school design” gets at the trap in a lot of canvas-to-code excitement. Faster handoff is useful, but it still treats the UI as the thing to preserve instead of the thing a system can produce when the context changes.

Dean again:

Canvas to code is a brilliant answer to a question that is already on its way out.

You can watch the whole industry racing to perfect it. Figma put an agent right on the canvas that generates and remixes and respects your design system, then made it possible to push those changes into a real codebase and open a pull request without ever leaving the file. It is clever work, and if your job today is getting a fixed design into fixed code, you should use it. Just notice what it is for. It is the most beautiful possible version of the handoff we have always done. It is the road getting smoother, right before it all changes.

Because here is where this is all heading, and it is so much more interesting than a faster mockup.

This is where designers have to be careful. If the interface becomes runtime output, then judgment has to live in components, constraints, refusal rules, and briefs the agent can actually use. The screen is still how the user experiences the product. It just stops being the primary thing designers hand over.

For a design team, that changes the evaluation. The first pass can be rough and still useful if it exposes which rules, components, and intentions are missing. The important artifact is the environment you can improve, not the individual screen you can rescue.

Dean on the method:

You stop finishing screens and start preparing materials. A set of components an agent can compose from, with the rules of combination written down: what sits next to what, how space behaves, which piece to use and when. Then you write your intentions in plain language, the way you would brief a thoughtful designer who is about to make a thousand small decisions without you in the room. How should this treat someone who is rushed. What does it never do, whatever happens. What should it feel like when the news on the screen is bad. You are not producing the outcome any more. You are designing the infrastructure, architecting the full experience, and curating the best outcomes.

Then you do the part that surprises people. You let it build, and you watch what comes back across many different moments. You correct the environment and the intentions, never the single screen. It is closer to coaching than to drawing. You train judgment into a system, and then you trust it in the places you will never get to enter.

You could start with one flow. Instead of designing the screen, write down everything an agent would need to know to design it well: the taste, the priorities, the hard refusals. Hand it over. Look at what it makes. Then resist every instinct to fix the pixels, and fix the instructions instead. That small discipline, correcting the brief rather than the output, is the whole new craft in miniature.