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

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

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

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

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

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

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

Pitre turns that into a test:

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

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

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

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

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

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

May again:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Trueman gets more specific about what Figma gave her:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Yes, I need to get out more.

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

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

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

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

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

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

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

Wood on the no-joke version:

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

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

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

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

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

Wood on the brief:

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

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

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

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

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

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

NJ Singh built something similar:

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

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

Designers are used to thinking with their hands.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Dean again:

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

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

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

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

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

Dean on the method:

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

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

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

In designer and investor Soleio’s South Park Commons interview, Rasmus Andersson, creator of Inter and an early Figma designer, draws a useful distinction between software and type. Regular software decays fast; Andersson says that if he hasn’t touched something in two weeks, he usually trashes it and starts over. But a typeface can keep gaining value years later.

Andersson starts with how complex modern software is:

Today there’s just this towering complexity of making software, and for a very good reason, right? For like 15, maybe 20 years by now, our industry as a whole has been hyper-focused on scale because it’s just been an economic evolution that’s been out of this world. So it makes sense that we’ve been trading off and trading away things like shareware, concepts like that, and things like simplicity and ease for the ability to scale and for the ability to things at scale to actually work and break apart. But in the wake of all of that, which is great in so many ways, we’ve given up these things that are listed, and I feel like at least me and many people like me and who sort of are trained to build this thing, enjoy making software at a smaller scale.

That’s like a metaphor that I think can be helpful is imagine your room, apartment, house, whatever, your dwelling place. It’s probably different from the person next to you. And it’s not so that we go out and we buy the Apple apartment and all the furniture is there and everything is perfect and we can change the carpet, and that’s about it. That’s ridiculous, no one would do that. Yet that’s what people do with software.

Manufacturing software was professionalized and gentrified. The stack got so optimized for global products that it left less room for the small, personal, weird things people used to make for themselves.

Andersson’s Figma story keeps that from becoming nostalgia:

First off, something that was just amazing about working at Figma at the time was that there was just this culture of doing things differently. That was amazing. And every single individual who I worked with were just like, if that person went to start a company now and they put me with it, I’ll come. Every person was like that. Every person had an opinion about something that was really exciting.

Another thing that I think was so fascinating about how things were done at the time at Figma was this deep intention around everything and moving slow. But moving slow with many things in parallel, like staggered, right? So from the outside, Figma would ship something every month, maybe even more often than that. But internally, a person would work on one thing for one year. And sometimes at the end of that one year, it would just go into the bin and never ship. So that I think was really cool to see from the inside and then having a very different effect on the outside.

That distinction matters in an AI tooling moment where output is getting cheap. Figma looked fast from the outside because slow, deliberate work was happening underneath. Speed at the surface depends on judgment below it.

On Inter:

One thing for sure is finding the right ratio between impact and effort. I think Inter is one of those things. Sure, I’ve spent like 10 years on it, and who knows how much of my time on it, right? So there’s a lot of effort behind it. But I think it’s one of those types of efforts that has a very disproportionate impact from the effort.

[…]

I gotta say though, something that is amazing about working at Typeface is, it’s something like, it’s almost like in the field of design, you might think about cars as a unique type of thing to design because it’s both like, and architecture’s a little bit like that too. It’s not strictly the sign as in signage for roads, right? It’s very technical and it’s not the sign as in expressing myself through art, like graphic design, like a poster, it’s somewhere magically in between.

And another aspect of it that’s kind of cool is that you can put in 10 minutes here and 10 hours there and they add up over time which I don’t think is true without a software because the rate of decay of any type of regular software is very high. Two weeks is my cutoff. If I have not worked on something for two weeks I have trashed it and start over but with a typeface like that decay is extremely extremely low, in some cases zero.

The useful thing about this AI layoffs simulator is that it turns an abstract workforce problem into something you can see: if every company cuts workers to save money, fewer people have money to spend.

Raj Nandan Sharma built the interactive page from “The AI Layoff Trap,” an arXiv paper about what happens when many companies automate at the same time. Sharma summarizes the mechanism this way:

Rational, forward-looking firms competing on cost are trapped in an automation arms race. Each captures the full savings of replacing a worker — but bears only 1/N of the resulting collapse in demand. The rest falls on rivals. The race is a dominant strategy. This simulator makes the trap visible as parameters change.

In the default model, each company keeps cutting until about 65% of workers are replaced. The healthier stopping point for the whole market is closer to 35%. That thirty-point gap is the trap.

The default setup is simple: each company has 100 employees, workers earn $50k, only 30% of lost income is replaced, and workers spend half their income at the same local companies. The key moment is when the chart crosses from “this is good for my company” to “this is bad for everyone”:

Past the sweet spot. At 31% automation, profits hit their peak. But every company is still cutting — because each firm saves the full wage bill privately, while only 1/1,000 of the lost demand lands on its own books. Profits are now falling, but still above the starting line.

The policy section gets denser, but the plain-English point is this: helping workers afterward matters, but it does not change why each company keeps cutting. The simulator argues that the cost of the decision has to change too:

Foresight alone cannot prevent the race toward the cliff.

I’ve been broadly bullish about AI, and regular readers here know that. The tools are useful already, and designers who learn to direct them will have a real advantage.

That is why I want to make room for Matthew Butterick’s more pessimistic argument. Butterick is a typographer, writer, programmer, and lawyer who has been directly involved in legal challenges to generative-AI training practices. His argument belongs in the AI conversation precisely because it does not require a rogue model or a Skynet story:

Among AI risks, we should take more seri­ously the poten­tial conse­quences of AI working as intended. AI is a capi­talist instru­ment. Its prin­cipal func­tion is to concen­trate capital. Its intended mech­a­nism is large-scale labor replace­ment. But it is also inher­ently polit­ical tech­nology. As AI makes it harder for workers to capture value from their labor, they will increas­ingly have to rely on goodies from Big AI, priva­tizing what were once func­tions of govern­ment. If Big AI subsumes the func­tions of workers and govern­ment, both will tend to realign polit­i­cally around Big AI’s inter­ests. What­ever term describes this system, it is not liberal democ­racy as US citi­zens have tradi­tion­ally under­stood it. AI-centered capi­talism risks an extinc­tion of demo­c­ratic possi­bility. It will be America. But it will no longer be Amer­ican.

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.