I’ve been playing around with Pencil along with Paper, both newer agentic design tools. The multi-agent demo is genuinely impressive—six AI agents designing an app simultaneously, each with its own cursor, name, and chat on the canvas.

Tom Krcha, Pencil’s CEO, speaking on Peter Yang’s channel, on the format bet at the center of the product:

It’s generating basically a descriptor for the design. And then what you can do, you can essentially ask it what kind of code you want to convert it into. Because we wanted to make sure that it’s sort of platform agnostic. […] So we have this platform agnostic file format. We call it .pen. It’s essentially just JSON-based format. We wanted to really build this format to be agentic from the ground up.

Krcha frames it as “agentic PDF.” I could get behind platform agnosticism as a philosophy, but I need more convincing. The .pen format is still a translation layer between the design and the code. That means migration from Figma, especially for teams with established design systems. And I’m skeptical that a button in Pencil’s built-in design system will correctly map to the right reusable code component when the agent translates .pen to production code. I need to test it out more for myself.

We have enterprises using that for this specific purpose, to convert their design systems into pen format and make sure that it lives in the Git. This is the source of truth for everybody now.

“Source of truth” is doing heavy lifting in that sentence. For teams with mature design systems, the source of truth is the code component, not a JSON representation of it.

This is a pretty impressive demo nonetheless, and it’s a moment of delight to give agents a name and a “face” if you will. Krcha:

Those cursors, it seems like a small touch, but it’s the first time I have seen AI humanized. It feels like there’s someone there. It’s crazy, it’s just a cursor.

Designers aren’t leaving Figma. They’re outgrowing what Figma was built to do.

Punit Chawla, writing for Bootcamp:

Designers are slowly shifting to a building first mindset. Which means that a good chunk of UI designers are moving quickly to AI coding platforms to bring their ideas to life. The “Vibe Coding” trend wasn’t just another tech bubble, but a wake up call for designers to create life like prototypes and MVPs from day zero. In fact, PMs and designers at Meta have publicly stated how they are showing working products instead of UI prototypes.

The shift is real, but “leaving” is the wrong word. Designers aren’t abandoning Figma. They’re adding tools that do things Figma was never designed to do. Figma’s role is narrowing from everything-tool to exploration-and-iteration tool. That’s not the same as dying.

Chawla’s strongest point is structural:

Some companies are built different with a completely separate infrastructure. For Figma to change their infrastructure from the bottom-up will be very difficult. Let’s not forget they are a publicly traded company. Risking major changes can mean risking billions in stakeholder investments. Companies like Cursor on the other hand are built to be building first/coding first products, hence a major advantage.

This is right. Figma’s architecture was purpose-built for collaborative vector editing, not code generation. Bolting on AI code output is a fundamentally different engineering problem. When Figma Make launched, I scored it at 58 out of 100, and it’s getting better, but it’s competing against tools that were born for this.

Where I’d push back is on the builder framing. Designers aren’t becoming coders. They’re becoming directors. A designer who orchestrates AI agents against a design system solves the handoff problem more fundamentally than one who vibe-codes an MVP. One eliminates the bottleneck. The other just moves which side of it you’re standing on.

Chawla hedges his own headline:

Don’t get me wrong, Figma is still the best tool for a majority of creatives and has a strong hold on our day-to-day workflow. Making any strong predictions at this point will be very ill-informed and it’s best to avoid making any conclusions as of now.

Fair enough. But the question worth tracking is whether Figma can expand fast enough to remain relevant as the deliverable shifts from mockups to working software.

Prototypes have always been alignment tools. Whether you’re testing with users or convincing leadership, the prototype’s job is to make the abstract concrete. That part isn’t new.

What’s worth noticing in Emma Webster’s case study roundup on the Figma blog is who’s doing the prototyping. Three stories. Three product managers. Zero designer protagonists.

ServiceNow’s Ram Devanathan explains the dynamic:

“They have a big portfolio, so they can’t always pivot directly to my project.”

So Ram built it himself in Make. His designer’s mockup missed the nuance he was after, so he took a crack at it:

“Make helped me show what I meant rather than trying to describe it in the abstract. I’m able to explain my ideas better. I’m able to convince people faster. That reduces the whole cycle for me.”

Ticketmaster PM Brian Muehlenkamp prototyped an AI assistant that wasn’t even on the roadmap and shipped it. Affirm’s SVP of Product Vishal Kapoor puts the value in craft terms:

“The real work lives in the variations, rabbit holes, and edge cases. It requires a lot of thinking, a lot of precision, and a lot of love.”

All three stories follow the same arc: PM has an idea, designer is unavailable or the mockup misses the mark, PM builds it in Make, team aligns faster. Designers aren’t the heroes of these stories. They’re the bottleneck the tool routes around.

I don’t think that’s Figma’s intended message. But it’s the one that came through to me.

Designers are builders by nature. We break problems apart, iterate through uncertainty, and treat process itself as something to be shaped. That instinct is exactly what Pete Pachal, writing for Fast Company, identifies as the dividing line in the age of agents:

We’ve trained a generation of office workers to work within software with clear boundaries and reusable templates. If there’s an issue, they call IT. Any feature request gets filtered and, if you’re lucky, put on a roadmap that pushes it out 6-12 months.

In short, most people don’t have a builder mentality to begin with, and expecting them to suddenly be comfortable working and creating with agents is unrealistic.

Pachal draws the line at mindset, not coding ability:

Builders don’t need to be coders, but they do have characteristics that most workers don’t: They seek to understand the process beneath their tasks, and treat that process as modifiable and programmable. More importantly, they see failure and iteration as tolerable, even fun. They thrive in uncertainty.

That’s the design process. What Pachal frames as rare in the broader workforce is default operating mode for most designers. We want to make things. We fiddle with tools and rebuild workflows for fun. The builder mentality isn’t something designers need to acquire; it’s the reason most of us got into this field.

Pachal again:

You don’t have to build agents to matter in an agent-driven workplace. But you do have to understand the systems being built around you, because soon enough, your job will be defined by defaults someone else designed. Most professionals will not build agents. But everyone will work inside systems builders create.

Pachal is describing the orchestrator gap at scale, not just in design but across all knowledge work. And it suggests designers are uniquely positioned to be on the right side of it. Shaping how people interact with systems has always been the job description.

Every design system is an exercise in compression. You take contextual reasoning—why this spacing, why this type scale—and flatten it into tokens and components that can ship without the backstory.

Mark Anthony Cianfrani:

the reason that your line height is set to 1.1 is because your application is, or was at one point, very data-intensive and thus you needed to optimize for information density. Because one time someone complained about not being able to see a very important row in a table and that mistake cost so much money that you were hired to redesign the whole system. But that’s a mouthful. You can’t throw that over the wall. An engineer can’t implement that. So we make little boxes with all batteries included.

All of that reasoning gets flattened into line-height: 1.1. The token ships. The reasoning doesn’t. Every design system makes this trade-off: you lose the why to gain portability.

Cianfrani argues we don’t have to accept that trade-off anymore:

LLMs give us the ability to ship our exact train of thought, uncompressed, a little bit lossy but still significantly useful. Full context that is instantly digestable. Instead of shipping <Boxes>, ship a factory.

Design systems were never the end goal. They were the best compression format we had. Components and tokens became the shipping containers because the full reasoning was too unwieldy to hand off. That constraint is loosening. In spec-driven development, that factory looks like a structured document: design intent expressed in plain language that AI agents build against directly. The spec is the reasoning, uncompressed.

Even if the AI bet doesn’t pay off:

And if this whole AI thing turns out to burst, at least you’ve improved the one skill that some of the best designers I’ve ever worked with had in common—the ability to communicate their design decisions into words.

The compression problem was always worth solving, with or without LLMs.

The transparency question in autonomous interfaces—what to surface, what to simplify, what to explain—needs a concrete framework. Daniel Ruston offers one.

Ruston names the next layer: the Orchestrated User Interface, where the user states intent and the system generates the right interface and executes across multiple agents. The label is less interesting than what it demands from designers:

We can no longer design rigid for “Happy Paths.” We must design for Probabilistic UX. The designer’s job is no longer drawing the buttons; the designer’s job is defining the thresholds for when the button “presses itself” or when the system needs user to clarify, correct or control.

Ruston makes this concrete with a confidence-threshold pattern:

Low Confidence (<60%): The system asks the user for clarification or provides a vague response requiring follow-up (“Which Jane do you want me to schedule with?”). Medium Confidence (60–90%): The system makes a tentative suggestion (“Shall I draft a reply based on your last meeting?”). High Confidence (>90%): The system acts and informs (“I’ve blocked this time on your calendar to prevent conflicts”).

That’s the design lever most AI products skip. They either act without explaining or ask permission for everything. The threshold gives designers something to actually spec: not “should the system do this?” but “how sure does it need to be before it does this without asking?”

Ruston borrows a metaphor from aviation to describe what this visibility should look like:

Analogue cockpits require pilots to look at individual gauges and mentally build a picture of the aircraft’s “system” state. The glass cockpit philosophy shifts the focus to a human-centered design that processes and integrates this data into an intuitive, graphical “picture” of flight.

Same problem, different domain. Most AI products today are analogue cockpits: individual agent outputs, raw status messages, no integrated picture. The confidence thresholds tell the system when to act. The glass cockpit tells the user what’s happening while it acts.

The shift from mockups to code is one thing. The shift from designing tools to designing autonomous behavior is another. Sergio Ortega proposes expanding Human-Computer Interaction into Human-Machine Interaction. The label is less interesting than what it points at.

The part that matters for working designers is the transparency problem:

This is where design must decide what to show, what to simplify, and what to explain. Absolute transparency is unfeasible, total opacity should be unacceptable. In short, designing for autonomous systems means finding a balance between technological complexity and human trust.

When a system makes decisions the user didn’t ask for, someone has to decide what gets surfaced. Ortega:

The focus does not abandon user experience, but expands toward system behavior and its influence on human and organizational decisions. Design is no longer only about defining how technology is used, but about establishing the limits of its behavior.

And the implication for design teams:

When the machine acts, design becomes a mechanism of continuous balance.

The pitch for generative UI is simple: stop making users navigate menus and let them say what they want. Every AI product demo shows the same thing: type a prompt, get a result, skip the 47-click workflow. It looks like progress.

Jakob Nielsen names what gets lost in the trade:

However, eliminating the Navigation Tax imposes a new Articulation Tax. In a menu-driven GUI, features are visible and therefore discoverable; a user can find a tool they didn’t know existed simply by browsing. In an intent-based AI interface, the user can only access what they can clearly describe.

“Articulation Tax” is the right frame. Menus are clunky, but they show you what’s possible. A blank prompt field assumes you already know what to ask for. That’s fine for power users. It’s a problem for everyone else. Nielsen:

The shift from WIMP to World Models represents a transition from Deterministic to Probabilistic interaction. In a WIMP interface, clicking an icon is deterministic: it produces the exact same result 100% of the time. In a generative world model, the system is probabilistic: the same prompt may yield different results on different attempts.

Deterministic to probabilistic is a trust problem. Users learned to trust GUIs because the same action always produced the same result. That contract is gone. Users will adjust eventually, but most aren’t there yet.

The design industry spent a decade burying skeuomorphism. Flat won. And now that AI can generate any flat interface in seconds, physicality is interesting again.

Daniel Rodrigues and Lucas Fischer, writing for Every, describe designing the iOS app for Monologue, a smart dictation tool. Rodrigues studied Braun radios and Teenage Engineering synthesizers, and at one point found himself crouched beside his apartment light switch watching how the shadow moved. His defense of skeuomorphism:

Skeuomorphism has been accused of being overdone, and fairly so, but I think of it as borrowing the credibility that physical things naturally have, like weight, shadow, and texture. Something similar to the way a real button communicates—without explicit explanation—that it can be pressed.

This isn’t a texture pack in Photoshop. Rodrigues studied how light behaves on a physical button and rebuilt that behavior in SwiftUI. The texture is functional, not decorative: it tells you the thing is pressable. Rodrigues and Fischer:

Not every AI product needs skeuomorphic buttons and custom sound effects, but the bar for what “functional” means is shifting. AI is making it faster and cheaper to build “functional” products, so the ones that endure are those where someone thought about what it feels like to use them. For us, that meant studying physical objects, exploring 20 wrong directions to find one right one, and hiring a musician to build sounds we could have pulled from a stock library.

Set some type in Illustrator. Print it out on a laser printer. Crumple the paper, really manhandle it. Rub it on the sidewalk. Scratch it with the back of an X-acto blade. Now scan it back in. That was the real analogue way I distressed type back in the 1990s.

That analogue look is trendy again. Hand-rendered type, ink textures, visible grain. All in search of “authenticity.”

Elizabeth Goodspeed, writing for It’s Nice That, has a name for what’s actually happening:

But if analogue only matters as a foil to the digital, why are analogue aesthetics being embraced without analogue tools? If the goal is to prove something wasn’t made by AI, faking “realness” on a computer doesn’t really get us anywhere new. It just reflects a different kind of dissonance (call it fauxbi-sabi). Case in point: I noticed that one vendor selling “analogue” Photoshop actions advertises them with the tagline “Save time, focus on being creative”, a promise suspiciously similar to every argument made in favour of AI.

“Fauxbi-sabi” is the whole scam in one word. AI and digital tools made polish free, so imperfection became the new signal for authenticity. But most of the “handmade” work in those trend reports was made in Photoshop with purchased texture packs. Goodspeed again:

You can think of adding in fake ink splatters a bit like penciling in a beauty mark: an intentional imperfection done to signal authenticity, rather than the byproduct of a real nuisance.

The whole essay is sharp, especially the historical parallels. When Kodak made photography easy in 1888, art photographers retreated to difficult, slow processes to prove human involvement. We’re running the same play 138 years later with different tools. The piece is worth reading in full.

I’ve rebuilt my personal website more times than I can count. The tools and platforms change; the principle doesn’t: I own my content, and nobody gets to take it away. I have a Substack, but it’s a digest, a syndication channel. The canonical content lives on my site, on my domain. My website can’t be enshittified by anyone but me.

Henry Desroches makes the case through Ivan Illich’s Tools for Conviviality:

In his book Tools For Conviviality, technology philosopher and social critic Ivan Illich identifies these two critical moments, the optimistic arrival & the deadening industrialization, as watersheds of technological advent. Tools are first created to enhance our capacities to spend our energy more freely and in turn spend our days more freely, but as their industrialization increases, their manipulation & usurpation of society increases in tow.

Illich also describes the concept of radical monopoly, which is that point where a technological tool is so dominant that people are excluded from society unless they become its users. We saw this with the automobile, we saw it with the internet, and we even see it with social media.

That’s social media in one paragraph. You don’t join Instagram because you want to; you join because opting out means opting out of the conversation. Desroches argues personal websites are the answer:

Hand-coded, syndicated, and above all personal websites are exemplary: They let users of the internet to be autonomous, experiment, have ownership, learn, share, find god, find love, find purpose. Bespoke, endlessly tweaked, eternally redesigned, built-in-public, surprising UI and delightful UX. The personal website is a staunch undying answer to everything the corporate and industrial web has taken from us.

The practical argument is strong enough on its own. Own your content. Own your platform. Syndicate outward. The moment you frame it as reclaiming the soul of the internet, you lose the people who most need to hear the boring version: just put your stuff on a domain you control.

The design process isn’t dead. It’s changing. My belief is that the high-level steps are exactly the same, but where designers spend their time is being redistributed.

Jenny Wen, head of design for Claude at Anthropic (formerly at Figma), on Lenny’s Podcast:

This design process that designers have been taught, we sort of treat it as gospel. That’s basically dead. I think it was sort of dying before the age of AI, but given now that engineers can go off and spin off their seven Claudes, I think as designers, we really have to let go of that process.

It’s a strong headline. But Wen then describes her actual day-to-day, and it sounds familiar:

We are still prototyping stuff. I’m still mocking stuff up. I think it’s just I have a wider set of tools now, and I think the proportion of time I spend doing each thing just has changed.

So the process isn’t dead. The proportions shifted. Wen breaks it down:

A few years ago, 60 to 70% of it was mocking and prototyping, but now I feel the mocking up part of it is 30 to 40%. And then there’s that other 30 to 40% there that is now jamming and pairing directly with engineers. And then there’s a slice of it that is now implementation as well.

What’s missing from that breakdown is user research and discovery. Wen mentions having a researcher on the team, mentions reading studies and feedback, but those activities don’t factor into the breakdown at all. For a team building products where, by Wen’s own admission, “you can’t mock up all the states” and “you actually discover use cases as you see people using them,” you’d think research would be eating a larger share of the pie, not disappearing from the conversation entirely. In my day-to-day, the designers on my team spend 30–40% on discovery and flows. Maybe 40–50% on mockups and prototypes. We’re basically already at her breakdown.

There’s also a context problem. Wen’s “ship fast, iterate publicly, build trust through speed” approach makes sense for Anthropic. They’re building greenfield AI products where nobody knows the right interaction patterns yet. The models are non-deterministic. Labeling something a “research preview” and iterating in public is the right call when the design space is that undefined.

That approach gets harder with a product that has an established install base. When you’re updating features that millions of people depend on, “ship it and iterate” has real costs. Sonos learned this. Or if your product is mission-critical as Figma learned when it shipped its UI3 and designers revolted. Or worse, an essential service like a CRM or operational software. The slow, unglamorous work of discovery and user testing exists because breaking what already works is expensive. Wen has the advantage of building greenfield — there’s no install base to protect. Not every team has that luxury.

The interview gets more interesting when Wen turns to hiring. She describes three archetypes: the “block-shaped” strong generalist who’s 80th percentile across multiple skills, the deep T-shaped specialist who’s in the top 10% of their area, and then a third she says the industry is overlooking:

My last one is probably the one that I think we’re all overlooking, which is what I call the crack new grad. It’s just somebody who’s early career and feels, like, wise and experienced beyond their years, but is also just very humble and very eager to learn. I think this person is really interesting right now because I think most companies are just hiring senior talent, folks that have done things before, are super experienced, but given how much the roles are changing and what we’re expected to do is changing, I think having somebody who almost has a blank slate, and is just a really quick learner and is really eager to learn new tactics and stuff like that, and doesn’t have all these baked in processes and rituals in their mind, that’s super valuable.

Wen’s “crack new grad” maps closely to the strategies I wrote for entry-level designers: build things, get comfortable with AI tools, be what Josh Silverman calls the “dangerous generalist.” Someone without baked-in rituals who learns fast and ships. That a design leader at a frontier lab is actively looking for this profile matters, because most of the industry is still filtering for ten years of experience.

The behavioral gap, the calcified companies, the startups shipping while incumbents argue about roadmap slides: there’s an economic force underneath all of it. Andy Coenen names it. He picks up from Matt Shumer’s “Something Big Is Happening“ and builds the case that we’re living through a Software Industrial Revolution, where the cost of producing software collapses the way textiles did in the 18th century.

His thesis on what survives the cost collapse:

Because while the act of building software will fundamentally change, software engineering has never really been about producing code. It’s about understanding and modeling domains, managing complexity (especially over time), and the dynamic interplay between software and the real world as the system evolves. And while the ability to produce code by hand is rapidly becoming irrelevant, the core skills of software engineering will only become more important as we radically scale up the amount of software in the world.

Replace “software engineering” with “product design” and “producing code” with “producing mockups” and you have the argument I made in Product Design Is Changing. The artifact was never the job. The judgment was.

Coenen again, on what abundance looks like in practice:

My friend, Dr. Steve Blum, is a brilliant cancer researcher. Steve’s work deals with massive amounts of data, and analyzing that data is a major bottleneck. But writing software to do so is extremely difficult, and there’s no world where Steve’s limited attention ought to be spent on python venv management.

The Software Industrial Revolution means that Dr. Blum and thousands of his colleagues have all, suddenly, almost magically, been given massive new leverage via the ability to conjure up almost any tool imaginable, on demand. This is like giving every cancer researcher in the world a team of world-class software engineers on staff overnight, for less than the price of Netflix. Frankly, I think this is nothing short of miraculous.

Now do that thought experiment for design. Every small business owner who needs a custom tool, every nonprofit that can’t afford a design team. The Industrial Revolution didn’t just make cloth cheap. It made good cloth cheap. That’s the part designers should be paying attention to.

Darragh Curran’s 2× goal reads like a halftime speech. We can do this. The tools are here. The gap is behavioral. Double your output in twelve months.

Claire Vo wrote the post-game report:

If AI adoption had 7 stages of grief, almost all of you would be in denial. No matter how many AI memos your CEO sends, the amount of Claude that’s being Coded, the chatbots in app and the evals in data—I’m here to tell you: you’re not competing. In fact, you probably can’t anymore.

Vo’s target is the company that thinks it’s adapting: AI features shipped, internal power users, a natural-language interface named after a gem. She’s not buying it:

While they try on the bows and ribbons of an AI-native team, they ignore the fact that their bones are old and the company has calcified. For the most part: sales still sells the same and marketing is still talking about channels and CAC and product says “prioritize” and eng says “capacity” and the board is endlessly asking either about Q1 perf and Q2 projections or the ever-elusive “increase in product velocity.”

“Bows and ribbons” versus “bones.” That’s the whole post in one sentence.

I have some sympathy for the incumbents, though. Vo’s startup-swagger framing undersells how much gravitational pull a $100M business carries. Enterprise contracts, compliance obligations, a customer base that didn’t sign up for a pivot. The companies she’s diagnosing aren’t stupid. They’re heavy. And heavy things don’t accelerate the same way light things do, even when both see the cliff.

None of that makes her wrong. It just means even the companies that want to change are fighting physics. But they’ll have to figure it out sooner than later.

Every few weeks another engineering leader publishes their AI productivity manifesto. Most read like press releases. Darragh Curran, Intercom’s CTO, argued it isn’t about the tools:

If we were to literally hit pause on further advancements, I’m convinced any engineering team just leveraging the already existing tools effectively should expect at least double their current productivity – a 2x improvement. Yet most people and teams in the industry at large are not getting close to this today, they aren’t trying, and they probably don’t believe it’s possible, and even if they do, behavior change is hard and the forces or incentives aren’t clear yet.

(By the way, he wrote this in mid-2025. Given how much better the latest models are, I’m sure the number is higher now.)

The tools are good enough. The gap is behavioral. Engineers got good AI tooling early and had clear on-ramps. For designers, the tooling is fragmented and many in the profession are still debating whether AI belongs in the process at all.

Curran makes the economic case:

It’s worth noting this is an entirely different vector to “just hire more people”. Even if we allocated the budget to hire 2x as many people, at our scale, it’s highly improbable we’d double our team size in 12 months. Even if we did, that’d come at huge cost and tradeoffs, hiring and onboarding takes time and carries risk, so we’d be slower for a year or two hoping to then catch up.

Figma’s State of the Designer 2026 is subtitled “Designers Are Leaning Into the Messy Middle.” I read “messy middle” less as emotional uncertainty and more as positional—designers occupy the space between product management and engineering, stretched in both directions. Their own Shifting Roles report backs this up: 64% of product builders now identify with two or more roles.

Madeline Stafford, writing for Figma:

And while designers crave the space for creative independence, they still benefit from clarity. Nearly all (91%) of designers say that clear goals and expectations help them do their best work. Structure is reassuring as AI changes the product design process. You’ve maybe seen this happening in real time: Armed with new tools, non-designers are increasingly able to participate in the design process. And while designers welcome collaboration—90% agree that it’s key to producing good work—these fluid boundaries can be scary.

“Fluid boundaries can be scary” is the key line. When everyone can prototype and has opinions about the UI, a designer’s value stops being about output and becomes about judgment.

Stafford again:

Designers want a seat at the table: They’re most content in their jobs when they have creative freedom, ranking it the number one contributor to overall satisfaction at work. Eighty-seven percent of designers say that decision-making power also boosts their performance, which many can connect directly to stronger business outcomes.

Designers want clear jurisdiction. When your role expands toward product strategy on one side and engineering on the other, knowing what you own matters. A Brazil-based designer in the survey:

AI tools make things much faster, but the precise designer’s vision is what makes the difference.

That “precise vision” is what separates a designer from a PM who happens to use Figma. The full report is worth a read.

Every profession, when it feels the ground shifting, reaches for whatever feels most solid. For designers, that’s been “craft” and “taste” (which I’ve used too in my writing). I get the instinct. When the tools you’ve mastered get commoditized, you want to assert that the real value was never in the tools. It was in you always: your eye, your sensibility.

But I’ve watched this play out for over a year now, and I think it’s less strategic positioning than grief response. Nicole Alexandra Michaelis makes the case that designers should be thriving, not panicking, and that much of the panic is self-inflicted. The whiplash:

Seniors are telling juniors to count themselves lucky if they’ll ever find a job. Design leaders are jumping from one AI-tool hypetrain to the next in mere weeks.

Monday, it’s all about prototypes. Thursday, it’s vibe coding. Friday, we’re preaching that output no longer matters (everyone can design now!) and that we should be brilliant strategists instead. By next Monday, we’ll be half-heartedly debating which soft skills are absolutely vital to survive.

Survive. As designers.

A profession trying on new identities in a dressing room. Nothing fits so we keep grabbing the next thing. “Craft” is the one people keep coming back to because it feels the most like home.

Michaelis is blunt about why that doesn’t work:

And listen, I’m not knocking craft. I love writing poetry, painting, throwing pots at the wheel. All that takes craft and skill, just as my designs at work do. But craft should be so obvious to us as designers that we should not make it our main selling point. Obviously, we develop incredible craft as our experience builds. Obviously, individual designers have different styles. Obviously, we put thought and care into what we make.

Craft is the baseline. That’s what we want the executives to know. By debating it and what it even means, we’re again undermining our authority.

She’s right, and I’d push it further. The fixation on craft is a tell. When a profession retreats to arguing about what makes it special instead of demonstrating it, that’s a group reaching for identity because it’s lost agency. The creative class version of quiet quitting.

The junior designer hiring crisis is a subject that’s near and dear to my heart, and Figma’s new hiring study puts hard numbers to it. The headline is encouraging—82% of organizations say their need for designers has increased or stayed steady. But the breakdown by seniority tells a different story.

Andrew Hogan, Head of Insights at Figma:

More than half of hiring managers (56%) say there’s increasing demand for senior design hires, compared to just 25% who are hiring for more junior roles. For many leaders, it’s less of a hiring philosophy and more a matter of bringing on designers who can tackle the problems they’re facing.

56% versus 25%. That gap keeps widening.

Daniel Wert, CEO of executive search firm Wert&Co, calls it out:

It just boggles my mind how few internship programs there are these days. I think it seems shortsighted. The best teams, the best organizations, have a lot of diversity…in terms of years of experience and where people are in their career. You want to have a nice cross-section of junior and mid-senior designers.

Every strong design team I’ve built or been part of had that cross-section. Seniors set the bar. Juniors challenge assumptions and bring energy. Mid-levels hold the whole thing together. Remove any layer and it gets brittle.

Wert again:

Hiring managers are looking for unicorns because they misunderstand how multidisciplinary design is. They want [top-tier] design, but are only willing to hire one person. Great design teams [have] multiple people with complementary strengths—not a single superhero.

This is the real problem. Companies want one person who can do visual design, product strategy, systems thinking, AI integration, and user research. That person doesn’t exist. Great design is a team sport, and the vanishing bottom rung of the career ladder is only making it harder to build those teams.

The fallacy that CEOs and CFOs keep telling themselves is that AI will make this unicorn “product builder” possible. I have my doubts.

Geoffrey Huntley makes a claim that should bother every designer. He’s listing what isn’t a moat in the AI era:

Any product features or platforms that were designed for humans. I know that’s going to sound really wild, but understand these days I go window-shopping on SaaS companies’ websites for product features, rip a screenshot into Claude Code, and it rebuilds that product feature/platform. As we enter the era of hyper-personalised software, I think this will be the case more and more. In my latest creation, I have cloned Posthog, Jira, Pipedrive, and Calendly, and the list just keeps on growing because I want to build a hyper-personalised business that meets all my needs, with full control and everything first-party.

“Features designed for humans” aren’t a moat. Not because design doesn’t matter—because the implementation can be cloned from a screenshot. Huntley himself rebuilt versions of Posthog, Jira, Pipedrive, and Calendly.

Huntley invented the Ralph loop—a technique for running AI coding agents in continuous loops that ship production software at a fraction of the old cost. He’s been tracking the economic fallout for a year:

The cost of software development is $10.42 an hour, which is less than minimum wage and a burger flipper at macca’s gets paid more than that. What does it mean to be a software developer when everyone in the world can develop software? Just two nights ago, I was at a Cursor meetup, and nearly everyone in the room was not a software developer, showing off their latest and greatest creations.

Well, they just became software developers because Cursor enabled them to become one. You see, the knowledge and skill of being a software developer has been commoditised.

Swap “software developer” for “designer.” Anton Sten rebuilt his website and invoicing system without writing code. Édouard Wautier’s team skips Figma after the initial sketch and prototypes directly in code. The commoditization Huntley describes is already arriving for design:

AI erases traditional developer identities—backend, frontend, Ruby, or Node.js. Anyone can now perform these roles, creating emotional challenges for specialists with decades of experience.

“UI designer,” “UX designer,” “interaction designer”—these specializations made sense when each required distinct tools and workflows. When an AI agent can handle the execution across all three, the labels stop carrying weight.

So if the implementation layer isn’t the moat, what is? Huntley’s answer for business is distribution, utility pricing, and operating model-first. The design answer is adjacent: knowing what to build and what to leave out. Taste. Judgment. The ability to look at what Claude generated from a screenshot and know it’s solving the wrong problem.

AI can now generate photographs you can’t distinguish from real ones. Illustrations that look hand-drawn. But ask it to design a typeface and you get garbage. Type design remains one of the few disciplines where the human hand is still obvious, and that gap is about to matter a lot more than people think.

Design provocateur Jessica Walsh, writing for Creative Boom, makes the case that typography is becoming the last credible signal of human craft. The piece comes from a branding perspective, and the diagnosis of the current type market is sharp:

A lot of type foundries understandably focus on mass-market needs: ultra-neutral workhorse sans serifs, or fonts that are basically just a slightly warmer, narrower, rounder, or “friendlier” cousin of something that already exists. These fonts do their job. They’re flexible. They’re safe. They sell well. But safety isn’t what builds distinction.

That’s been true for a while. What’s changing is the AI layer on top. When every brand has access to the same generators and stock libraries, the visual output converges fast. Walsh argues this makes human typography more valuable:

We’re entering an era where people will crave proof of human craft more than ever, because they literally won’t be able to trust what they’re seeing.

And the punchline:

Custom typography is about to become one of the most powerful ways for brands to signal: a human made this.

Typography was always the quiet differentiator in branding. Most people can’t name the typeface on their favorite brand, but they’d notice if it changed. AI just turned that quiet differentiator into a loud one. Worth a full read if you work in brand design.

Every junior designer or intern I’ve ever managed has eventually wandered over with the same sheepish question about whether they can use something they found online. Nobody teaches this stuff. Design programs spend semesters on typography and color theory but maybe one lecture on intellectual property, if that. So designers learn copyright law the hard way—by getting a yelled at by their freaked out creative director, or watching a colleague get yelled at.

Michele Hratko, a Pittsburgh-based designer, made a book about it. Who Owns This Book? started from the same questions:

As a design student, I frequently overhear peers asking questions along the lines of: can I use this image from Google in a poster? Can I use this trial font without buying it for a project? How much do I have to edit an image I find online before I can use it? The goal of this book was to respond to my peers’ musings and begin to answer those questions.

The lovely book is split into three sections—Who Owns This Library? Who Owns This Machine? Who Owns This Image?—and uses seven different paper stocks, color-coded sections, and a typeface chosen specifically for friendliness. Hratko on why the design choices matter:

Copyright law can also be kind of intimidating, so I wanted to use the design of the book to make the content more approachable and engaging.

That’s a long lost art—making essential-but-dry information something people actually want to pick up. The “Who Owns This Machine?” section is especially timely given every AI copyright case working its way through the courts right now.

“People are change averse,” Duolingo’s CEO Luis von Ahn said when users revolted against the app’s 2022 redesign. He refused to offer a revert option. The backlash was just resistance to change, and users would get over it, he argued.

Dora Czerna, writing for UX Collective, makes the case that von Ahn got it wrong. Users weren’t afraid of change. They’d lost something:

That old interface isn’t just a collection of buttons and menus–it’s ours. We’ve invested time learning it, built workflows around it, developed preferences and shortcuts. The new design might be objectively superior in controlled testing, but it requires us to surrender something we’ve claimed as our own.

That’s the endowment effect applied to software. The hours you spent learning an interface have real value, and a redesign zeroes them out. Calling that “change aversion” dismisses the investment.

Czerna points to Sonos as the worst-case scenario—users who’d spent thousands on home audio systems suddenly couldn’t adjust the volume after an app update. But even smaller changes trigger the same psychology. Google changed its crop tool from square corners to rounded ones and got enough backlash to reverse it.

Czerna on what happens when you tell users the new version tested better:

Telling users “we tested this, and it’s better” when they’re actively experiencing it as worse creates a disconnect. Acknowledging that change is difficult, explaining what you’re trying to achieve, and being responsive to legitimate concerns about lost functionality builds more goodwill than insisting everything is fine when it clearly isn’t.

What’s less common is teams treating the transition itself as a design problem worth solving. And of course it is.

The instinct when working with AI agents is to write more. More instructions, more constraints. Turns out that’s exactly wrong.

Addy Osmani, writing for O’Reilly, digs into the research:

Research has confirmed what many devs anecdotally saw: as you pile on more instructions or data into the prompt, the model’s performance in adhering to each one drops significantly. One study dubbed this the “curse of instructions”, showing that even GPT-4 and Claude struggle when asked to satisfy many requirements simultaneously. In practical terms, if you present 10 bullet points of detailed rules, the AI might obey the first few and start overlooking others.

So the answer is a smarter spec, not a longer one. Osmani pulls from GitHub’s analysis of over 2,500 agent configuration files and finds that effective specs cover six areas: commands, testing, project structure, code style, git workflow, and boundaries.

The boundaries piece is worth lingering on. Osmani recommends a three-tier system:

Always do: Actions the agent should take without asking. “Always run tests before commits.” “Always follow the naming conventions in the style guide.”

Ask first: Actions that require human approval. “Ask before modifying database schemas.” “Ask before adding new dependencies.”

Never do: Hard stops. “Never commit secrets or API keys.” “Never edit node_modules/ or vendor/.” “Never remove a failing test without explicit approval.”

That framing—always, ask first, never—gives the AI a decision framework instead of a wall of instructions. It maps to how you’d manage a person, too. Osmani quotes Simon Willison on the comparison: getting good results from a coding agent feels “uncomfortably close to managing a human intern.”

Klaassen’s compound engineering is one version of this. Osmani’s spec framework is another. The principle underneath both: teach fewer things well rather than everything at once.

Claude skills are structured markdown files that tell Claude how to handle a specific type of task. It is—as the name suggests—a new skill Claude or any AI agent can “learn.” Each one defines a role for Claude to adopt, the inputs it needs, a step-by-step workflow, and a quality bar for the output. You can build them for anything—research synthesis, writing, code review, design critique. Once loaded, Claude follows the workflow instead of improvising.

Nick Babich, writing for UX Planet, put together 10 skills aimed at product designers. The three I’d reach for first are the UX Heuristic Review, the Design Critique Partner, and the Competitor Analysis Generator. All three give a solo designer a structured second opinion on demand: a heuristic eval against Nielsen’s 10, a senior-level design critique, or a competitive feature matrix.

Babich’s skill format is clean and worth studying even if you end up building your own from scratch. (Hint: or use Claude Code to write its own skills.)