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.

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 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.

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.

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.

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.

“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.

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.)

Boris Cherny, head of Claude Code at Anthropic, on Lenny’s Podcast:

I think at this point it’s safe to say that coding is largely solved. At least for the kind of programming that I do, it’s just a solved problem because Claude can do it. And so now we’re starting to think about what’s next, what’s beyond this. Claude is starting to come up with ideas. It’s looking through feedback. It’s looking at bug reports. It’s looking at telemetry for bug fixes and things to ship—a little more like a co-worker or something like that.

“Largely solved” is a big claim from the person running the tool that’s solving it. And then he goes further—Claude is starting to decide what to build. That’s product management work.

Cherny on what his team at Anthropic already looks like:

On the Claude Code team, everyone codes. Our product manager codes, our engineering manager codes, our designer codes, our finance guy codes, our data scientist codes.

And on where the role boundaries are heading:

There’s maybe a 50% overlap in these roles where a lot of people are actually just doing the same thing and some people have specialties. I think by the end of the year the title software engineer is going to start to go away and it’s just going to be replaced by builder. Or maybe everyone’s going to be a product manager and everyone codes.

But where does design fit in all this? A PM can define the problem, maybe even come up with a good solution. But does Cherny think that AI will be the designer?

Lenny ran polls asking engineers, PMs, and designers whether they enjoy their jobs more or less since adopting AI. Engineers and PMs: 70% said more. Designers went the other direction with only 55% who said they were enjoying their job more, and 18%—nearly twice as many as engineers—said they were enjoying their job less.

Cherny’s reaction:

Our designers largely code. So I think for them this is something that they have enjoyed because they can unblock themselves.

That’s an engineer’s answer to a design question. Designers at Anthropic are happy because they can ship without waiting on a developer. But “unblocking yourself” isn’t the same as “AI can do the design.” Cherny doesn’t touch the user experience, visual thinking, the spatial reasoning.

My theory: Designers are visual people. Typing to design doesn’t really compute. And who can blame us?

I wrote recently about what Wall Street gets wrong about SaaS—how the $285 billion selloff confuses capability with full-throated DIY. Mission-critical enterprise software isn’t going anywhere. But I also argued that micro-apps are a different story. Small, personal utilities that solve one person’s problem? Those are absolutely getting built by non-developers now.

Anton Sten is a good example. Like me, he’s a designer, not a developer, who rebuilt his website with Cursor and Claude last year and then turned his attention to replacing the $11/month invoicing tool he’d been paying for. The initial version followed familiar SaaS patterns. Then something clicked:

I was building software that lived by old rules. Rules designed for generic tools that serve thousands of users. But this tool serves exactly one user. Me.

So I changed it. Now, instead of manually entering client details, I upload a signed contract and let AI parse it — mapping it to an existing client or creating a new one, extracting the scope, payment terms, duration, everything. It creates my own vault of documents. I added an AI chat where I can ask things like “draft an invoice for unbilled time on Project X” or “what’s the total amount invoiced to Client Y this year?”

That’s the micro-apps argument in practice. A tool shaped entirely around one person’s workflow, built in under two days. Jonny Burch stated that the source of truth for design is moving from Figma to code. Sten is further along that path—a designer who stopped hiring developers entirely.

Sten on the broader shift in thinking:

For decades, the default response to any problem was “what software should I subscribe to?” We browsed Product Hunt. We compared pricing pages. We squeezed our workflows into someone else’s idea of how things should work.

The point isn’t the tool. The point is the muscle. Once you’ve built one thing, you start seeing opportunities everywhere. You stop asking “is there an app for that?” and start asking “what if I just made it?”

Victor Yocco lays out a UX research playbook for agentic AI in Smashing Magazine—autonomy taxonomy, research methods, metrics, the works. It’s one of the more practical pieces I’ve seen on designing AI that acts on behalf of users.

The autonomy framework is useful. Yocco maps four modes from passive monitoring to full autonomy, and the key insight is that trust isn’t binary:

A user might trust an agent to act autonomously for scheduling, but keep it in “suggestion mode” for financial transactions.

That tracks with how I think about designing AI features. The same user will want different levels of control depending on what’s at stake. Autonomy settings should be per-domain, not global.

On measuring whether it’s working:

For autonomous agents, we measure success by silence. If an agent executes a task and the user does not intervene or reverse the action within a set window, we count that as acceptance.

That’s a different and interesting way to think about design metrics—success as the absence of correction. Yocco pairs this with microsurveys on the undo action so you’re not just counting rollbacks but understanding why they happen.

The cautionary section is worth flagging. Yocco introduces “agentic sludge”—where traditional dark patterns add friction to trap users, agentic sludge removes friction so users agree to things that benefit the business without thinking. Pair that with LLMs that sound authoritative even when wrong, and you have a system that can quietly optimize against the user’s interests. We’ve watched this happen before with social media. The teams that skip the research Yocco describes are the ones most likely to build it again.

Jonny Burch argued that design’s source of truth is moving from Figma to code. Édouard Wautier is already there. He wrote up a field report on how Dust’s design team prototypes directly in code.

After the initial analysis and quick sketchbook phase, when I need to give the idea shape and pressure-test it, I don’t open Figma. I open my development environment, pull the latest version of our repo, and create a branch. Then I ask an agent to scaffold a new prototype, and I describe what I’m trying to make.

The prototype isn’t a picture of the product—it’s built from the same design system components and tokens. So what is Wautier optimizing for at this stage?

At this point I mostly care about trying the idea and seeing whether the interaction holds. I’ll build small flows, prototype the transitions, and sanity-check the parts that static screens often hide (state changes, error cases, motion, empty states, keyboard/navigation/accessibility basics).

He’s honest about the trade-offs. You occasionally lose 30 minutes to a tooling issue. Prototypes can invite premature polish because they look real too early. And handoff clarity gets muddy—engineers aren’t always sure what’s prototype-only versus reusable.

Wautier’s closing:

More like clay than drafting: you shape, you test, you feel, you adjust — with an instantaneous feedback loop. The artifact is no longer a description of the thing. It starts to become the thing, or at least a runnable slice of it.

I believe this is the future.

The source of truth for product design is shifting from Figma to code. I’ve been making that argument from the design side. Jonny Burch is making it from the tooling side, with a sharper prediction about what replaces Figma: nothing owned by one company.

Burch on where design interfaces are headed:

As product, design and engineering collapse together, design interfaces will start to look more like dependencies in the code itself.

A mature design system already lives in code—the Figma components are a mirror, not the original. Once AI agents can read and build against that code directly, the mirror becomes optional. Burch sees this leading to a fragmented ecosystem of code-first plugins and open tools rather than a single Figma replacement. I think he’s right about the direction, if aggressive on the timeline.

On why the pressure is building:

In modern teams it’s no longer acceptable for a designer to spend 2 weeks in their mind palace creating the perfect UI.

It’s starting to happen on my own team. Engineers with AI agents are producing working features in hours. The design phase—the Figma phase—is now the slowest part of the cycle. That’s a new and uncomfortable feeling for designers who grew up in a world where engineering was always the bottleneck.

Burch on Figma’s position in all of this:

They’re suddenly the slow incumbent with the wrong tech stack and a large enterprise customer-base adding drag.

I watched the same dynamic play out when Figma displaced Sketch. The dominant tool doesn’t always adapt fast enough. Sometimes the market just routes around it.

To be sure, I don’t wish for the death of Figma. Designers are visual thinkers and that’s what makes us different than PMs and engineers. I’m sure we’ll continue to use Figma for initial UI explorations. But instead of building out 40-screen flows, we’ll quickly move into code and generate a prototype that’ll look and feel like what we’re going to ship.

The software development process has accumulated decades of ceremony. Boris Tane argues AI agents are collapsing the whole thing.

On engineers who started their careers after Cursor:

They don’t know what the software development lifecycle is. They don’t know what’s DevOps or what’s an SRE. Not because they’re bad engineers. Because they never needed it. They’ve never sat through sprint planning. They’ve never estimated story points. They’ve never waited three days for a PR review.

I read that and thought about design. How much of our process is ceremony too? The Figma-to-developer handoff. The pixel-perfect QA pass. The design review where six people debate border radius. If an AI agent can generate working UI from a design system in three prompts—which I’ve done—a lot of what we treat as process is friction we’ve institutionalized.

Tane’s conclusion:

The quality of what you build with agents is directly proportional to the quality of context you give them. Not the process. Not the ceremony. The context.

For engineering, context means specs, tests, architectural constraints. For design, it means your design system—the component docs and the rules for how things fit together. If that context is thin, the agent produces garbage. If it’s thorough and machine-readable, the output lands close to production-ready.

Tane again:

Requirements aren’t a phase anymore. They’re a byproduct of iteration.

Same for mockups. When you can generate and evaluate working UI faster than you can annotate a Figma frame, the mockup stops being a deliverable and becomes a sketch you might skip entirely. The design system becomes the spec. Context engineering becomes the job.

I’ve been arguing that the designer’s job is shifting from execution to orchestration—directing AI agents rather than pushing pixels. I made that case from the design side. Addy Osmani just made it from engineering based on what he’s seeing.

Osmani draws a hard line between vibe coding and what he calls “agentic engineering.” On vibe coding:

Vibe coding means going with the vibes and not reviewing the code. That’s the defining characteristic. You prompt, you accept, you run it, you see if it works. If it doesn’t, you paste the error back and try again. You keep prompting. The human is a prompt DJ, not an engineer.

“Prompt DJ” is good. But Osmani’s description of the disciplined version is what caught my attention—it’s the same role I’ve been arguing designers need to grow into:

You’re orchestrating AI agents - coding assistants that can execute, test, and refine code - while you act as architect, reviewer, and decision-maker.

Osmani again:

AI didn’t cause the problem; skipping the design thinking did.

An engineer wrote that. The spec-first workflow Osmani describes is design process applied to code. Designers have been saying “define the problem before you jump to solutions” for decades. AI just made that advice load-bearing for engineers too.

The full piece goes deep on skill gaps, testing discipline, and evaluation frameworks—worth a complete read.

Nolan Lawson opens with a line that’s hard to argue with:

The worst fact about these tools is that they work. They can write code better than you or I can, and if you don’t believe me, wait six months.

He’s right. They do work.

Lawson again:

I didn’t ask for the role of a programmer to be reduced to that of a glorified TSA agent, reviewing code to make sure the AI didn’t smuggle something dangerous into production.

It’s a vivid image. But the people I know doing this work well look more like film directors than airport security—they’re deciding what gets built and when to throw the model’s work away. That’s a different job.

Lawson on economic gravity:

Ultimately if you have a mortgage and a car payment and a family you love, you’re going to make your decision. It’s maybe not the decision that your younger, more idealistic self would want you to make, but it does keep your car and your house and your family safe inside it.

I’ve seen this play out with every industry shift I’ve lived through—desktop publishing, print to web, responsive design. Each time, the people with financial obligations adapted first and mourned later. The idealism erodes fast when the market moves.

Where I part ways with Lawson is the framing. He presents two options: abstain on principle, or capitulate for the paycheck. There’s a third path—use the tools to expand what your craft can produce. The grief is real. So is the third path.

I’ve been watching the design community fracture over the past year. Not over tools or methodologies—over what it means to be a designer at all. One camp is excited about AI-assisted workflows, shipping working UI from terminals. The other is doubling down on pixel-craft in Figma, treating the shift as a threat to everything they’ve built their careers on. Dave Gauer published a piece that puts words to this feeling better than anything I’ve read from the design side:

It’s weird to say I’ve lost it when I’m still every bit the computer programmer (in both the professional and hobby sense) I ever was. My love for computers and programming them hasn’t diminished at all. But a social identity isn’t about typing on a keyboard, It’s about belonging to a group, a community, a culture.

He hasn’t lost the skill. He’s lost the tribe. I recognize that grief. When I wrote about these same changes hitting design, a former colleague responded: “I didn’t sign up for this.” None of us did. And I think UX and product designers are less than twelve months behind programmers in feeling this exact thing.

He describes what drove the wedge:

When I identified with the programmer culture, it was about programming. Now programming is a means to an end (“let’s see how fast we can build a surveillance state!”) or simply an unwanted chore to be avoided.

Swap “programming” for “design” and you’re looking at the trajectory I wrote about in “Product Design Is Changing.” When the craft becomes something an AI agent can approximate, the culture around it shifts. The conversation moves from “how do we make this great?” to “how fast can we ship this?” The designers who cared about the craft are watching their community become unrecognizable. I get it.

And then there’s this, on what the programming community actually lost:

We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.

That “slot machine lever” is the programmer’s version of the vibe coding critique. The craft people—in programming and in design—wanted better tools. What they got was a culture that treats the craft itself as an obstacle to speed.

The identity split I described in my essay is already visible: designers who orchestrate AI and ship working software versus designers who push pixels in Figma. The deeper question Gauer is circling is whether the craft was ever the point for you, or just the bottleneck.