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.

Most agent-velocity hype rests on one premise: that writing code was the slow part. .txt, the team behind the structured-generation library, takes a saw to that assumption. The point goes back to two foundational software-engineering texts—Fred Brooks’s The Mythical Man-Month (1975) and Gerald Weinberg’s The Psychology of Computer Programming (1971)—and .txt puts it like this:

Software is what’s left over after a group of humans finishes negotiating with each other about what the system should do. The code matters, but it is the residue of the harder work, not the work itself.

Code as residue. That inversion reorganizes the whole conversation. The tools and processes we’ve built around software for fifty years—IDEs, wireframes, mockups, code review, even pair programming—have been about lowering the cost of producing the residue. Once that cost approaches zero, what’s left to slow you down is the negotiation underneath. And that negotiation has not gotten any cheaper.

What that layer actually consists of, in practice:

What slows down a team where agents do the implementation is the production of specifications precise enough for an agent to pick up and run. Roadmap, written down. Acceptance criteria, written down. The “what we actually want” forced into precision, be it via a test suite, a ticket, or a written design.

The bottleneck moves from people writing code to people deciding what code should exist. .txt calls that work management, and I’d put it a little wider; it’s also product, design, and anyone whose job description includes the phrase “what we’re building.” A spec precise enough for an agent is a falsifiable description of the outcome, with the trade-offs already made.

.txt on what runs underneath the spec:

Context is the commodity an organization runs on. It is the shared understanding of what we are building, why it matters, what has been tried, who decided what, what is load-bearing and what is vestigial. Humans on a team accrete it by osmosis. By being in the room, by reading the same Slack channel, by debugging the same outage at two in the morning. Most of it is never written down. When a senior engineer reviews a PR and says “this’ll break the migration,” they are drawing on context that has no document. Agents cannot do osmosis.

“Agents cannot do osmosis” is the line. Specs are the formal surface; context is what’s underneath, and teams absorb it without writing it down. The post closes here:

The companies that win the next decade will not necessarily have the best models or the best agent infrastructure. It will be the companies whose fifty people, then two hundred, then two thousand, can stay aligned on a shrinking set of decisions while shipping more output per head. They will be the ones that already knew, before agents arrived, that their hardest problem was coherence. That is a culture and management problem. Always has been.

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.

Jess Eddy reaches back to the 19th-century pessimist Arthur Schopenhauer for the distinction senior creatives may worry about:

Talent is like the marksman who hits a target which others cannot reach; genius is like the marksman who hits a target which others cannot even see.

Eddy borrows a line from Jack Grapes, the poet and writing teacher: “Make me look good, and I’ll keep you on the payroll.” That’s the trap. The longer you’ve been at it, the more reliably your talent delivers, and the more expensive it gets to walk away from what works. Most career advice says lean into your strengths. Eddy says your strengths keep you aimed at targets you already know how to hit.

For experienced designers, those targets are getting harder to find. AI is changing what counts as design work and what tools do it, and the ground under the profession is moving with it. The reflex when the ground moves is to double down on the move you’ve already mastered. But the mastered move hits the visible target. The targets that come next won’t be visible yet.

Eddy doesn’t let anyone skip the mastery step. The 5–10-year window isn’t optional. But once you’ve put in the time, you have to walk away from the talent that made you reliable. Eddy closes with Grapes:

Talent does what it can, genius does what it must.

Nearly nine in ten organizations now use AI in at least one business function. Ninety-four percent aren’t seeing significant value from it. Gale Robins, writing for UX Collective, argues that the gap is a framing problem, not an adoption problem. Her earlier piece on discovery judgment made the same case; the new one sharpens it with an anecdote that shows the trap:

A team I spoke with recently had compressed their discovery cycle from six weeks to ten days using AI. They were proud, and the throughput was real. When I asked what the work had taught them that they did not already believe, the answer was: not much. Same questions, faster. Same answers, sooner.

Same questions, faster. Same answers, sooner. Her analogy for the wider pattern is the electric factory one I’ve used before:

When factories first installed electricity, productivity barely moved. Manufacturers replaced steam engines with electric motors and kept the line-shaft layout. The breakthrough came later, when they redesigned the factory around what electricity made possible. The technology was only part of the answer.

Robins maps McKinsey’s three waves of AI value—productivity, differentiation, transaction-cost reduction—and finds most teams stuck in the first one. Robins on where they have to go to get out:

These decisions are upstream of every artifact a team produces. They are also where AI productivity gains help least, and where human judgment compounds the most.

Robins’s evidence undersells her own thesis. She leans on Generative AI at Work—the Stanford-and-MIT customer-support study by economists Erik Brynjolfsson, Danielle Li, and Lindsey Raymond that became the canonical citation for “AI helps novices most”—to argue AI raises the floor, not the ceiling. Novices gained 34%; experienced workers, basically zero. That’s why so many designers who have never coded—like me—are now suddenly shipping with this newfound superpower. It’s the same finding behind the junior designer crisis. But LinkedIn’s Full Stack Builder rollout found the opposite: top performers adopted AI fastest and got the most out of it, because they had the judgment to know what to ask for. The floor-not-ceiling story is only true where the questions are fixed. Once the questions are the work, the pattern inverts. That’s exactly the territory Robins is mapping. If AI rewards the experienced most when the work is judgment-shaped, framing is where the gap between teams widens.

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.

According to Harvard Law School, Eric Ries tells Lenny Rachitsky, only 20% of venture-backed founders are still CEO three years after going public. Every founder gets told by their lawyers, bankers, and VCs that they’re the exception. Statistically, they’re not. Ries, author of the Silicon Valley textbook The Lean Startup, treats this as a structural problem with a structural answer in his new book Incorruptible. The analogy he spins:

This is like you’re building a bridge. And if your bridge collapses, and Lenny, I say you’re an engineer, and I say, “Lenny, why did my bridge collapse?” If you’re like, “Well, ‘cause of gravity.” I’m gonna be like, “Dude, yeah. Thank you for that genius insight, right?” […] I call it financial gravity. […] Yeah, but I want to know why did this bridge collapse? And more importantly, how come other bridges didn’t collapse? And they say, “Oh, for that, we need to study the load, load factor, wind load, shearing tension.” And we go look up close. We say, “Oh, look, all the metal bolts have been corroded.” They’re rusted. No wonder it collapsed. And then if you say, “Well, I want to build a new bridge, but I don’t want this one to collapse. What can I do?” You won’t say, “Well, gravity, what can you do?” No. You say, “Why don’t we use stainless steel next time on the bolts so they don’t get corroded?” Oh, yeah, good idea. So this book is about what are the organizational equivalents of stainless steel?

This is the move that makes Incorruptible a design book. Most writing about founder ouster and mission drift treats those outcomes as moral failures: bad people taking shortcuts or unlucky breaks in the market. Ries refuses that. Corrosion is predictable. Stainless steel is a material choice. Your bolts are going to rust unless you specified otherwise before pouring the foundation. The governance documents a founder signs in year one are the structure of the company itself. And the people advising them on those documents (the lawyers, the bankers, the VCs) are not the people who will be standing on the bridge in year ten.

Ries on a related diagnosis:

I could tell that this restaurant got taken over by private equity. I could taste it. And I’ve told that story a bunch of times now. And so many different people have told me, “Oh yeah, I know what restaurant you’re talking about!” And then they name like 12 different restaurants. So what’s going on that like you can taste the ownership structure of a company in the food? How many people have had a famous brand that they love get ruined? […] all kinds of famous companies where the thing that destroyed them was not competition. It was not someone else came up with a better product. No, their very success became a liability because the more gold in the goose, the greater the temptation to butcher.

You can taste the ownership structure in the food. That’s a designer’s instinct, even if Ries doesn’t call it that. It’s the same thing that tells you, holding a product, whether the team that built it still cares, and whether anyone at the top is protecting the people who do. The Sonos app rewrite that wiped half a billion in market value came from decisions inside the company about what to ship and who got protected. The bridge was already corroding. Ries is arguing that the protection has to be installed early, before there’s anything worth butchering. That’s design work, in the most literal sense.

Ries is a captivating storyteller in this episode. I can’t wait to get my hands on his new book.

Nearly a thousand design studios across more than 50 countries, hand-picked by one person. Wences Sanz-Alonso runs Just a Design List, a directory that strips each entry down to a name, a city, a discipline, and a link. No hero image, no blurb, no star rating. The about page explains what it is:

Just a Design List is a personal reading list that grew too long to keep privately. It began in 2023 as a list of bookmarks, and is now a small, slow public archive — a place to point at studios whose work rewards close attention, without the obligation of a review.

It’s an excellent curated list full of inspo possibilities to close out the week.

I met Jennifer Jerde early in my career. She’s one of the nicest humans I’ve ever encountered in this business, and her firm Elixir Design has been quietly building brands out of San Francisco for 27 years.

Rachel Paese, writing for Design Observer, gets Jerde on the question the rest of the industry is trying to dodge:

We’re in a world right now where everything kind of looks the same. You can go to Canva, you can get Squarespace templates, and you basically just change out the messaging. And it looks pretty handsome. It’s a design of an ad. It’s a design of a website. It’s where the design is a noun. It looks pretty nice, but to make stuff that’s actually true, it looks like listening to a lot of different people.

The thing you ship is the artifact, and the artifact can be produced by anyone with a template and a logo file. What Jerde sells is the listening—27 years of it—and the specific verb that template work can’t perform.

She gives the verb a definition later in the piece:

We do have an observation practice. I would never refer to it that way. We listen like crazy. We’re observing what lives inside clients’ minds and hearts about things. And then we don’t just show them 3 directions, we show them fifteen. Then we observe what happens.

The difference between three directions and fifteen is the difference between a studio and a feed. Three directions is what you present when you already know which one you want the client to pick. Fifteen is what you present when you genuinely don’t know yet, and you’re willing to use the meeting as the instrument that tells you. That’s expensive and it doesn’t scale. It’s the entire reason Elixir has been doing this for 27 years and not 27 months.

Jerde on AI:

I’m both deeply impressed by AI and scared of it. But I feel like companies and brands get exactly what they deserve. They hang out there exactly who they are, in a way. […] And then there are the players who are like, no, no, we really want to reach this audience. We want to show how genuinely great we are in whatever way we are genuinely great. That takes effort.

There’s a caveat in there: the migration to AI is optional. You can opt out. The template will work for the audience that doesn’t require you to have listened. It’s good enough.

But the interesting brands are the ones that don’t accept good enough, that demand that extra effort.

Chip Kidd, in a Fast Company interview with Nicole Gull McElroy, says he is “the last of that breed.” He means the 40-year career at one publisher, which he is about to complete at Knopf in October. He says it plainly:

In October, if I live that long, I will have passed my 40th year at Alfred A. Knopf. I feel very fortunate. Frankly, I’m the last of that breed. I have peers who are also the last, but that’s going to be it. It’s not for me to say, but the age of a 40-year career at the same place used to be not that unusual, but going forward it will be. That’s just the way things have evolved.

Read the interview and the easy story is the celebrity arc: Pennsylvania kid joins Knopf in 1986, does Jurassic Park, ends up on the canon shelf with Cormac McCarthy, Donna Tartt, and John Updike. But Kidd points at the mechanism instead of the outcome. He points to two anonymous designs—the Tide box, the Coca-Cola wordmark—and then explains why his name is on his work and theirs is not.

A lot of graphic designers do not get credit for what they do. Who designed the Tide detergent box? We don’t know but it certainly is iconic. Even going back to Coca-Cola: Who designed that? […] Growing up in the ’70s, the only other area of graphic design where the designers got credit were record album covers. If you looked closely, you could see this one was done by Peter Saville. He was a huge influence on me. […] To this day, if I design a book cover and it gets put out into the world, it has my name on it. That is why we are even having this discussion right now. Not only did I get credit for what I was doing, but I piggybacked on these books that became iconic bestselling books.

Two structural facts are doing the work here, and neither is talent. The first is the medium: book jackets have a back flap, and the back flap has room for a designer credit. Record sleeves had the same affordance, which is how Peter Saville got known for Joy Division and New Order. Packaging does not: there’s no flap on a Tide box where the designer’s name goes. The second is duration: the credit on any single jacket is small, but Kidd got to put it on hundreds of jackets over forty years, several of which became permanent fixtures on the canon shelf. Stack enough of those and you become legible as a designer. None of the anonymous designers behind Coca-Cola or Tide got either accident — neither the flap nor the four decades to fill it.

This is what makes the Kidd interview useful, and why the celebrity reading misses it. He is the exception that demonstrates the rule. The credit crisis in design is structural: it turns on whether the artifact you make has a place for a name and whether your employment lets you stay long enough to accumulate names. Most design work fails one or both of those tests. The artifacts that fill a designer’s career now—apps, dashboards, marketing pages, packaging—don’t carry credits at all, and few roles last long enough to compound into a body of work the way Kidd’s did. The 40-year jacket-flap career was never the model. It was the unusual case where the structure happened to cooperate.

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.

When I wrote about the forward-deployed designer squad model earlier this year, I was working from the outside in: what the model should look like, who it serves, why it matters. Ron Bronson ran it for four years as director of a 40-person design division at 18F, the now-defunct US government’s in-house digital services agency. His post is the inside view and he diagnoses why most orgs never get there:

The real reasons that design roles aren’t being considered for this is the ways orgs constrain how designers show up on cross-functional teams. If your designers are only good for handoffs, you’re not going to invest in the headcount.

The people are the key, but you have to be opinionated about what you’re looking for your designers to do. If you’re looking for pixel-perfect, portfolio polish then you’re doing it wrong. Due to the quirks of federal hiring rules, we weren’t allowed to consider portfolios. It didn’t mean we couldn’t look at them, they just couldn’t be part of the criteria someone got an offer or not.

Take the portfolio rule: federal hiring restrictions sound like the kind of constraint that makes a practice worse, and instead they forced 18F to evaluate designers on the things that actually predict forward-deployed performance—ambiguity tolerance, collaboration, low ego, willingness to work in the open. The portfolio gauntlet that dominates tech-industry design hiring optimizes for the opposite skill: producing pixel-perfect artifacts in isolation. Bronson’s team got better signal because they were prevented from looking at the worse one.

Bronson on the multidisciplinary bar:

hired designers who can do more than one thing. Some impressive UX researchers would show up on our doorstep often, and if they talked to me, I’d be very direct with them about how we worked and that our designers often had to wear more than one hat out of necessity. The other constraint? Headcount. Design often has to justify itself more than other practices, so we couldn’t afford people who were too “special” to be staffed to a broad array of partner engagements. What this meant in practice? Designers who could code, researchers with content strategy & information architecture chops, service designers who could lead and/or PM projects, and every designer being a strategist on some level.

Generalist breadth in this context is a structural requirement of the engagement. That’s what Bronson means by “wear more than one hat out of necessity.” You can’t deploy a specialist into a six-week problem-scoping sprint and expect them to be useful for more than one week of it.

Bronson on where designers should sit:

As I explained in Design as Repair at IxDA Oslo last September: we need designers embedded where problems happened, not downstream after it’s been scoped, broken and all the framing has been done and asked to execute.

Most design orgs are structurally downstream: invited in after PM and engineering have already decided what’s being built, given a brief that pre-resolves the questions design should be asking. Bronson’s 18F was built to refuse that posture by default, which is why the model worked there before it had a name.

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.

Taras Bakusevych closes his walkthrough of ten dying UI patterns on the heuristic that matters:

Execution UI: Interfaces that help humans perform deterministic work — entering data, configuring rules, following process steps, executing repetitive operations. 🟠 Shrinking. As AI automates execution, these surfaces lose their reason to exist.

Judgment UI: Interfaces that help humans evaluate, guide, and correct work done by machines — reviewing outputs, verifying changes, understanding reasoning, intervening at exceptions. 🟢 Growing. As AI takes on more autonomous work, humans need better surfaces to supervise it.

The supervision problem is what Jakob Nielsen called evaluability—the new central UX metric—and Bakusevych is doing the screen-by-screen translation. Every pattern in his list gets re-examined under one question: is this surface helping the human do the work, or helping the human check the work?

The HubSpot quote flow makes the friction concrete:

Creating a single sales quote in HubSpot requires navigating seven sequential screens. The rep manually selects the contact, adds company details, configures line items, chooses signature options, sets payment terms, picks a template, and previews the result — before a single quote reaches the buyer. Each step assumes the system doesn’t know information it already has in the CRM.

Bakusevych’s replacement gives the rep a different role: review what Shopify Sidekick assembled, correct what’s wrong, ship.

That’s the test he leaves you with. Open one screen in your product and ask which job it’s doing. If it’s interrogating the user for context the system could have inferred, it’s on the shrinking side.

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.

Nathan Beck, a product designer in Amsterdam, opens his essay with the title “The death of design” and an immediate retraction: “LOL only jk design still alive.” Then he spends a few thousand words on why, walking through what AI tools actually do to a working designer’s day and what they conspicuously do not do.

The pivot quote is buried two-thirds in:

If you call yourself a designer and—be honest with yourself—the bulk of your role has been the production of flat pictures of user interfaces, then I’m sorry to break it to you, but you are not designing. You are styling.

That line is the whole post compressed. Beck is not arguing that AI threatens designers. He is arguing that AI threatens styling, and that a lot of people who call themselves designers have been styling for a decade and are now discovering that the part of the job AI is good at was the part they were doing.

What’s left over, in Beck’s telling, is the reflective work: the thing that happens during design, not in the final file. He quotes Kaari Saarinen on output isn’t design:

In the same way that one writes in order to understand what one is writing, one designs in order to understand what one is designing. As Kaari Saarinen explains, “Working visually keeps me close to the problem and is slow enough [sic] gives me time to think while I work. Moving things around, testing relationships, and refining structure is not separate from the thinking. It is part of how clarity emerges.”

This is the part the “designers are cooked” discourse misses. The understanding accumulated while making the Figma file was the asset all along. The file was the receipt.

Beck has a second argument running underneath the first: AI output, on its own, is aesthetically average. He quotes Nick Foster’s Dezeen piece on what software feels like after a decade of optimization:

The apps I use to hire plumbers look and feel remarkably similar to those I use to watch skiers do backflips. Every brand feels the same, every function feels the same, every interaction feels optimised, streamlined and joyless. By any measure, these pieces of software are miracles of engineering and triumphs of logic, yet they feel profoundly underwhelming to live with.

A designer who only ever produced flat pictures of those interfaces has been replaceable by a model for a while now. The judgment about which of those generic outputs should ship and which should be thrown out and rebuilt is the part no model has managed yet.

Beck closes:

However, I am cautiously optimistic that as we weather this historical conjuncture, and machine intelligence loses its sparkly aura, and weekend vibe coders increasingly learn how substantial the gap is between a prototype and a product, the role of design, however it is redefined, will be just as essential as it ever was.

That unsexy gap is the whole game. Greg Kozakiewicz updated the old construction line: we used to confuse the drawing with the building; now we confuse the prototype with the product. The demo works on a good laptop with someone who knows what the app is supposed to do. The product has to work for the user who doesn’t. Closing that gap is the orchestration job—defining the thresholds and deciding what the system should refuse to do—and when the weekend demos lose their shine.

Scott Berkun lists three portable superpowers most designers underrate in themselves: investigative curiosity, the ability to translate between people who can’t understand each other, and a working grasp of tradeoffs. The first one is where he starts:

If we can spend hours reading about the 16th-century French history behind the beloved font Garamond, or studying the details of the design prototypes Jonathan Ives made to create the first iPhone, we have the rare capacity to discover and digest layers of complex information for practical use in solving problems.

Designers tend to file “I went deep on Garamond’s history” as a hobby or a tic, not a transferable skill. Berkun’s point is that the depth is the skill, and the subject is interchangeable. Aim it at a thing your CEO is worried about and you’re suddenly the person who knows the most about it in the room.

On translation:

Someone who explains things clearly, including through insightful sketches, diagrams, or metaphors, has tremendous value. Explainers help people make sense of each other. Designers are often shy about their ability to explain things, but typically we’re better at this than other professionals, since our work is rooted in communication (even visual design is rooted in semiotics, the study of symbols and their meaning). If we can be curious about our coworkers’ perspectives, objectives, and frustrations, we can be translators.

Berkun has made the curiosity argument before, in the negative, when he listed lack of curiosity as one of the five worst habits a designer can have. Reading this piece next to that one, the two halves connect: the habit he warns against in one post is the superpower he’s asking us to revive in this one.

My recent newsletter, “Out of Your Head, Into the File,” made the case for getting taste out of your head: writing it down so it can survive the messy middle of an AI workflow. Mia Kiraki, writing in Robots Ate My Homework, picks up the other half of that problem: how taste erodes when you don’t.

Her central image is the Hansel and Gretel gingerbread house, recast:

AI output is the gingerbread. You’re tired, the deadline is close. The output IS the shelter. You eat it - of course you eat it. That’s what gingerbread is made for, right? […] The Grimms buried a much smarter lesson in the early pages, before the witch even shows up. Hansel drops breadcrumbs to mark his path through the forest and the birds eat every one. He still leaves them, though. Those breadcrumbs are your taste, every little choice you make on the page (this word, this angle, this risk) which leaves a marker of who you are. The forest will always try to erase them.

What’s specific to AI is the environment. It’s now optimized to wear taste down a percent at a time, in ways you can’t feel while it’s happening, until the work you used to do feels like someone else’s.

Kiraki puts the mechanism plainly:

If most of your reading this week was AI slop (which is pretty likely given the state of the internet), you trained your judgment on machine output. […] Each accepted sentence is a small vote for a lower standard. You accept a vague phrase because the deadline is close. You let a soft claim through because rewriting from scratch would cost an hour you don’t have. […] Taste dies slowly, when you wake up someday and read something you wrote six months ago and realize you used to sound so different. You had edges, took risks, made claims, and you sounded like a person who made choices.

Kiraki gets at the failure mode that follows once taste is the only real moat left.

Her counter:

Read work that operates at a higher standard than yours. Work where someone made choices you wouldn’t have made or took risks you would have edited out. Your taste calibrates upward when you expose it to judgment that outclasses your own. […] Practice the explanation. When something in your own work feels wrong, write down the reason. The specificity of your explanation is the weapon. […] Ship work that makes you nervous. If a piece feels comfortable to publish, you probably didn’t push hard enough. The pieces that make your stomach tighten show and prove your taste is working at full capacity.

The middle one is what that newsletter was about: writing down the reasons, not just the verdict. Kiraki adds the bookends. Read above your level so your baseline isn’t drifting toward consensus. Publish the version that scares you a little, because the version that doesn’t is the gingerbread.

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.

There is a small genre of data-visualization writing whose whole purpose is to give readers vocabulary for the moves bad-faith presenters make. Nathan Yau’s “Defense Against Dishonest Charts” is a must-read. It is interactive, taxonomic, and names its villains: the Damper, the Cherrypicker, the Base Stealer, the Storyteller. Read it once and you start seeing the moves everywhere.

Then watch Hank Green take apart a Reason video that argues climate change is real but not worth doing anything about. Green opens with the diagnosis:

This video is a master class in like very subtle manipulations. A lot of a lot of the internet is really brute force here. But this video is like just appears to be a calm, collected guy helping you understand the world better. […] But if you look closely, if you follow this closely, you see the subtle manipulations in a way that makes it so clear that this is bad faith and that he is making an argument, not because he believes it, but because he has an agenda.

For Green, calmness is the manipulation. Yau is mostly cataloguing chart geometry: axes truncated, scales squeezed, slices reordered. Green is cataloguing the verbal layer that wraps around the geometry. A steady tone primes you to trust a graph that’s doing the lying. He spends a long beat on how the Reason presenter introduces his experts:

We have Michael Mann who is a climate activist. And then we have Steven [Koonin] who is a theoretical physicist. […] Like you could say former oil industry executive Steven [Koonin]. You could say lead climate contrarian Steven [Koonin]. Like you could call Steven [Koonin] a lot of things and theoretical physicist is certainly one of those things, but you’ve picked which one you’re going to call him whereas you’ve picked what you’re going to call Michael Mann. Honestly, if you didn’t do these little things, I would believe that you believe your BS. But you do these little things and it makes it very clear that you don’t believe your BS. You’re trying to manipulate me.

Same person, two truthful titles, picked to do opposite work on the viewer’s belief. Yau’s taxonomy doesn’t cover that one. The dishonesty lives in the labels around the chart, in the small choices nobody flags because each one, on its own, is technically true. Same kind of move as a Cherrypicker, though, in a different layer of the presentation. The ratio-graph segment is closer to Yau’s home turf:

How would you correct for that? Well, you just take a ratio every year and see how that changes year-over-year. Oh my god, what an elegant solution. But apparently the only reason you could possibly do that is cuz you wanted to SHOW A SCARY GRAPH. WHAT ARE YOU TALKING ABOUT, GUY? HAVE YOU NEVER BEEN AROUND A GRAPH?

The dishonest move there is the inversion: a valid statistical adjustment, presented to the audience as proof of motive. The graph is fine. The taxonomy of the attack on the graph is what’s missing.

Read Yau first, then watch Green. You will have names for almost every trick the Reason presenter pulls, and a clearer view of the ones the field still needs to name.

The terminal’s return as a serious surface for new tools (Claude Code, Codex, Omarchy) has mostly been read as a developer aesthetic story. Alcides Fonseca reads it as the receipt for thirty years of GUI toolkit churn. He walks the platforms one by one (Windows, Linux, macOS), then through Electron, then through the failed restarts (Google’s Flutter UI, Zed’s GPUI), and ends on TUIs as the place developers go when none of the layers above hold up.

Fonseca on macOS:

Apple used to be a one-book religion. Apple’s Human Interface Guidelines used to be cited by every User Interface course over the world. Xerox PARC and Apple were the two institutions that studied what it means to have a good human interface. Fast forward a few decades, and Apple is doing the best worst it can to break all the guidelines and consistency it was known for.

This isn’t a nostalgia complaint. Fonseca lists the live breaks (Fitts’ law getting ignored, the Tahoe window-resizing saga that didn’t stay fixed, the icons cluttering Apple menus) and treats them as the same class of failure as Microsoft’s WinForms-WPF-Silverlight-WinUI-MAUI parade. The mechanism differs but the outcome is the same: the platform stops being a place a designer can rely on.

Fonseca on Electron:

Looking at my dock, I have 8 native apps (text mate and macOS system utilities) and 6 electron apps (Slack, Discord, Mattermost, VScode, Cursor, Plexampp). And that’s from someone who really wishes he could avoid having any electron app at all. […] These are actions that should be the same across every macOS application, and even if there are shortcuts, they are not announced in the menus.

The dock count is the right way to measure it. RAM is the visible cost of Electron; the invisible cost is that every Electron app becomes its own little keyboard regime, with shortcuts that often don’t match the rest of the system and aren’t announced in menus when they do exist. Fonseca’s Cursor example (can you keyboard from the agent panel to the agent list and archive an item) is the kind of question any pre-Electron Mac app would have answered yes to. Most Electron apps answer maybe, with a shortcut their vendor invented.

His prescription that follows (make HCI mandatory in CS curricula, fail student projects with bad UIs, push OS vendors to invest in toolkits developers want to use) is correct in shape and probably wrong about leverage. Students aren’t the bottleneck. Apple and Microsoft have already read Norman. TUIs are back because the platforms quit, and the curriculum can’t fix that.

Fonseca’s diagnosis is right. The prescription is narrower. The TUI escape hatch works for developers because their work is text. Designers don’t get the same exit when the canvas is the medium itself.

Bonus: Speaking of TUIs, TUIStudio is a macOS app for designing terminal UIs, just like Figma!

In product orgs, the word “autonomy” tends to get attached to seniority and titles. Sara Paul, writing for Nielsen Norman Group, puts the bar somewhere else:

Our research shows that autonomy is about becoming sufficiently informed to credibly shape shared product decisions.

You’ve earned design autonomy when you’ve collected enough context to make a recommendation that holds up under scrutiny. Until then, you haven’t. Low-autonomy designers, in Paul’s terms, “execute predefined solutions.” High-autonomy designers shape what gets prioritized, because they know things their stakeholders don’t.

The four-part pipeline is the practitioner half:

The designers who achieved high autonomy kept information flowing to them from all sources within their organization. Their pipelines consisted of four parts: (1) Gathering information from across teams and channels, (2) Building relationships with people who provide information, (3) Creating crossfunctional spaces for information to be shared, (4) Synthesizing information to form a “big picture” of context that empowered credible recommendations.

Paul’s examples are specific enough to put to use. The opening one is a lead designer at an online review platform whose ad-setup experience lived across mobile, desktop, and web. Three teams owned different parts of the experience and the whole was nobody’s job. Here’s how the story ends:

She saw the problem, took the initiative to gather the information she needed, and synthesized it into a recommendation that boosted her influence over what got built. This is design autonomy.

None of this required a new title. It required a tracker, a few standing meetings, and the willingness to do the synthesis work nobody assigned.

The designers I want—and have—on my team are the ones who can fill in for a PM when they’re on vacation. Paul’s article is the mechanism for getting there. The PM-shaped skill is holding the information context that lets you make a defensible call.