Dan Shipper, CEO of Every, has spent the last few years running his company as an early-adopter lab for AI tooling. The report from inside is that aggressive automation has not shrunk the team. The work has changed shape, but the volume of expert human work has gone up, not down. The reason, Shipper argues, is structural.

Slop is not any one particular mistake. It is not the use of em dashes, or a certain sentence rhythm, or purple accents on a landing page. Slop is visible sameness, repeated ad nauseam. It is what gets produced by default when humans in many different circumstances use the same tool, trained on the same corpus, without thinking too hard. It is what happens when everyone has access to an expert who has the same default tendencies. When someone in operations can issue a pull request, marketers can create YouTube thumbnails in seconds, or engineers are writing product guides, it’s easy to end up in a world where your output has gone up—but the quality, coherence, and differentiation of what you’re producing has dropped.

Sameness as the failure mode lines up with what BetterUp Labs researcher Kate Niederhoffer and her co-authors named workslop: AI-polished output that shifts the burden of judgment downstream onto whoever has to interpret, correct, or redo it. Shipper’s contribution is to follow the mechanism one more turn: once everyone is producing the same default output, the work that doesn’t look like the default becomes the scarce thing. Difference becomes the new status game, and difference has to come from a human who is alive to this moment, this customer, this codebase, this conversation.

The second half pushes the same logic up to AGI. Shipper on why even AGI doesn’t escape the loop:

In any hypothetical AGI built by any of the major labs, there is still going to be a framer—a human—directing the model to achieve a goal. And because the frame is not the framer, we’ll see the same pattern repeat: AI turns yesterday’s framed competence into something cheap; people use that cheap competence in more places; the results become abundant; experts move to the edge to decide what matters now; their judgment creates the next frame; and then the model climbs that, too.

At the end, Shipper drops the analytical voice and writes:

The race is over. You can almost feel your muscles beginning to atrophy, useless in the face of this mechanical copy of you and everyone you’ve ever met, of the whole of humanity. A ghost chasing a ghost, and winning. But then something strange happens. The model turns to you. Your cursor blinks, off and on, in the blank text box, expectantly. Waiting.

Michael Riddering brings Tommy Geoco on Dive Club fresh off field visits to Vercel, Perplexity, Metalab, Ramp, and Snowflake. Geoco and his team are making a documentary after roughly 200 conversations with designers and design leaders this year. The survey finding he leads with is the one I would have least expected: designers who have moved more of their work into AI-assisted prototyping are also more satisfied with their workflows. The hierarchy of who is actually doing that work is the part worth sitting with:

The number one thing that stood out to me was that designers who are currently vibe coding are more satisfied with their workflows. […] And I did not expect that. […] People seem to dig it in this survey. […] It’s the people who are currently doing the majority of their workflow on vibe coding activities. It’s design engineers. That makes sense. Lead principals. [After that] it’s non-designer roles, which might be students and researchers. Then it’s managers. And then it’s your general junior mid-level IC. And that part was fascinating that managers are doing more than junior and mid-level ICs. Either things are trickling down and people are experimenting and then they’re going to pass learnings down, which is kind of what we’ve seen on location. But it also might mean that like some managers or teams haven’t yet made room for the rest of the team.

Design engineers and leads at the top is unsurprising. Managers above juniors and mid-levels is the inversion, and remains basically unchanged from two years ago when Geoco’s 2024 survey found the same thing.

Leadership-IC Divide. Leaders adopt AI at a higher rate (29.0%) than ICs (19.9%)

So what’s the read? Geoco gives it the generous read first—learnings cascading down—and then concedes the other possibility: some teams haven’t made room for the rest of the team. Riddering puts it more bluntly: “I’m looking at a bunch of junior and mid designers that are getting cut out of the process.”

The other finding is that 59% of designers have built their own tool for their workflow. The example Geoco brings back from Vercel makes the builder-mode shift concrete:

When I went over to Vercel, they had this brand designer, who had never coded before. And now was vibe coding a tool. Their marketing team would put out blog posts. And they were like, “Why does the design team need to create the OG blog post cards for every page? That’s not a good use of [their time].” So he built a tool that just allowed them to insert any sort of images. And it just already had all of the branding and the sizing baked in. And they just roll these [tools] out quickly. And I’m like, that just became a tool, an internal tool. That’s cool. And so because it was really interesting that they started referring to him as a brand engineer… And I’m like, okay, that kind of qualifies it actually.

A designer who had never coded solves an actual marketing-team problem, ships the tool, and the role title arrives after the work. That is how the next batch of “blank engineer” titles is going to land. Riddering then describes how the orchestrator pattern works in his own day-to-day, offering a concrete account of the workflow I have been writing about as orchestration from a working designer:

Part of me is almost slightly self-conscious about it. But I do the vast, vast majority of my messy explorations with AI now. I feel like I have made the jump to the quote unquote creative director where I’m just working with AI to show me a certain thing 50 different ways. And then I’m pulling the pieces that I like and then combining them again. And finally I get to somewhere where I’m like, yep, that’s good. And then I take that from paper, run it through cloud code, and now it exists on localhost. And then I will sweat the details and actually do the precision designing in code, which is, that’s crazy, man. That’s a very, very different workflow than I’ve done at any point in my career.

The orchestrator gap is opening where I thought it would. What I did not account for is who is getting invited into that work first. The data Geoco surfaces points to leads, managers, and design engineers getting more chances to build with AI than junior and mid-level ICs.

Here’s a hypothesis I’ll put out there: leads are more used to directing. I’m personally comfortable with orchestrating, being the editor because I’ve been a creative director and leader for so long. The loop is right there: frame, review, direct.

After watching six agents design an app together in Pencil and spending a little time in Paper, I’ve been waiting for Figma to answer. Rodrigo Davies and Tammy Taabassum, writing on the Figma blog, finally announce it: a native design agent on the canvas, not bolted on through a separate app or a third-party MCP client.

Davies and Taabassum open with the pitch:

Designers need purpose-built tools that serve the essentials: exploration, experimentation, collaboration, and precision. Figma was built as a multiplayer canvas to make all of that possible. As teams adopt agentic tools to build products more quickly, false choices are emerging: Speed or precision? AI generation or direct manipulation? You shouldn’t have to choose.

Earlier this year Figma opened the canvas to third-party agents through its MCP server, letting Claude Code, Codex, and other agents push designs into a Figma file. That move covered the integration story. This one covers the in-app story:

That’s why we built the Figma agent. Our goal was to create an agent fluent in Figma and native to the way teams work. That meant making Figma itself legible to a model in ways that aren’t possible with third-party tools—with deep context on your components, tokens, standards, and best practices.

A third-party agent reaching in through MCP has to translate every request through a protocol; a native agent already speaks the file format. It knows your components, your tokens, your variables. That’s the gap between an agent that can edit a Figma file and an agent that lives in one.

The use cases Davies and Taabassum walk through—going wide on style explorations, bulk-updating variables across a design system, distilling comment threads into actionable plans—are the work designers were already paying the tax on. On exploration specifically:

The best designs rarely come from the first idea—or the first prompt. Exploring directions, comparing approaches, and iterating is already core to how designers work. Our agent will help you cover more ground in less time.

Renaming variables across a file, repeating padding changes through an entire flow, swapping one component for another across a dozen screens: that’s the busywork the agent is perfect for. The taste call on which direction to ship stays with the designer.

Davies and Taabassum close with:

Figma’s agent is embedded where the work already happens. There’s no toggle tax, no context switching, no learning curve. You stay in Figma and your team stays in the loop. We built this with one goal: to help you work faster without compromising on quality and craft.

That’s the competitive answer to Paper and Pencil. Agent-native canvases get a head start by not carrying any legacy assumptions; Figma carries millions of files and the design systems inside them. The bet is that the install base plus a fluent-in-Figma agent beats a greenfield canvas plus a generic one. We’ll see who’s right once the beta opens up.

Last week I linked Ravi Mehta on the three layers of context engineering for AI prototyping: functional spec, visual wireframe, structured data. Karo Zieminski, an AI PM writing Product with Attitude, makes the same case at the product scale and cites Mehta directly. Mehta wrote about prototyping one screen; Zieminski writes about designing the whole product around an agent.

Zieminski puts it in one line:

Prompt engineering is deciding what and how to ask the model. Context engineering is deciding what the model knows when it answers.

Then the asymmetry:

A well-crafted prompt in a poorly engineered context still fails. A poorly crafted prompt in a well-engineered context often succeeds.

That asymmetry is the argument for treating context as the underlying system.

If that asymmetry is real—and a year of using these tools tells me it is—then most teams are still optimizing the wrong layer. The visible artifact is the prompt. The work that actually decides the output is everything around it.

The piece I want to underline is who owns the work:

PMs define what goes in each context layer. Engineers build the infrastructure to fetch and store it… If the PM isn’t doing this, one of two things happens. Either an engineer makes the product decision by default, or nobody makes it and the agent gets every available signal dumped into the window.

Zieminski calls the alternative abdication. I think she’s right and I also think most PM job descriptions in 2026 haven’t caught up. The hiring filter still selects for ticket-shaping and roadmap maintenance, not for “decide what the model should know about the user, what should age out, what should never get re-fetched.” Those are product decisions about how memory is organized, and the people best positioned to make them—PMs who understand the product and the user—are often the ones least equipped to talk about retrieval and eviction. The gap is one of vocabulary and authority.

Both write for PMs, but the work is also design work. The context an agent sees is a designed surface: what gets included, what gets hidden, what should age out, what should persist between sessions. Mehta’s three-layer brief—spec, wireframe, JSON, twenty minutes in Figma, real data—is daily prototyping for designers working with agents now. Zieminski’s architecture is the system those prototypes live inside. If designers don’t show up here, PMs and engineers will design this surface for us.

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.