Alex Harper, writing for Web Designer Depot, describes the new baseline for web design work:

For decades, a significant portion of a web designer’s value was tied to the act of building: moving pixels in Figma, translating those pixels into CSS, ensuring the flexbox behaved, and troubleshooting why a specific button looked “off” in Safari.

But with the arrival of high-fidelity “Agentic UI” and the rise of what industry insiders are calling “Vibe Coding,” the barrier between a thought and a fully functional interface has effectively vanished.

Today, a founder can speak into a prompt—”Give me a high-end, minimalist FinTech landing page with a Swiss-style grid and a sense of ‘quiet luxury’ using deep emerald tones”—and receive a production-ready, accessible, and responsive site in seconds.

This is the AI design conversation with dollars attached. Once a small business owner can get a polished page for almost nothing, “pretty page” stops carrying much economic value.

Harper describes the commodity pressure as a loop:

The primary problem with Vibe Coding is that AI, by its very nature, is a statistical engine. It generates the most “probable” result based on your prompt. If you ask for a “Modern Minimalist” site, the AI isn’t going to innovate; it’s going to give you a composite of every modern minimalist site it has ever seen.

This creates a Feedback Loop of Averageness. 

1. Designers use AI to generate “vibey” layouts. 2. These layouts are published and become part of the web. 3. Future AI models are trained on these new layouts. 4. The aesthetic “mean” becomes tighter and tighter.

Designers have to take that feedback loop seriously. While the taste in the models are slowly getting better, AI nudges taste toward whatever the training set keeps rewarding. Notice a lot more serif fonts online recently?

That’s why “clean and professional” worries me less as a style than as a business model: if everyone gets the same acceptable answer for almost no money, the designer’s value moves into judgment, story, and constraints.

Harper adds:

To survive the Vibe Coding crisis, designers have to move away from the “Vibe” and toward the “Mechanism.”

If the “look” of a website is now a commodity, where does a designer provide value? The answer lies in the areas that AI still struggles to grasp: Nuance, Narrative, and Friction.

AI can create a page that looks like a brand, but it cannot yet build a page that feels like a story. Vibe Coding creates “scrollytelling” templates, but it doesn’t understand the emotional arc of a user journey. A human designer understands that a specific user might need to feel “uncomfortable” or “challenged” at a certain point in the flow to make a realization. AI only knows how to please.

An AI can generate a screen, but can it generate a philosophy? Designing a design system in 2026 isn’t about making components; it’s about defining the “Ethics of Interaction.” How does this brand handle data privacy through UI? How does it signal inclusivity without being performative? These are high-level strategic decisions that a “vibe” prompt cannot solve.

Cash App product designer Brad Wrage on moving design from handoff to production ownership:

Across this project, I personally merged 25 pull requests across three codebases — Android (14 PRs), iOS (8 PRs), and Server (3 PRs). As a designer.

And zooming out further — over the last two months, I personally authored ~45 PRs merged across 5 repos. As a product designer:

Wrage stayed accountable for the experience after Figma, across Android, iOS, and server. That is where the delay in a traditional handoff becomes obvious. It maps to Cash App’s org-speed bottleneck: building faster only matters if approvals, reviews, and deployment move with it.

Wrage describes the operational core:

This is where the traditional dynamic flips. Instead of filing bugs and waiting for engineering to prioritize them, I lead the charge — logging issues, kicking off fixes, and drive them to completion.

The process: visual feedback and bugs drop into a dedicated Slack channel. Builderbot — which intimately knows our codebase — picks them up and posts rapid fixes, often within minutes.

[…]

I pull the code down, test on a real device, reference my Figma file via MCP, and approve or adjust until it’s right. Every PR still gets a human review.

The guardrail is in that last sentence: code review remains part of the process. The result is a tighter loop between taste, implementation, and product judgment without removing engineering accountability.

Wrage’s phrase for that distance:

This is the inflection point. The designer isn’t on the sidelines filing tickets anymore — the designer is in the driver’s seat, leading the last mile to ship.

The last mile. The difference between “shipped” and “crafted.”

B. Prendergast revisits atomic design:

Atomic design is nearly ten years old. Brad Frost’s atoms, molecules, organisms hierarchy did something genuinely useful when it arrived: it gave teams a shared language for the idea that components are made of other components, all the way down. For a lot of people, including me, that was the conceptual unlock they needed to start building modular reusable front ends instead of pasting the same button in seventeen places. It worked. The industry absorbed it wholesale.

But I think we can probably retire the metaphor now.

Brad Frost’s watershed atomic design concept solved a real communication problem. It helped designers and engineers talk about components as things that compose, not screens that get pasted together. The problem starts when a teaching metaphor becomes the operating model.

Prendergast describes the tax teams pay when that happens:

The problem I keep running into with teams over the years isn’t that they don’t understand atomic design. It’s that they’ve understood it too literally. They’ve set up their Figma and Storybook libraries with Atoms, Molecules, and Organisms sections. They’ve had the naming convention conversations. And then, reliably, they get stuck arguing about whether a card with an avatar and a label is a molecule or an organism. That conversation is a tax. It doesn’t produce better components. It produces friction, disagreements, and the occasional afternoon lost to taxonomy instead of building.

That’s the part I care about in design systems. A good library should make the useful path obvious: which pieces can be reused and which contracts they have to honor. If the library mostly teaches people to sort objects into clever buckets…well, that’s a distraction from the work.

Prendergast closes with the on-ramp caveat:

I’m not arguing against atomic design as an on-ramp. If someone on your team is new to component-based thinking, the atoms/molecules/organisms scaffold is still a powerful and reasonable way to introduce it. Use it. Just don’t park there. The abstraction to keep is composability. Components compose up from smaller components. There are no real required levels between the smallest useful unit and a whole page or view. Whether an intermediate component is a molecule or an organism is a naming problem, not a design problem. We can stop solving it now.

The real test of a design system isn’t whether every component sits neatly in the correct layer of a hierarchy. It’s whether people can understand it, trust it, use it, and extend it without breaking it.

Nobody ships a better product because they correctly identified a component as an organism instead of a molecule. Atomic design succeeded because it taught people to think in terms of composition. Components built from components. Small pieces combined into larger ones. Clear contracts. Predictable behaviour.

Everything else is bookkeeping.

Tony Le separates a usability problem from a clarity problem before the team starts redesigning screens:

A usability problem is when the user understands the promise but struggles to complete a task.

A clarity problem is when the user never forms a confident mental model in the first place.

They hesitate. They guess. They bounce. Not because the UI is hard, but because the product is not making a clear argument.

Le’s example shows the distinction in practice:

A few years back, I worked with a company building an internal SaaS product, something they planned to launch within about a year.

They did a lot of things right early on. They invested in research. They poured real money into development, easily in the five-figure range. The team was shipping.

Then onboarding came up.

The owner tried to use the product and got stuck.

Instead of treating that moment like a signal to test the build, align on how the system worked, and validate the onboarding path, the conclusion was immediate.

This is a UX and UI problem.

So the team did what teams often do under pressure. They rebuilt.

They revamped the system once.

Then they revamped it again.

And after all that effort, the real issue came into focus. The UI was not broken. The product lacked a shared, plain language model of how it worked. Key concepts were obvious to the people building it, but not obvious to the person trying to onboard into it. So when onboarding started, confusion showed up as hesitation and wrong clicks, and the team assumed the interface was the culprit. They revamped the system twice, only to learn the real fix was clarity, clearer concepts, clearer naming, and a clearer first win.

That is the part teams miss. The stuck user is real, so the design critique feels real too. But if the product has not made a clear argument, every screen-level fix is downstream of the wrong problem.

I see this most often in products that have accumulated internal language. The team knows what a feature is for because they have lived with the roadmap, the sales narrative, the customer calls, and the implementation details. A new user gets none of that. They get a label, a blank state, a primary button, and maybe a tour.

So clarity is not just better copy. It is the product choosing what it is asking the user to understand first. The interface can make that choice visible, but it cannot make the choice for you.

Jason Cyr, writing at The Human in the Loop, starts with the AI-design conversation’s taste claim and points to the work teams need before agents start producing anything:

There’s a popular narrative that design’s value in the age of AI is taste — the human eye that says “not that, this.” I think that undersells us. Taste matters. But what organizations actually need from design right now is clarity. The ability to wade through ambiguity, make invisible systems legible, and give teams something they can act on. That’s always been the real (often under-appreciated) superpower, and AI just made it an urgent need.

Cyr’s earlier piece on agentic-era design teams covered the move from making outputs to directing work. Here, he describes the coordination layer that had been hiding inside the old process:

The old product development process had shock absorbers we never realized. Meetings where people quietly aligned on things that were never written down. Hallway conversations that resolved ambiguity nobody had formally surfaced. Design reviews that were really translation sessions — designers decoding what product actually meant, engineers decoding what designers actually intended. PMs who held critical context in their heads and dispensed it as needed.

None of this was in any process document. It was human labour — invisible, unacknowledged — absorbing the ambiguity that the formal process couldn’t handle.

We called it process, but it was actually a buffer.

Cyr puts that clarity work inside design leadership:

Here’s the thing about this problem: it’s not a tooling gap. It’s not a project management gap. It’s a clarity gap.

Design earns its seat at the table when it moves beyond artifacts and starts shaping how a product organization delivers work. Not just the screens. Not just the system. The operating model itself — who decides what, when something is ready, how context travels, and what “good enough” means at each stage.

Fabrizia Ausiello, writing for UX Collective, uses Apple’s Liquid Glass transparency slider to ask who is supposed to make interface judgment calls:

Apple just introduced a transparency slider for its Liquid Glass UI — a control that lets users dial up or down the translucency of system elements. On the surface, it’s a thoughtful accessibility gesture (especially considering the criticism that Liquid Glass has accumulated), but in practice, it’s the manifestation of a deeper tension that designers have been circling for years: when you give users a knob, are you empowering them or just finishing your job somewhere more convenient?

Ausiello on the older design assumption that users shouldn’t have to make these calls:

For most of the history of digital product design, designers have been making decisions so users don’t have to. We studied, tested, iterated, and then shipped something that worked. Interface design is opinionated because it has to be.

It might sound arrogant, but it really isn’t, it’s simply part of the craft that’s baked into the role. The whole point of a well-designed system is that it removes cognitive load; the moment you ask a non-technical user to evaluate the “level of transparency” of their interface, you’ve already failed them because they don’t have a mental model for it, they just want to read their notifications.

I agree. As designers, we should be making this call. Ausiello turns the same question back on us:

If you work in digital product design, this moment is worth paying attention to for the precedent that it’s setting.

As AI takes over the execution layer — generating screens, producing variants, handling repetitive interface decisions — the value of a designer is shifting and the role that remains is the harder one: understanding the problem deeply enough to know which decisions shouldn’t be delegated at all.

Some things should be personalised, some should not, and knowing the difference, having the conviction to hold that line, is a skill needed and worth having. Dumping a slider in onboarding isn’t personalisation — it’s a designer who didn’t finish their job.

The future of adaptive interfaces is exciting, but getting there doesn’t mean abandoning judgment in the present. It should mean being more deliberate about which decisions belong to the system, which belong to the user, and which belong to you.

Interestingly, Ausiello also gives Apple an out. That maybe, Apple is playing the long game here and gathering data to make personalization more automatic in the future. The author again:

The reasoning goes roughly like this: we don’t need to commit to a specific default, because the AI will figure out the right setting for each user eventually. Siri will learn your preferences and you’ll just ask it to make things more readable and it’ll handle the rest. Seen from this perspective, the slider isn’t a UI failure, but rather an early, manual version of something that will eventually be automatic.

Honestly, I think it’s a bit of a stretch. Nice thought exercise though.

Amber Bouabdallah, writing in UX Collective, gets at the learning problem lots of designers are facing in this AI transition: the tools don’t produce one shared path toward competence.

Bouabdallah draws the line between deterministic software training and relational AI practice here:

Traditional software training works because the tools are deterministic. You learn where the buttons are, what the shortcuts do, how the system behaves when you click the thing. Mastery, in that world, converges — everyone arrives at roughly the same competence, following roughly the same path, and you can write a training deck for it. Mastery means knowing the tool’s correct use.

AI tools break that definition. Maggie Appleton — designer and anthropologist, now at GitHub Next — gave a talk in 2023 called “Squish Meets Structure” about designing products with language models, and the line from it that I love is her description of the magic-input box: it has “no affordances,” “no knobs or door handles.” The interface, she writes, “offloads a ton of cognitive labour to the user.” There is no correct use to learn. The tool meets you where you are. Which means what you bring to it — your instincts, your mental models, your accumulated taste, your willingness to iterate, your custom claude.md files — is the tool, as much as the model is.

So mastery hasn’t disappeared. It has shifted. With deterministic software, mastering the tool meant converging on its logic. With AI tools, mastering one means the opposite: learning to bend it toward your logic. Tailoring it to how you already want to work. Mastering an AI tool is the craft of making it amplify the specific strengths and experience you bring — so the work that comes out is sharper, and unmistakably yours. That kind of mastery is real, and hard-won, and worth teaching toward. It is just personal rather than universal. Divergent rather than convergent. Everyone’s version of it should look different, because everyone’s version is built out of a different person.

Her Salesforce examples keep that from becoming an abstract tool-training claim:

Six months in, Ningdan and I had designed for tool adoption and accidentally created conditions for something more intimate. Seeing each other work. Seeing the specific choices someone makes when the tool doesn’t behave, the workarounds they’ve invented, the mental models they’ve constructed to make sense of something genuinely new. A window into someone’s thinking — and into how each person was mastering these tools in a shape no one else’s would match.

And once you can see the thinking, you can see the worry too. Amanda Harris, a User Experience Architect on our team, named a tension directly in the post-mortem: “I worry that we’ll lose the exploratory aspects of finding what’s wrong with an idea by jumping so quickly into hi-fi prototyping.” That’s not resistance to new tools. That’s a designer protecting something she knows matters. Hearing it voiced — in a room where everyone is nominally learning the same things — is only possible in a setting small enough and safe enough for honest uncertainty.

The anxiety designers are feeling is a signal, not a weakness.

And Bouabdallah closes by naming the training layer her team actually designed:

The tools will keep changing. They will keep arriving faster than any module can be written, any best practice can be documented, any official curriculum can ratify. It is tempting to treat the peer layer as a bridge — something to lean on until the real training arrives. But the real training is not coming, because there is no fixed competence to train people toward. As long as the tools keep moving, the peer layer isn’t the bridge. It’s the ground.

We did design how designers master AI. We just found that mastery wasn’t what we thought it would be. Not a competence everyone arrives at, but a practice each person builds — bending a generic tool toward their own strengths, their own experience, their own way of working, until the work it helps them make is sharper and theirs.

Nicole Alexandra Michaelis, catalogs the job titles opening up as AI takes over the production work. Titles like “AI Design Consultant” (aka forward deployed designer), “Agentic UX Architect,” and “Trust Designer.”

These new titles are flashy, as she says, and I’m wary of crazy titles as I believe “designer” is a good catch-all. Michaelis seems to agree:

The “Product Designer” used to be the top of the crop, working with content designers, motion designers, UI designers, service designers, and more. But all of these titles had one thing in common: deeply strategic design thinking. While product design was often treated as the most T-shaped profile amongst designers, I always believed any (good) designer could shift in and out of skills and ways of working quickly, independent of their specific title.

The constant she identifies—deeply strategic design thinking—is the job; the titles are what we print on the business card in any given season. I’ve watched these labels multiply over the years, and the strong designers always moved between them regardless of title.

Take the Trust Designer:

The Trust Designer focuses entirely on transparency. They translate complex cryptographic or algorithmic verification into instant, split-second visual signals. They design the metadata tags, watermark indicators, and explainability mechanisms that show consumers exactly why an AI recommended a specific product or how a piece of media was verified.

The work here is genuinely needed. Translating something invisible—verification, provenance—into a split-second signal a human can trust is design at its core, not pixel-pushing. This is the part worth taking seriously, regardless of what we call the person doing it, or that it’s its own full-time job.

Michaelis again:

Ultimately, this shift is incredibly empowering for the creative community. The lesson of the AI age isn’t “learn to code or get replaced.” It is that design is moving away from the mechanics of pixel production and shifting heavily toward cognitive psychology, systems thinking, and business orchestration. And I would argue, most of us loved that part of the work most anyway.

She’s right about where the work is heading, and the only thing I’d watch is the title proliferation. The strategic judgment underneath is the same craft it’s always been, whatever we end up calling it.

The AI job grief piece was about what happens when old roles stop feeling stable. Sarah Gibbons, writing for Nielsen Norman Group, gets at the next question: what are we actually supposed to call the new work?

When someone says “AI design,” everyone in the room pictures something different.

One person is thinking about using AI to generate component variations for a design system. Another is designing a chat interface. A third is structuring data so an AI agent can parse it. A fourth is defining an LLM’s behavior.

They all fall under “AI design” but they are not the same work.

I see this in job postings, LinkedIn posts, and conference talks. Someone says, “We need to figure out our AI design strategy,” and every person at the table nods — while imagining a completely different thing. Six months later, everyone’s frustrated because the “AI-design initiative” was not what they expected. 

The conversation around AI and design is forking. What used to be a single (admittedly vague) topic has split into at least four distinct orientations. Each one focuses on a different type of design work, sits in different organizational structures, and uses different definitions of what “good” looks like. Most teams are staffed for only one of these orientations, confused about which one they’re doing, or trying to dance between all of them without realizing it.

Gibbons’s agent-facing category moves the taxonomy beyond the human interface:

This one is going to feel like a departure from user experience. Stay with me.

In this type of work, you design content, data, or interactions that AI agents (not humans) will read, parse, or act on. You’re building the infrastructure that autonomous systems navigate. If AI agents are the self-driving cars, you’re designing the roads, the signage, and the lane markings. AI agents are your users.

That might mean structuring product data so a shopping agent can compare options on behalf of a user, writing instructions that an AI assistant will follow, or optimizing content for AI search and discovery instead of (or in addition to) human search and discovery.

Some of this infrastructure won’t even be human-readable. A road sign designed for AI-controlled vehicles might encode information in ways no human driver could parse — data transmitted via radio or embedded in nonvisible parts of the spectrum. The “user” of that sign is an agent, and the design constraints are entirely different.

This is the orientation most design teams are still ignoring, but mostly because many organizations don’t have anyone explicitly responsible for how AI agents experience their product. Which means it’s either not happening, or it’s happening by accident inside an engineering team with no design input.

Designing for AI agents matters because it involves design decisions. What data gets exposed? How is it structured? What can an agent do versus what requires human confirmation? These shape the end-user experience just as much as any interface, they’re just one layer removed.

She then ties that category shift to the market for design expertise:

Understanding which type of AI design you’re building expertise in matters because the market is moving fast. Right now,  few designers have deep experience across multiple orientations. However, this window won’t stay open for long. Within a year, many more designers will have meaningful AI experience. Those who build depth in a specific direction now will have a significant advantage over those who stay broadly “AI-adjacent.”

Here’s where the field is right now:

Most designers today are using AI as a tool in their workflow. A growing number are designing AI products and features. Very few are designing for AI agents or designing the AI itself.

The demand for those last two is growing. The supply of designers who understand them barely exists. So, if you’re a designer, its an opportunity gap that’s widening.

Jack Maguire writes about AI displacement as a grief problem, not only a labor-market problem:

Knowledge workers hold a different relationship to their labor than manufacturing workers did. For a cognitive professional, expertise is not only an activity. It is a large part of the self. A data scientist who has spent a decade building statistical judgment does not experience that judgment as a detachable tool. It is closer to a personality trait. When automation threatens the work, it reaches past the income and touches the identity.

I can certainly relate—my profession is my identity and sense of self, unhealthy as that may be.

Maguire on disenfranchised grief and AI layoffs:

Even where grief exists, workers are denied social permission to feel it, and the denial makes the grief worse.

The relevant concept is disenfranchised grief, a term coined by the grief researcher Kenneth Doka for loss that is not acknowledged or socially supported. As one accessible summary puts it, disenfranchised grief is “grief that is not acknowledged or socially supported, often because the loss does not conform to societal expectations of what should be mourned.” When a loss is not recognized by others, the grieving process stalls, and the grief stays “hidden and unresolved.”

Tech layoffs are engineered to produce exactly this condition. They are framed as strategic pivots, restructurings, and efficiency measures. The language is designed to read as ordinary corporate hygiene, and it forecloses mourning by refusing to name a loss at all. There is no ritual for the end of a profession, no obituary for a career, and no socially sanctioned grief leave for the worker who has watched the meaning drain out of work that technically still pays.

The default cultural model for grief still tends to be the five stages of grief, popularized by psychiatrist Elisabeth Kübler-Ross: denial, anger, bargaining, depression, acceptance. Maguire’s point is that AI displacement does not behave like a bounded loss moving toward acceptance:

The Kübler-Ross framework assumes that acceptance is reachable, because the loss it was built to describe is finite. When a person dies, the absence becomes permanent. The bereaved adjusts to a stable, if painful, new reality. Acceptance is possible because there is something fixed to accept.

AI displacement does not offer a fixed endpoint. The process is ongoing and accelerating, with no stable post-AI equilibrium to adapt to. A worker who retrains into the safe role of this year may find that role automated within two years. There is no permanent absence to grieve, only a moving frontier. Workers are being asked to accept a process rather than an outcome, and the process keeps advancing.

Apple’s developer conference WWDC kicked off on Monday with a keynote. They announced various OS improvements, including refinements to Liquid Glass, and most importantly, a revamped AI strategy.

In the days leading up to the keynote, longtime Mac journalist Jason Snell wrote about building his first Mac app with Claude Code in just a couple of hours. We’ve heard this story before. We’ve been talking about it here for months. And yet, here’s a veteran technologist who’s just now discovering Claude Code’s power and building an app.

It’s easy to get caught up in the Silicon Valley AI hype bubble and think the whole world has changed and is using AI for everything. But no, that’s not actually the case.

Snell on what the experience actually required:

The process of building the app reinforced something I’ve been thinking about for quite a while: coding is a specific skill, but it’s only one part of a much larger process. Great developers aren’t necessarily great coders, though they can be. Apps must be envisioned, their specifications defined. The act of trying to describe an app to an AI coding engine is a clarifying one. The more you describe the app, the harder your brain has to work, because it’s always more complicated than you think it’s going to be. The decisions you make determine what the app comes to be. […]

Yup, tell me about it. Tell us product builders about it! The code was never the hard part.

Where I’d push back is on the optimism around it:

We now live in an era where, if you can dream an app, you can probably build it. Especially Mac utilities. And who cares more about native Mac software than Mac users? Certainly not those companies that gave up on Mac development and focused all their energies on giant cross-platform code bases to attract venture investment and big payouts.

Snell himself calls his app “ugly and incomplete” a paragraph earlier, so “if you can dream it, you can build it” is a bit of a stretch. The gap between a thing that runs and a thing you’d ship is where the real work lives: envisioning, deciding, refining.

And it’s a reminder of where the next barrier sits. Snell ends on the tooling:

Which brings me to a final point: Apple’s development tools, most notably Xcode, are nightmarish. My developer friends are used to them, but as someone who has never really used Xcode before, I was shocked at just how deeply unintuitive it is. As in, Claude would tell me to click on things, and I would have to reply, “I have no idea what that is or where it’s supposed to be.” And I’ve been a Mac user for a long time! I’ve gotten very good at intuiting where stuff is in a Mac interface.

[…]

While AI tools have made it more possible to build apps on Apple’s platforms, the developer tools themselves are still a formidable barrier. As the definition of “developer” changes, so, too, must the definition of developer tools.

I wholeheartedly agree with Snell that Xcode is a mess. For those like me who only open it on occasion, it’s baffling that Apple developers live with such a nutty application. Take a look at the best of Apple’s first-party apps like Keynote, Final Cut, or even Numbers, and Xcode is just…bizarre.

Apple did announce something at WWDC 2026 that was interesting—that nods to where they could go if they wanted to—users can ask Siri AI to vibecode Shortcuts and Safari extensions. Will have to see if that’s the seed for something.

Arpan Patel wrote a nice consolidated Claude Code reference: the directory layout, CLAUDE.md the way Anthropic’s Boris Cherny writes it, skills, subagents, MCPs, the underused commands. The whole guide turns on one shift:

Claude Code clicked for me once I quit treating it like ChatGPT in a terminal. The mental model flipped from “I need to write this code” to “I need to set Claude up to write this code well.” Setup is the work. Execution is verification.

If you use Claude Code daily, bookmark it.

Emma Webster, writing for Figma, argues that AI tools are pulling prototyping earlier in the product process: teams can validate with more fidelity, then carry design context forward instead of recreating it at handoff.

Product teams are rapidly adapting to the new way of working in the AI era. They’re prototyping before writing specs, testing in code before designing, exploring at unprecedented scale, and shipping with design system context that used to get lost in the handoff. We talked to product builders at FloQast, Merkle, Affirm, and Accor about how that’s playing out in practice.

The shift is about when the hard questions show up. Specs used to be the artifact that let teams pretend they had alignment. The team behind Claude Design skipped the PRD entirely and prototyped its way to the answer instead. With AI tools, a prototype can become the first serious question: does this flow hold up when the data, logic, motion, and system constraints are present?

Webster describes the code-to-canvas loop this way:

Testing an idea against intricate constraints—things like multi-step flows where one action triggers the next, or interfaces that behave differently depending on the data behind them—used to require significant developer investment. Today, AI coding tools have made it possible for more people on a product team to quickly build and test these kinds of interactions before committing to a direction. That’s opened up a new workflow. A product builder can create a working prototype in code, then move it onto the Figma canvas using Codex to Figma to see the full picture and refine it together. From there, if more work needs to happen in code, they can move back via MCP with the design context intact.

This is the version of AI-assisted design I care about. Not “prompt a shiny UI from a blank page.” A working model becomes the place where designers, PMs, and engineers can see the same problem at once. Figma is still the canvas for style exploration and visualizing complex flows, but the decision surface is becoming more product-shaped.

That matters because prototype fidelity changes what a team is allowed to learn. A flat mockup can test preference and comprehension. A working prototype can test sequencing, edge cases, permissions, motion, and whether the idea survives contact with real constraints. Bringing that earlier into the process should make design less speculative, not less thoughtful.

The Accor example shows why this matters before anyone commits to a build:

Justine opened Figma Make and prototyped something she wouldn’t have had time to build by hand—a webpage that reorganizes itself based on what the user types. Search for “golf” and the page reshapes around properties with golf courses, curated outings, and relevant experiences. Make handled the micro-interactions and transitions, and the Figma MCP server kept everything connected to the brand’s design system. Within days, she had a working prototype ambitious enough to show leadership what was possible—and concrete enough to start a real conversation about what to build next.

Webster’s Affirm example carries the same logic all the way into production:

A PM prototyped the badge variations in Figma Make—going from idea to working prototype in two days instead of the usual six weeks. Designers refined the winning direction on the canvas, and when the team was ready to move that design into production, they loaded the design artifacts into the Figma MCP server and connected it to Cursor. MCP passed the components, tokens, and layout structure directly into the coding environment, where an AI agent generated the front-end implementation. Developers used that as their starting point, building production code that already reflected the designs instead of reinterpreting them from scratch.

Preserving components, tokens, and layout structure turns the prototype into a rehearsal for the real build. It has enough fidelity to expose bad directions early and enough context to keep the winning direction from being rebuilt from memory.

Simon Willison thinks the AI labs have found product-market fit. Here’s his own monthly usage priced at API rates against the $200 he actually pays:

• $1,199.79 for Anthropic Claude Code
• $980.37 for OpenAI Codex

That’s $2,180.16 worth of tokens for $200—not bad at all! I’m a moderately heavy user of these tools, but I’m certainly not running agents every hour of the day and night.

That discount is gone: since April 2026 enterprises pay full API rates. Willison’s read:

Coding agents really did change everything. These are tools which burn vastly more tokens, but are also quickly becoming daily drivers for the work carried out by extremely well-compensated professionals. Right now that’s still mostly software engineers, but a coding agent is a tool that can automate anything you can do by typing commands into a computer… so they are clearly applicable to a much wider set of skilled knowledge workers.

Right now the bill falls on engineers. Designers may be next. Anthropic has already rolled out a separate usage meter for Claude Design. And Figma is charging for AI usage overages.

Mozilla.ai’s Alejandro Gonzalez asks a useful question for designers working through agent-native software: what is the agent actually editing in the first place?

He starts with Claude Design but the piece is really about the old software contract underneath most productivity tools:

Most human-computer interaction has been built around two patterns: issuing commands (typing, clicking, speaking) and manipulating representations (dragging, resizing, arranging, formatting). Every productivity tool ever built is designed around one or both of those. The keyboard, the mouse, the touchscreen. That is the full vocabulary. The interface and the product were, for practical purposes, the same thing.

This is a useful distinction for designers because it doesn’t treat UI as decoration. It treats UI as a historical compromise: the thing humans needed in order to reach the state underneath. Agents put pressure on that compromise because they don’t need the same surface.

Gonzalez is careful about the transition, though:

This is useful. More than useful, it is probably necessary. The world already runs on existing software. Companies have years of organizational knowledge embedded in Gmail, Slack, Jira, Salesforce, Notion. If agents are going to be helpful today, they need to work inside that world.

That is the bridge.

But the bridge is not the destination. Agents using existing apps help bring AI into the current software stack. Apps built for agents may change the shape of the stack itself.

And there is something more valuable in that process than just short-term utility. Watching where agents struggle with existing interfaces, where the translation between intent and UI operation is most painful, is probably the most honest way to find where the structural opportunity is. The friction is the signal.

The agent failing to use a legacy screen isn’t only a product bug; it may be a map of where the product’s abstraction is wrong. For design teams, that shifts the work from polishing the path through a tool to naming the real object of work.

Gonzalez’s product-strategy example makes that abstraction concrete:

The source of truth for a product strategy is not the slide deck, the roadmap doc, the ticket board, or the dashboard. It is the strategy itself: the goals, the bets, the risks, the owners, the metrics, the decisions. Everything else is a view. The memo, the board deck, the launch checklist, the customer brief are renderings of the same underlying object, shaped for different audiences.

A product launch is not a Notion doc, a Linear project, a slide deck, and a dashboard. It is a product launch.

In Gonzalez’s framing, the deliverable is no longer the deck, the board, or the dashboard. The durable thing is the structured model that can be rendered, checked, diffed, approved, and exported.

That is the part that changes the designer’s job. If the source of truth is a structured object instead of a visible artifact, then design has to specify the object: its fields, constraints, permissions, states, failure modes, and views. The screen becomes one projection among many. A human may need a deck, an agent may need a schema, a manager may need a dashboard, and the system needs a versioned record of what changed. Those are not separate products if they are all renderings of the same underlying thing.

Gonzalez closes by keeping the old tools in the frame:

The old tools will not vanish quickly. They have distribution, habits, enterprise contracts, file compatibility, and decades of user training on their side. But the center of gravity moves. The work happens in the agent-native system. The legacy app receives the export.

I do not think this transition will be clean. The old world will remain around us for a long time. People will still export PowerPoint files, update spreadsheets, paste things into email, and manage work through tools that were designed before any of this existed.

But that feels increasingly like a transitional phase.

The more interesting future is not only agents operating apps. It is applications designed so agents, humans, and existing tools can all work with the same underlying objects.

Not because every app disappears but because the source of truth may move.

Jakob Nielsen starts from OpenAI’s new $4 billion consulting arm and its acquihire of 150 Forward Deployed Engineers, the kind who embed with a client instead of building from headquarters. His argument is that they solve the wrong level of the problem: you can speed up the work without changing it. The missing counterpart he proposes is the Forward Deployed Designer.

Nielsen draws the line between faster individual work and a faster business:

With AI, the old workflows must no longer be treated as the design brief; they must be questioned at the root. AI is, in fact, a great productivity enhancer even when used in the traditional way to increase the efficiency of individual employees performing the same tasks as always, just faster and better. A paralegal can summarize a legal brief in seconds; a junior developer can write boilerplate code instantly; a digital marketer can generate campaign copy with a single prompt. We can typically improve that employee’s performance on those specific rote tasks by roughly 40%.

But at the company-wide level, such local productivity gains rarely translate into substantial profit gains and shareholder value. When you have a long chain of steps and optimize only a few, the delay simply shifts to the remaining steps, which will dominate the overall time to solve the underlying problem.

Nielsen again:

Once AI removes the cognitive bottleneck, a different bottleneck appears: authority. The limiting question becomes not “Can the system know what to do?” but “Is the system allowed to do it?” AI-native workflow design must therefore redesign decision rights, escalation rules, audit trails, and accountability boundaries. Otherwise, the organization merely replaces slow human cognition with fast machine recommendations waiting for the same old human permission structure.

The line usually attributed to Einstein goes like this: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” It is a warning against racing to the answer. Gale Robins, writing for UX Collective, makes the same case for product teams—then moves it one step earlier than Einstein did.

Her subject is the decision that rarely gets scheduled: whether a customer signal deserves discovery at all. She calls it Signal Evaluation, and she describes it bluntly:

Signal Evaluation is not a box to tick on the way to the real work. It is a filter, and a good filter is defined by what it keeps out. If most of what reaches your team makes it into discovery, the filter is not working; it is just a turnstile.

This is Einstein’s 55 minutes, relocated:

It is tempting to think discovery begins when you start talking to customers. It begins one step earlier, with the call to research this rather than something else. Every signal that reaches a team […] arrives carrying an implicit claim: this is worth your attention. Evaluating a signal is the act of testing that claim before you spend anything on it.

The difference she leans on is between a feature signal and a job signal:

The distinction that matters is whether the signal is about the customer’s job or about your product […]. “The export button is confusing” is a feature signal: it concerns your solution and usually warrants a quick fix rather than a discovery effort. “I cannot get my insights to my stakeholders” is a job signal: it is about what the customer is trying to accomplish, and it may hide an underserved need worth real investigation.

That is the trap Einstein was guarding against. The seductive request arrives pre-packaged as its own solution—add the widget, fix the button—and it is tempting precisely because it lets you skip the 55 minutes. Robins’s point is that a signal can be strong, genuine, and still aimed at the wrong job.

Here is where she goes past Einstein. His hour is already committed: he has a problem and is deciding how to spend time inside it. Robins is working a layer earlier. Her question is whether the signal has earned the hour in the first place. In her words, the skipped judgment is “whether to begin it at all.” Signal Evaluation is the gate before Einstein’s clock even starts.

AI is what makes that gate matter more now, not less.

AI can scan your entire feedback corpus, cluster signals by frequency, surface correlations with churn, and tell you in minutes that the widget request appeared in twenty-three of forty calls. That is genuinely useful and genuinely predictive: pattern-finding at a scale no human can match.

But notice what AI cannot do in that example. It can tell you the signal is strong. It cannot tell you the signal is pointing at the wrong job. That judgment, that “more widgets” is really “I cannot see what matters,” and that building the literal request might make things worse, is meaning-making, not pattern-matching.

Tokyo Design Forum publishes former Facebook and Dropbox design leader Soleio’s closing talk from this year’s conference, where he previews a book-sized thesis called The Geometry of Luck. Soleio’s move is to treat luck less like a mood and more like a design problem: a question of arrangement, position, and conditions.

He starts with geometry because geometry gives the argument its discipline:

When we say something has a geometry, we mean it has structure.

Not just parts, but relationships between parts, distances, angles, arrangements that produce specific properties.

For example, a triangle just isn’t three lines, it’s three lines whose arrangement do something. The interior always sum to 180 degrees, no matter the triangle. That is geometry. It’s structure that produces reliable properties.

So when we talk about the geometry of a room, or the geometry of a negotiation, or the geometry of a network, we’re saying something very specific about its nature. We’re saying its composition, its arrangement, tells us more than a list of its parts.

That saves the talk from becoming another self-help riff on “making your own luck.” Soleio is more precise than that. He is saying luck has variables, and designers already understand the work of arranging variables toward a purpose. He links that to industrial designer and architect Charles Eames’s definition of design as a plan for arranging elements toward a purpose.

When something has a geometry, it can be measured, it can be reasoned about, it can be taught.

[…]

So geometry is a language of arrangement.

For designers, it’s like the vocabulary of our craft.

From there, the framework becomes practical:

I believe luck has three facets, three independent variables that work together in concert. They are the basic elements of good fortune.

The first I call orientation, how we perceive our environments and place ourselves within them.

The second is surface area, the degree to which we’ve made it easy for good fortune to find us.

And the third is novel action, our capacity to act on what we perceive, what we do with the opportunities that the universe presents to us.

The useful distinction here is agency without control. You don’t command the outcome. You arrange the conditions: what you can see, who can find you, and whether the value you create can keep circulating after it leaves your hands.

That is why the talk eventually turns back toward software design:

As software designers, we shape the environment where luck happens.

We are very, very lucky to be here in this room today.

Few inventions touch the fabric of people’s daily lives, such as software.

Every interface, every space, every system we create either amplifies or dampens the flow of opportunity for the people who encounter it.

With every over-the-air update we push to production, we alternate the networks through which luck flows.

And so I hope designers put as much consideration to luck as they do look and feel and utility.

I like that as a design brief. Not “be lucky.” Not “hustle harder.” Arrange yourself, your work, and your systems so more good fortune can pass through them. Test hypotheses. That is a useful bar for products too.

The line running through Tobias Van Schneider’s interview is simple: designers complain about tools all the time, but the better move is to build the environment you wish you had.

Nikolas Wrobel interviews designer Tobias Van Schneider, founder of Semplice and mymind, and the profile traces that pattern directly: Semplice for portfolios that didn’t fit the platform/template world, then mymind for thinking without the performative noise of social media.

Van Schneider:

How do you protect yourself against consuming, draining effects from Social Media, or disenchanting tech-mechanisms?

This question almost too perfectly leads into what I do everyday. In part, I protect myself by using mymind.com (which I created) — there are no ads, no vanity metrics, no social media features, nothing but myself. Only me and the things I care about. Over the years, mymind has become so valuable to me, it’s the first place I go to look for inspiration. In fact, while I am answering this interview, I find myself going back and forth between old notes and musings inside mymind.

Social media still drains me, just like everyone else, but it’s nice to at least have one place just for myself. And thats mymind.

Aside from that, I just get offline and out into the world. Or I create something.

Van Schneider isn’t pitching another social layer; he’s describing a private room for memory, taste, and reference.

He later explains where that product idea started:

As with many things, it was a total coincidence. When we initially worked on the mymind product and brand, we didn’t even have the name “mymind” yet. The whole thing was called AWMT, which stands for “As We May Think” and is a reference to an old essay by Vannevar Bush from 1945 in which he wrote about a machine called “The Memex” which was some sort of machine that collects and connects your personal knowledge.

Coming off of that inspiring essay, we came up with a slogan called “Think for yourself” which is sort of the antithesis to the cloud/hive mind of what we call social media today. Especially since we position mymind as a private sanctuary, it just made sense to us.

All of this eventually got me into the rabbit whole to search for ideas for our logo. The classic “Thinker” statue immediately came to mind. I always loved that one, a man deep inside his own thoughts, unfazed by the world around him. But the statue was a bit too literal to me, too well known, too sharp and serious. We needed something more abstract, more playful. Eventually I found out about Cycladic art, originating from the Aegean islands during the Early Bronze Age. Very famous for their minimal and stylized marble figurines. Now, the rest is history. I immediately fell in love with the simplicity of it and it felt like a great canvas to build our visual universe on it. The rest is history (:

Wrobel asks Van Schneider about the conditions he works best under:

The creative me enjoys being alone. Completely isolated, nobody even in the other room. It gives me freedom and clarity to think for myself and be myself. My real creative being thrives in these moments, untouched by the opinions and desires of others.

My ultimate solitude tends to arrive at midnight. It almost transforms me. The dark brings focus. Silence brings new ideas. No voices interrupt, no chance of emails, just me and my thoughts. It’s this time I feel most creatively alive.

Now, add a soundtrack to it and I’m in creative heaven (:

I don’t think every designer needs midnight solitude. But design work does need stretches where taste can form before it becomes consensus. In a work culture that treats collaboration as a default good, that distinction matters.

This is also why the tools question matters. A portfolio system, a private reference space, even a type foundry site are not neutral containers. They either protect the conditions where taste can develop, or they pull the work back toward the defaults of the platform. Van Schneider’s career makes that feel less like a manifesto and more like a working habit: when the available environment makes the work smaller, build a different environment, then keep using it until it changes the work.

Van Schneider’s favorite advice turns complaint into output:

“The best way to complain is to create something” by James Murphy, founder of LCD Soundsystem. It has become one of my guiding principles. It turns useless, negative energy into productive, positive energy.

Design leaders spend a lot of time telling teams to experiment with AI. Nathan Lavertue, a Design Program Director for IBM Z and LinuxONE, turns that advice back on leadership itself:

We spend a lot of time helping designers understand how to work with AI. The question I keep coming back to is simpler. How many of us are doing the same for ourselves in ways that meaningfully support the business?

So instead of just encouraging my teams to experiment with AI tools, I put myself in the work. I built a design program signals website using IBM Bob. What started as a wireframe to sketch out an idea became something I realized I could actually build myself. That surprise is the whole story.

I appreciate the reciprocity here. If designers are being asked to work through this shift in public, leadership cannot treat AI as a strategy deck it reviews from a comfortable distance. You cannot build useful judgment about these tools by asking other people to absorb the uncertainty for you. That is why I’ve been reading about them, writing about them, and experimenting with them on my own. Whether it’s OpenClaw, Hermes, running a local LLM, ComfyUI, or Claude Design, curiosity is key here.

The interesting part of Lavertue’s example is not that he made a dashboard. Dashboards are cheap. The useful part is that he used AI to make a leadership problem legible enough to discuss. His signals site pulled together team health and business impact, then sorted indicators into required, expected, and optional categories so the absence of a signal became something to interpret, not just a blank cell to punish.

Lavertue is clear about this:

I had to remind myself of that more than once while building it. The signals site was useful. Bob was a capable collaborator. But the risk with any tool that comes together quickly is mistaking the build for the point. The site was never the outcome. It was infrastructure for conversations. Design’s impact on the business was the outcome. Keeping that distinction clear required the same discipline I would ask of any designer getting excited about a new tool.

The site did not replace leadership judgment. It grounded it. Instead of reacting to delayed updates or anecdotal signals, I could engage teams with shared context and a clearer ability to look forward rather than back. This was another form of walking the walk. Not just encouraging teams to work differently but building the system that made that work visible and meaningful.

That feels like the better bar for AI-native leadership. Not “leaders should code now.” Not “every management problem needs a custom tool.” The bar is whether leaders are willing to put their own work through the same change they are asking from their teams.

Fulya Lisa Neubert, writing for the Slack Design blog, starts with a familiar design handoff problem:

For most of my design career, Figma was where the real work happened. I’d design screens, build prototypes, then hand off the designs for someone else to build. If something felt slightly wrong in production, we’d go back and forth trying to articulate what “it should feel like” in words. This process worked well enough, but there was always a gap between what I could show in a static design tool and what someone would actually experience in the product.

The piece gets concrete when Neubert moves from screens to Slack search. She points to a kind of interaction where static prototypes can suggest the flow, but can’t prove whether the experience works under someone’s hands:

The search experience in Slack is a deeply keyboard-driven feature: typing states, focus management, the way content scrolls and reflows as you interact. These are things you can sketch in Figma and even prototype to a degree, but a Figma prototype can’t tell you whether the focus ring moves correctly between elements when you press tab, or whether a scrolling gradient feels right as content overflows. You need to actually use it.

I don’t read this as an argument that designers need to become frontend engineers. Neubert came in with the basics and figured it out:

I came into this with basic HTML and CSS — enough to roughly understand what I was looking at, but not enough to write it myself. That turned out to matter less than I expected. The first time I described a focus interaction in plain language and had a prototype working in minutes, I stopped thinking of code as someone else’s territory. […]

My setup is fairly straightforward. Cursor is my main environment. I use Figma’s MCP integration to pull in components I’ve already designed and Slack’s design tokens, so I don’t have to rebuild spacing, color, and type from scratch every time. I tried working directly in Slack’s codebase — years of accumulated complexity that made every small change feel like a bigger undertaking than it needed to be. […]

The Figma integration matters because the prototype isn’t starting from a blank toy environment. It pulls real components and tokens into a lighter workspace, which makes the thing shareable without pretending to be production. For Slack search, that means the team can review behavior instead of debating screenshots.

Neubert is also clear about the tax:

AI also doesn’t always preserve what you’ve already built. You prompt it to change one thing, and it quietly breaks something else. If you’re not testing after every turn, you won’t notice until you’re sharing the prototype with someone — or worse, presenting it — and that’s when you realize something’s broken.

That is the right caution. AI changes the distance between intent and working behavior, but it doesn’t remove verification. If anything, it makes the habit of testing after every small change part of the design process itself.

Felipe A. Carriço, a UX designer and AI product builder, turns accessibility guidance into context AI coding agents have to follow with A11Y.md:

A11Y.md is not a guideline. It is an accessibility validation protocol and a persistent context architecture for developing accessible software with AI. It is designed to integrate with AI agent systems and human review workflows to ensure certifiable compliance.

By adopting the mental model of Anthropic’s CLAUDE.md—which acts as a system prompt memory for code generation—A11Y.md translates this architecture into a universal, portable governance layer. Instead of generic coding rules, it forces any coding agent (Claude, Cursor, Copilot) to strictly adhere to WCAG 2.2 AA and ADA standards from the very first line of generated UI code.

I appreciate how operational this is. It pairs well with Joost de Valk’s Website Specification, which treats machine-readable standards as part of what a good site does. A11Y.md brings the same idea into the build process: the generator has to carry the accessibility context while it makes the UI. That matters because accessibility failures in generated code are rarely abstract. They show up as broken keyboard paths, silent error states, and interface logic that only works for the person who can see and click everything.

Carriço is blunt about the difference between reading and changing the workflow:

Reading about accessibility is the first step, injecting it into your code is the real goal. Do this right now in your project:

1. Download the Rules: Copy the A11Y.md file from docs/en/ to the root of your application’s repository.
2. Inject into the Prompt: If you use Cursor, GitHub Copilot, or Claude, add this to your global rules file (.cursorrules or Context system):

“Strictly follow the development rules defined in the A11Y.md file.”

3. Use as a Quality Gate: Before merging important PRs, use the checklist in docs/en/templates/REPORT.md.

If you do not perform the steps above, you are not changing your workflow — you are just reading about the subject.

That is the product here: wiring accessibility into the build process so it changes what gets generated.

Joost de Valk, creator of the Yoast SEO plugin for WordPress, has turned the “what should a good website do?” question into The Website Specification: a platform-agnostic checklist that puts HTML basics, SEO, accessibility, security, performance, privacy, internationalization, and agent readiness in one place.

The useful shift is that the AI-facing work is treated as normal website hygiene. Not a separate “AI strategy” project. Not a prompt-engineering side quest. Just another part of making the site understandable to the systems that now read, rank, quote, and retrieve it.

A platform-agnostic specification of the technical features every decent website should have — from <title> to /.well-known/security.txt, from WCAG contrast to llms.txt. Written for humans and agents.

Ten areas, mapped to widely-accepted standards.

Each topic links back to the source standard — WHATWG, W3C, IETF RFCs, WCAG, MDN, and the organisations defining the modern web.

Whether you ship WordPress, Drupal, TYPO3, Next.js, Astro, Hugo, a Django app, or plain HTML, the spec is the spec. Implementation hints follow it, not the other way round.

I like that standards-first posture. A lot of AI advice still treats the web like a pile of pages to be scraped, summarized, and maybe attributed later. De Valk pulls it back toward contracts: stable URLs, explicit policies, structured data, clean source material, and machine-readable ways to discover what matters.

From the Agent Readiness section:

Agent readiness is a loose umbrella term for the choices that make a website legible to AI agents — chat assistants, autonomous browsers, retrieval pipelines, and any other non-human client that reads the web at scale. None of it is a single formal standard. It is a collection of existing web fundamentals plus a few emerging conventions.

Agents read the same HTML as browsers, but they read it differently. They:

• Fetch a page, often without executing JavaScript.
• Strip away navigation, ads, and chrome to extract the main content.
• Follow links, structured data, and well-known endpoints to discover more.
• Cache and quote your content in answers, with or without a link back.

If your content is locked behind client-side rendering, your URLs change every release, or your robots.txt blocks the assistants your customers use, you are invisible in that surface. The pages that win in agent answers are the ones that are easy to fetch, easy to parse, and easy to trust.

That’s the part designers should pay attention to. We tend to think of the interface as the thing on the screen. But if agents are part of the audience now, the interface also includes off-screen surfaces: metadata that explains the page, feeds and sitemaps that expose what exists, crawler policies that say what can be read, and curated indexes like llms.txt that tell software what matters.

De Valk again:

There is no single switch. The items in this category each cover one part:

• Stable URLs so cached answers stay valid.
• Structured data (JSON-LD) so agents can extract entities without guessing.
• Clean semantic HTML so content extraction does not pull in navigation.
• A robots.txt that names AI crawlers explicitly so your policy is unambiguous.
• /llms.txt as a curated index of your most important content (emerging).
• Machine-readable endpoints — sitemaps, RSS, JSON feeds — where they fit.
• MCP server endpoints for sites that expose tools or actions (emerging).

Most of these also benefit traditional search engines and accessibility. Agent readiness rarely conflicts with the rest of the spec; it just raises the priority of things that have always been good practice.

De Valk’s point is simpler: agent readiness mostly means doing the old web discipline well enough that agents can actually read and trust the site.

Dan Carey leads product at Anthropic Labs, the team behind Claude Code and Claude Design. In a talk on how a three-person team shipped Claude Design in ten weeks, he describes what happened to everyone else after their engineers got fast:

And so once Claude Code took off, the bottleneck moved. The bottleneck moved from building the feature to figuring out the right things to be building for your users, in a lot of cases. So the option was either skip those early steps, just try and decide on the fly, and potentially build the wrong thing really fast, or try to find ways for the rest of us to speed up. So our designers, our PMs, were having trouble keeping up. We needed our own accelerator tool.

Carey just relocated the bottleneck onto the exact work designers and PMs own: figuring out what’s worth building. That’s product discovery becoming the real constraint. When building gets cheap, what’s left to get right is the decision about what to build at all.

How does the team make that call? Not by writing it down:

So we like to use prototypes because documents are imprecise. It’s so easy for two people to look at the same doc and have two different products in mind about what the experience should be. […] Prototypes are more concrete, more visceral. They let you get hands on with the thing and really feel the experience yourself.

They skipped the PRD and the vision docs entirely. A working prototype immediately aligns people, and it doubles as the discovery tool: you build the rough thing to find out what the right thing is.

And it helped that the team was small enough to skip coordination entirely. Here’s Carey:

Everyone on the team does everything. The engineers talk to users, PMs write code, designers do data analysis. All of these things are enabled in part with Claude. And the lines between the roles on this team, they have essentially dissolved at this point. You do have your specialization, you do have the unique perspective and diversity that you bring to a team, but at any moment, any one of these people on this team can talk to 10 users, you can realize what the underlying problem is, you can design a solution to it, you can ship it to users, you can listen for feedback, you can keep iterating solo if you need to.

On Carey’s team, the designer who spots the problem also builds the solution and ships it. That’s the kind of role a lot of designers are now being asked to grow into, and it looks less like a handoff between specialists than one person carrying an idea from problem to finished screen.

Speed doesn’t guarantee you build the right thing, though, and Carey is candid about the team’s misses. They built a set of advanced, fine-grained controls for power users. A few vocal testers loved them—I know I would have. But the usage showed everyone else hated them, and the team pulled the controls in a week. Two lessons came out of it:

So this taught us a couple of things. One, this taught us that we should be a tool that lifts the level of craft for everybody, not just the ceiling on power users. It also taught us that we want to be as open as possible, because there will be users that we never meet the full needs of. There’s going to be some power user out there who wants to do something very specific that we’re not going to support. And that’s what convinced us that we wanted this to be a very open tool. That’s why if you export from it, you get HTML, CSS, JavaScript.

Deva Corriveau, Creative Director at Brandpie, writing for The Subtext, asks what happens when the customer doesn’t choose at all.

Take something mundane, like ordering a takeaway. Consumers don’t feel a deep emotional connection to whether dinner arrives via Just Eat, Deliveroo or Uber Eats. They may have habits or interface preferences, but they don’t meaningfully care about the logo on the rider’s jacket or the tone of voice in their advertising. Yet these businesses still spend tens of millions each year trying to build precisely that sense of distinction.

Now imagine a step beyond this. Instead of opening an app at all, the consumer simply instructs an AI assistant to order a pizza. The system scans available providers, evaluates delivery times, compares pricing, reviews reliability data, and executes the transaction. The entire process takes place behind a seamless, invisible layer of automation. The user does not browse. They do not compare. They are not exposed to campaigns or nudged by distinctive brand assets. The decision is simply optimized.

From a consumer perspective, this is seamless and efficient. From a brand perspective, it’s an unsettling shift in how choice is made and where influence sits.

That distinction matters. In a browser or an app, brand can still interrupt the customer at the point of comparison. Inside an agent, the brand has to show up as criteria the agent can evaluate.

Corriveau on the shift:

For decades, we’ve treated awareness as the foundation of growth. Be famous. Be distinctive. Be top of mind. When the moment of choice arrives, ensure your brand is mentally available. That logic remains sound – but only if a human is making the decision.

An AI agent does not remember your jingle or favour your colour palette. It does not feel reassured by your heritage or inspired by your purpose. It simply calculates against a defined set of criteria.

This does not mean brand disappears, but its role shifts. Marketeers must move upstream from the moment of choice to defining the parameters of the choice itself.

If the agent is comparing delivery time, service ratings, return policies, privacy history, and price, then the promises a brand makes need to map to service behaviors, policies, and performance an agent can actually evaluate. A promise the company can’t prove becomes decoration.

I don’t read this as “branding is dead.” Corriveau is saying something narrower: people still define preferences; automation changes when and how those preferences get expressed.

Discussions about automation often miss a critical point: humans still define the criteria. A user may delegate comparison and selection to an AI, but they still decide what it optimises for. They might instruct it to prioritize companies with high customer service ratings, favour businesses with strong sustainability credentials, or exclude brands that have suffered data breaches. Human values, identity, and worldview remain central – they are simply expressed differently.

Trust, identity signalling, ethical alignment: these human drivers do not disappear just because a machine intermediates the transaction. In fact, they may become more explicit. Rather than being subconsciously influenced by advertising, consumers will consciously encode their preferences into the system.

In that world, the role of brand becomes less about capturing attention in the moment and more about establishing a presence so clear and widely understood that people choose to embed it into their decision rules. The brands that endure will be those that stand for something concrete enough to be deliberately included in the instructions given to machines.

That keeps Corriveau’s argument from becoming a pure optimization story. He isn’t replacing human values with machine logic; he is moving the expression of those values upstream. The shelf moment gets quieter because the proxy has already filtered the options. Brand becomes less about a burst of attention and more about operational consistency the customer can delegate with confidence.

For designers and brand teams, the practical consequence is simple: brand claims need proof a system can read and compare. The work doesn’t stop at making a company memorable; it has to make the company’s promises observable, consistent, and legible before a human sees the options. The artifact isn’t only the campaign anymore; it’s the evidence trail behind the campaign.

The biggest risk sits in the middle. The brands whose differentiation relies primarily on communication rather than capability. Agentic AI will expose decorative branding with uncomfortable clarity. If your distinctiveness lives in marketing but not in service, performance or trust, optimisation will reduce your value to price alone.

For branding professionals, this is not a minor adjustment; it is a structural reframing. The future will rely less on megaphones and more on architecture. We must move away from simply generating awareness toward establishing qualities so credible and so consistent that they influence how customers configure their digital proxies. The question is no longer just how to be noticed, but how to be retrievable, recommendable, and selectable inside AI-driven systems.

This is where Generative Engine Optimization (GEO) begins to matter. Brands will need to think less in terms of impressions and more in terms of machine-readable signals of trust, performance, and relevance – the inputs that shape whether an AI system even considers them in a ranked set of options. Practically, this means building brand equity in ways that can be consistently interpreted by both humans and machines: structured proof of service quality, transparent value signals, strong third-party validation, and behavioural consistency over time.