Earlier this week I linked to Gale Robins’ argument that AI makes execution cheap but doesn’t help you decide what to build. Christina Wodtke is making the same case from the research side.

Christina Wodtke opens with a designer who spent two weeks vibe-coding a gratitude journaling app. Beautiful interface, confetti animations, gentle notifications. Then she showed it to users. “I don’t really journal,” said the first one. “Gratitude journaling felt performative,” said the second. Two weeks building the wrong thing. Wodtke’s diagnosis:

That satisfaction is a trap. You’re accumulating artifacts that may have nothing to do with what anyone needs.

Wodtke draws a line between need-finding and validation that I think a lot of teams blur. Skipping the first and jumping to the second means you’re testing your guess, not understanding the problem:

Need-finding happens before you have a solution. You’re listening to people describe their lives, their frustrations, their workarounds. You’re hunting for problems that actually exist—problems people care enough about that they’re already trying to solve them with spreadsheets and sticky notes and whatever else they’ve cobbled together.

Wodtke’s version of fast looks different from what you’d expect:

The actual fast path is unsexy: sit down with five to ten people. Ask them about their lives. Shut up and listen. Use those three magic words—“tell me more”—every time something interesting surfaces. Don’t show them anything. Don’t pitch. Just listen.

“You’ll build less. It’ll be the right thing.” When building is cheap, the bottleneck moves upstream to judgment, knowing what to build. That judgment comes from listening, not prompting.

Last September I wrote about why we still need a HyperCard for the AI era—a tool that’s accessible but controllable, that lets everyday people build and share software without needing to be developers. John Allsopp sees the demand side of that equation already arriving.

Writing on LinkedIn, he starts with his 13-year-old daughter sending him a link to Aippy, a platform where people create, share, and remix apps like TikTok videos. It already has thousands of apps on it:

Millions of people who have never written a line of code are starting to build applications — not scripts or simple automations, but genuine applications with interfaces and logic and persistence.

The shift Allsopp describes isn’t just about who’s building. It’s about how software spreads:

This pattern — creation, casual sharing, organic spread — looks a lot more like how content moves on TikTok or Instagram than how apps move through the App Store. Software becomes something you make and share, and remix. Not something you publish and sell. It surfaces through social connections and social discovery, not through store listings and search rankings.

And the platforms we have aren’t built for it. Allsopp points out that the appliance model Apple introduced in 2007 made sense for an audience that was intimidated by technology. That audience grew up:

The platforms designed to protect users from complexity are now protecting users from their own creativity and that of their peers.

This is the world I was writing about in “Why We Still Need a HyperCard for the AI Era.” I argued for tools with direct manipulation, technical abstraction, and local distribution—ingredients HyperCard had that current AI coding tools still miss. Allsopp is describing the audience those tools need to serve. The gap between the two is where the opportunity sits.

Designers know this feeling. Your work lives inside whatever tool made it—Figma, Miro, Framer—and when that tool changes its pricing, gets acquired, or shuts down, your files go with it. We’ve now accepted this as normal.

Dan Abramov argues it shouldn’t be. In a long post about the AT Protocol (the technology behind Bluesky), he starts with how files used to work on personal computers:

The files paradigm captures a real-world intuition about tools: what we make with a tool does not belong to the tool. A manuscript doesn’t stay inside the typewriter, a photo doesn’t stay inside the camera, and a song doesn’t stay in the microphone.

He takes that intuition and applies it to social computing. What if your posts, likes, and follows were files you owned instead of data locked inside Instagram or Twitter? Abramov calls this a “social filesystem” and walks through how the AT Protocol makes it real, from records and collections to identity and links, all building toward one idea:

Our memories, our thoughts, our designs should outlive the software we used to create them. An app-agnostic storage (the filesystem) enforces this separation.

That word “designs” jumped out at me. Abramov is talking about social data, but the same logic applies to creative work. The inversion he describes, where apps react to your data rather than owning it, is the opposite of how most design tools work today:

In this paradigm, apps are reactive to files. Every app’s database mostly becomes derived data—an app-specific cached materialized view of everybody’s folders.

One of the reasons I write content here on this blog as opposed to writing in a social network or even Substack—though my newsletter is on Substack, humans aren’t perfect—is because I want the control and ownership Abramov brings up.

The whole post is worth reading. Abramov makes the AT Protocol’s architecture feel inevitable rather than complicated, and his closing line is the one I keep thinking about: “An everything app tries to do everything. An everything ecosystem lets everything get done.”

Earlier I linked to Hardik Pandya’s piece on invisible work—the coordination, the docs, the one-on-ones that hold projects together but never show up in a performance review. Designers have their own version of this problem, and it’s getting worse.

Kai Wong, writing in his Data and Design Substack, puts it plainly. A design manager he interviewed told him:

“It’s always been a really hard thing for design to attribute their hard work to revenue… You can make the most amazingly satisfying user experience. But if you’re not bringing in any revenue out of that, you’re not going to have a job for very much longer. The company’s not going to succeed.”

That’s always been true, but AI made it urgent. When a PM can generate something that “looks okay” using an AI tool, the question is obvious: what do we need designers for? Wong’s answer is the strategic work—research, translation between user needs and business goals. The trouble is that this work is the hardest to see.

Wong’s practical advice is to stop presenting design decisions in design terms. Instead of explaining that Option A follows the Gestalt principle of proximity, say this:

“Option A reduces checkout from 5 to 3 steps, making it much easier for users to complete their purchase instead of abandoning their cart.”

You’re not asking “which looks better?” You’re showing that you understand the business problem and the user problem, and can predict outcomes based on behavioral patterns.

I left a comment on this article when it came out, asking how these techniques translate at the leadership level. It’s one thing to help individual designers frame their work in business terms. It’s another to make an entire design org’s contribution legible to the rest of the company. Product management talks to customers and GTM teams. Engineering delivers features. Design is in the messy middle making sense of it all—and that sense-making is exactly the kind of invisible work that’s hardest to put on a slide.

For as long as I’ve been in startups, execution speed has been the thing teams optimized for. The assumption was always that if you could just build faster, you’d win. That’s your moat. AI has mostly delivered on that promise—teams can now ship in weeks—see Claude Cowork—what used to take months. And the result is that a lot of teams are building the wrong things faster than ever.

Gale Robins, writing for UX Collective, opens with a scene I’ve lived through from both sides of the table:

I watched a talented software team present three major features they’d shipped on time, hitting all velocity metrics. When I asked, “What problem do these features solve?” silence followed. They could describe what they’d built and how they’d built it. But they couldn’t articulate why any of it mattered to customers.

Robins argues that judgment has replaced execution as the real constraint on product teams. And AI is making this worse, not better:

What once took six months of misguided effort now takes six weeks, or with AI, six days.

Six days to build the wrong thing. The build cycle compressed but the thinking didn’t. Teams are still skipping the same discovery steps, still assuming they know what users want. They’re just doing it at a pace that makes the waste harder to catch.

Robins again:

AI doesn’t make bad judgment cheaper or less damaging — it just accelerates how quickly those judgment errors compound.

She illustrates this with a cascade example: a SaaS company interviews only enterprise clients despite SMBs making up 70% of revenue. That one bad call—who to talk to—ripples through problem framing, solution design, feature prioritization, and evidence interpretation, costing $315K over ten months. With AI-accelerated development, the same cascade plays out in five months at the same cost. You just fail twice as fast.

The article goes on to map 19 specific judgment points across the product discovery process. The framework itself is worth a read, but the underlying argument is the part I keep coming back to: as execution gets cheaper, the quality of your decisions is the only thing that scales.

I’ve watched this pattern play out more times than I can count: a team ships something genuinely better and users ignore it. They go back to the old thing. The spreadsheet. The manual process. And the team concludes that users “resist change,” which is the wrong diagnosis.

Tushar Deshmukh, writing for UX Magazine, frames it well:

Many teams assume users dislike change. In reality, users dislike cognitive disruption.

Deshmukh describes an enterprise team that built a predictive dashboard with dynamic tiles, smart filters, and smooth animations. It failed. Employees skipped it and went straight to the basic list view:

Not because the dashboard was bad. But because it disrupted 20 years of cognitive routine. The brain trusted the old list more than the new intelligence. When we merged both—familiar list first, followed by predictive insights—usage soared.

He tells a similar story about a logistics company that built an AI-powered route planner. Technically superior, visually polished, low adoption. Drivers had spent years building mental models around compass orientation, landmarks, and habitual map-reading patterns:

The AI’s “optimal route” felt psychologically incorrect. It was not wrong—it was unfamiliar. We added a simple “traditional route overlay,” showing older route patterns first. The AI suggestion was then followed as an enhancement. Adoption didn’t just improve—trust increased dramatically.

The fix was the same in both cases: layer the new on top of the familiar. Don’t replace the mental model—extend it. This is something I think about constantly as my team designs AI features into our product. The temptation is always to lead with the impressive new capability. But if users can’t find their footing in the interface, the capability doesn’t matter. Familiarity is the on-ramp.

Fitts’s Law is one of those design principles everyone learns in school and then quietly stops thinking about. Target size, target distance, movement time. It’s a mouse-and-cursor concept, and once you’ve internalized the basics—make buttons big, put them close—it fades into the background. But with AI and voice becoming primary interaction models, the principle matters again. The friction just moved.

Julian Scaff, writing for Bootcamp, traces Fitts’s Law from desktop GUIs through touch, spatial computing, voice, and neural interfaces. His argument is that the law didn’t become obsolete—it became metaphorical:

With voice interfaces, the notion of physical distance disappears altogether, yet the underlying cognitive pattern persists. When a user says, “Turn off the lights,” there’s no target to touch or point at, but there is still a form of interaction distance, the mental and temporal gap between intention and response. Misrecognition, latency, or unclear feedback increase this gap, introducing friction analogous to a small or distant button.

“Friction analogous to a small or distant button” is a useful way to think about what’s happening with AI interfaces right now. When a user stares at a blank text field and doesn’t know what to type, that’s distance. When an agent misinterprets a prompt and the user has to rephrase three times, that’s a tiny target. The physics changed but the math didn’t.

Scaff extends this into AI and neural interfaces, where the friction gets even harder to see:

Every layer of mediation, from neural decoding errors to AI misinterpretations, adds new forms of interaction friction. The task for designers will be to minimize these invisible distances, not spatial or manual, but semantic and affective, so that the path from intention to effect feels seamless, trustworthy, and humane.

He then describes what he calls a “semantic interface,” one that interprets intent rather than waiting for explicit commands:

A semantic interface understands the why behind a user’s action, interpreting intent through context, language, and behavior rather than waiting for explicit commands. It bridges gaps in understanding by aligning system logic with human mental models, anticipating needs, and communicating in ways that feel natural and legible.

This connects to the current conversation about AI UX. The teams building chatbot-first products are, in Fitts’s terms, forcing users to cross enormous distances with tiny targets. Every blank prompt field with no guidance is a violation of the same principle that tells you to make a button bigger. We’ve known this for seventy years. We’re just ignoring it because the interface looks new.

For years, the thing that made designers valuable was the thing that was hardest to fake: the ability to look at a spreadsheet of requirements and turn it into something visual that made sense. That skill got people hired and got them a seat at the table. And now a PM with access to Lovable or Figma Make can produce something that looks close enough to pass.

Kai Wong interviewed 22 design leaders and heard the same thing from multiple directions. One Global UX Director described the moment it clicked for his team:

“A designer on my team had a Miro session with a PM — wireframes, sketches, the usual. Then the PM went to Stitch by Google and created designs that looked pretty good. To an untrained eye, it looked finished. It obviously worried the team.”

It should worry teams. Not because the PM did anything wrong, but because designers aren’t always starting from a blank canvas anymore. They’re inheriting AI-generated drafts from people who don’t know what’s wrong with them.

Wong puts the commoditization bluntly:

Our superpower hasn’t been taken away: it’s more like anyone can buy something similar at the store.

The skill isn’t gone. It’s just no longer rare enough to carry your career on its own. What fills the gap, Wong argues, is the ability to articulate why—why this layout works, why that one doesn’t. One CEO he interviewed put it this way:

“I want the person who’s designing the thing from the start to understand the full business context.”

This resonates with me as a design leader. The designers on my teams who are hardest to replace are the ones who can walk into a room and explain why something needs to change, and tie that explanation to a user need or a business outcome. AI can’t do that yet. And the people generating those 90%-done drafts definitely can’t.

Every few years, the industry latches onto an interaction paradigm and tries to make it the answer to everything. A decade ago it was “make it an app.” Now it’s “just make it a chat.” The chatbot-as-default impulse is strong right now, and it’s leading teams to ship worse experiences than what they’re replacing.

Katya Korovkina, writing for UX Collective, calls this “chatbot-first thinking” and lays out a convincing case for why it’s a trap:

Many of the tasks we deal with in our personal life and at work require rich, multi-modal interaction patterns that conversational interfaces simply cannot support.

She walks through a series of validating questions product teams should ask before defaulting to a conversational UI, and the one that stuck with me is about discoverability. The food ordering example is a good one—if you don’t know what you want, listening to a menu read aloud is objectively worse than scanning one visually. But the real issue is who chat-first interfaces actually serve:

Prompt-based products work best for the users who already know how to ask the right question.

Jakob Nielsen has written about this as the “articulation barrier,” and Korovkina cites the stat that nearly half the population in wealthy countries struggles with complex texts. We’re building interfaces that require clear, precise written communication from people who don’t have that skill. And we’re acting like that’s fine because the technology is impressive.

Korovkina also makes a practical point that gets overlooked. She describes using a ChatGPT agent to get a YouTube transcript — a task that takes four clicks with a dedicated tool — and watching the agent spend minutes crawling the web, hitting paywalls, and retrying failures:

When an LLM agent spends five minutes crawling the web, calling tools, retrying failures, reasoning through intermediate steps, it is running on energy-intensive infrastructure, contributing to real data-center load, energy usage, and CO₂ emissions. For a task that could be solved with less energy by a specialised service, this is computational overkill.

The question she lands on—“was AI the right tool for this task at all?”—is the one product teams keep skipping. Sometimes a button, a dropdown, and a confirmation screen is the better answer.

Back in September, when Trump announced America by Design and appointed Joe Gebbia as Chief Design Officer, I wrote that it was “yet another illustration of this administration’s incompetence.” The executive order came months after DOGE gutted 18F and the US Digital Service, the agencies that had spent a decade building the expertise Gebbia now claims to be inventing.

Mark Wilson, writing for Fast Company, spoke to a dozen government designers about how Gebbia’s tenure has played out. When Wilson asked Gebbia about USDS and 18F—whether he thought these groups were overrated and needed to be rebuilt—here’s what he said:

“Without knowing too much about the groups you mentioned, I do know that the air cover and the urgency around design is in a place it’s [never] been before.”

He doesn’t know much about them. The agencies his administration destroyed. The hundreds of designers recruited from Google, Amazon, and Facebook who fixed healthcare.gov and built the COVID test ordering system. He doesn’t know much about them.

Mikey Dickerson, who founded USDS, on the opportunity Gebbia inherited:

“He’s inheriting the blank check kind of environment… [so] according to the laws of physics, he should be able to get a lot done. But if the things that he’s allowed to do, or the things that he wants to do, are harmful, then he’ll be able to do a lot of harm in a really short amount of time.”

And what has Gebbia done with that blank check? He’s built promotional websites for Trump initiatives: trumpaccounts.gov, trumpcard.gov, trumprx.com. Paula Scher of Pentagram looked at the work:

“The gold card’s embarrassing. The typeface is hackneyed.”

But Scher’s real critique goes beyond aesthetics.

“You can’t talk about people losing their Medicare and have a slick website,” says Paula Scher. “It just doesn’t go.”

That’s the contradiction at the center of America by Design. You can’t strip food stamps, gut healthcare subsidies, and purge the word “disability” from government sites, then turn around and promise to make government services “delightful.” The design isn’t the problem. The policy is.

Scher puts it plainly:

“[Trump] wants to make it look like a business. It’s not a business. The government is a place that creates laws and programs for society—it’s not selling shit.”

Wilson’s piece is long and worth reading in full. There’s more on what USDS and 18F actually accomplished, and on the designers who watched their work get demolished by people who didn’t understand it.

Daniel Kennett dug out his old Mac Pro to revisit Aperture, the photo app Apple discontinued in 2015:

It’s hard to overstate quite how revolutionary and smooth this flow is until you had it for multiple years before having it taken away. Nothing on the market—even over a decade later—is this good at meeting you where you are and not interrupting your flow.

Kennett’s observation: Aperture came to you. Most software makes you go to it. You could edit a photo right on the map view, or while laying out a book page. No separate editing mode. Press H for the adjustments HUD, make your changes, done.

The cruel twist was Apple suggesting Photos as a replacement. Ten years later, photographers are still grumbling about it in comment sections.

I spent all of last week linking to articles that say designers need to be more strategic. I still stand by that. But that doesn’t mean we shouldn’t understand the technical side of things.

Benhur Senabathi, writing for UX Collective, shipped 3 apps and 15+ working prototypes in 2025 using Claude Code and Cursor. His takeaway:

I didn’t learn to code this year. I learned to orchestrate. The difference matters. Coding is about syntax. Orchestration is about intent, systems, and knowing what ‘done’ looks like. Designers have been doing that for years. The tools finally caught up.

The skills that make someone good at design—defining outcomes, anticipating edge cases, communicating intent to people who don’t share your context—are exactly what AI-assisted building requires.

Senabathi again:

Prompting well isn’t about knowing to code. It’s about articulating the ‘what’ and ‘why’ clearly enough that the AI can handle the ‘how.’

This echoes how Boris Cherny uses Claude Code. Cherny runs 10-15 parallel sessions, treating AI as capacity to orchestrate rather than a tool to use. Same insight, different vantage point: Cherny from engineering, Senabathi from design.

One of my favorite parts of shipping a product is finding out how people actually use it. Not how we intended them to use it—how they bend it, repurpose it, surprise us with it. That’s when you learn what you really built.

Karo Zieminski, writing for Product with Attitude, captures a great example of this in her breakdown of Anthropic’s Cowork launch. She quotes Anthropic engineer Boris Cherny:

Since we launched Claude Code, we saw people using it for all sorts of non-coding work: conducting vacation research, creating slide presentations, organizing emails, cancelling subscriptions, retrieving wedding photos from hard drives, tracking plant growth, and controlling ovens.

Controlling ovens. I love it. Users took a coding tool and turned it into a general-purpose assistant because that’s what they needed it to be.

Simon Willison had already spotted this:

Claude Code is a general agent disguised as a developer tool. What it really needs is a UI that doesn’t involve the terminal and a name that doesn’t scare away non-developers.

That’s exactly what Anthropic shipped in Cowork. Same engine, new packaging, name that doesn’t say “developers only.”

This is the beauty of what we do. Once you create something, it’s really up to users to show you how it should be used. Your job is to pay attention—and have the humility to build what the behavior is asking for, not what your roadmap says.

Nice mini-site from the Figma showcasing the “iconic interactions” of the last 20 years. It explores how software has become inseparable from how we think and connect—and how AI is accelerating that shift toward adaptive, conversational interfaces. Made with Figma Make, of course.

“Taste” gets invoked constantly in conversations about what AI can’t replace. But it’s often left undefined—a hand-wave toward something ineffable that separates good work from average work.

Yan Liu offers a working definition:

Product taste is the ability to quickly recognize whether something is high quality or not.

That’s useful because it frames taste as judgment, not aesthetics. Can you tell if a feature addresses a real problem? Can you sense what’s off about an AI-generated PRD even when it’s formatted correctly? Can you distinguish short-term growth tactics from long-term product health?

Liu cites Rick Rubin’s formula:

Great taste = Sensitivity × Standards

Sensitivity is how finely you perceive—noticing friction, asking why a screen exists, catching the moment something feels wrong. Standards are your internal reference system for what “good” actually looks like. Both can be trained.

This connects to something Dan Ramsden wrote in his piece on design’s value in product organizations: “taste without a rationale is just an opinion.” Liu’s framework gives taste a rationale. It’s not magic. It’s pattern recognition built through deliberate exposure and reflection.

The closing line is the one that sticks:

The real gap won’t be between those who use AI well and those who don’t. It will be between those who already know what “good” looks like before they ever open an AI tool.

If design’s value isn’t execution—and AI is making that argument harder to resist—then what is it? Dan Ramsden offers a framework I find useful.

He breaks thinking into three types: deduction (drawing conclusions from data), induction (building predictions from patterns), and abduction—generating something new. Design’s unique contribution is abductive thinking:

When we use deduction, we discover users dropping off during a registration flow. Induction might tell us why. Abduction would help us imagine new flows to fix it.

Product managers excel at sense-making (aka “Why?”). Engineers build the thing. Design makes the difference—moving from “what is” to “what could be.”

On AI and the temptation to retreat to “creativity” or “taste” as design’s moat, Ramsden is skeptical:

Some might argue that it comes down to “taste”. I don’t think that’s quite right — taste without a rationale is just an opinion. I think designers are describers.

I appreciate that distinction. Taste without rationale is just preference. Design’s value is translating ideas through increasing levels of fidelity—from sketch to prototype to tested solution—validating along the way.

His definition of design in a product context:

Design is a set of structured processes to translate intent into experiments.

That’s a working definition I can use. It positions design not as the source of ideas (those can come from anywhere, including AI), but as the discipline that manages ideas through validation. The value isn’t in generating the concept—it’s in making it real while managing risk.

This piece cites my own research on the collapse of entry-level design hiring, but it goes further—arguing that AI didn’t cause the crisis. It exposed one that’s been building for over a decade.

Dolphia, writing for UX Collective:

We told designers they didn’t need technical knowledge. Then we eliminated their jobs when they couldn’t influence technical decisions. That’s not inclusion. That’s malpractice.

The diagnosis is correct. The design industry spent years telling practitioners they didn’t need to understand implementation. And now those same designers can’t evaluate AI-generated output, can’t participate in architecture discussions, can’t advocate effectively when technical decisions are being made.

Dolphia’s evidence is damning. When Figma Sites launched, it generated 210 WCAG accessibility violations on demo sites—and designers couldn’t catch it because they didn’t know what to look for:

The paradox crystalizes: tools marketed as democratization require more technical knowledge than traditional workflows, not less.

Where I’d add nuance: the answer isn’t “designers should learn to code.” It’s that designers need to understand the medium they’re designing for. There’s a difference between writing production code and understanding what code does, between implementing a database schema and knowing why data models influence user workflows.

I’ve been rebuilding my own site with AI assistance for over a year now. I can’t write JavaScript from scratch. But I understand enough about static site generation, database trade-offs, and performance constraints to make informed architectural decisions and direct AI effectively. That’s the kind of technical literacy that matters—not syntax, but systems thinking.

In “From Craft to Curation,” I argued that design value is shifting from execution to direction. Dolphia’s piece is the corollary: you can’t provide direction if you don’t understand what you’re directing.

The data from Lenny’s Newsletter’s AI productivity survey showed PMs ranking prototyping as their #2 use case for AI, ahead of designers. Here’s what that looks like in practice.

Figma is now teaching PMs to build prototypes instead of writing PRDs. Using Figma Make, product managers can go from idea to interactive prototype without waiting on design. Emma Webster writing in Figma’s blog:

By turning early directions into interactive, high-fidelity prototypes, you can more easily explore multiple concepts and take ideas further. Instead of spending time writing documentation that may not capture the nuances of a product, prototypes enable you to show, rather than tell.

The piece walks through how Figma’s own PMs use Make for exploration, validation, and decision-making. One PM prototyped a feature flow and ran five user interviews—all within two days. Another used it to workshop scrolling behavior options that were “almost impossible to describe” in words.

The closing is direct about what this means for roles:

In this new landscape, the PMs who thrive will be those who embrace real-time iteration, moving fluidly across traditional role boundaries.

“Traditional role boundaries” being design’s territory.

This isn’t a threat if designers are already operating upstream—defining what to build, not just how it looks. But if your value proposition is “I make the mockups,” PMs now have tools to do that themselves.

The optimistic case for designers in an AI-driven world is that design becomes strategy—defining what to build, not just how it looks. But are designers actually making that shift?

Noam Segal and Lenny Rachitsky, writing for Lenny’s Newsletter, share results from a survey of 1,750 tech workers. The headline is that AI is “overdelivering”—55% say it exceeded expectations, and most report saving at least half a day per week. But the findings by role tell a different story for designers:

Designers are seeing the fewest benefits. Only 45% report a positive ROI (compared with 78% of founders), and 31% report that AI has fallen below expectations, triple the rate among founders.

Meanwhile, founders are using AI to think—for decision support, product ideation, and strategy. They treat it as a thought partner, not a production tool. And product managers are building prototypes themselves:

Compare prototyping: PMs have it at #2 (19.8%), while designers have it at #4 (13.2%). AI is unlocking skills for PMs outside of their core work, whereas designers aren’t seeing the marginal improvement benefits from AI doing their core work.

The survey found that AI helps designers with work around design—research synthesis, copy, ideation—but visual design ranks #8 at just 3.3%. As Segal puts it:

AI is helping designers with everything around design, but pushing pixels remains stubbornly human.

This is the gap. The strategic future is available, but designers aren’t capturing it at the same rate as other roles. The question is why—and what to do about it.

Previously, I linked to Doug O’Laughlin’s piece arguing that UIs are becoming worthless—that AI agents, not humans, will be the primary consumers of software. It’s a provocative claim, and as a designer, I’ve been chewing on it.

Jeff Veen offers the counterpoint. Veen—a design veteran who cofounded Typekit and led products at Adobe—argues that an agentic future doesn’t diminish design. It clarifies it:

An agentic future elevates design into pure strategy, which is what the best designers have wanted all along. Crafting a great user experience is impossible if the way in which the business expresses its capabilities is muddied, vague or deceptive.

This is a more optimistic take than O’Laughlin’s, but it’s rooted in the same observation: when agents strip applications down to their primitives—APIs, CLI commands, raw capabilities, (plus data structures, I’d argue)—what’s left is the truth of what a business actually does.

Veen’s framing through responsive design is useful. Remember “mobile first”? The constraint of the small screen forced organizations to figure out what actually mattered. Everything else was cruft. Veen again:

We came to realize that responsive design wasn’t just about layouts, it was about forcing organizations to confront what actually mattered.

Agentic workflows do the same thing, but more radically. If your product can only be expressed through its API, there’s no hiding behind a slick dashboard or clever microcopy.

His closing question is great:

If an agent used your product tomorrow, what truths would it uncover about your organization?

For designers, this is the strategic challenge. The interface layer may become ephemeral—generated on the fly, tailored to the user, disposable. But someone still has to define what the product is. That’s design work. It’s just not pixel work.

The rise of micro apps describes what’s happening from the bottom up—regular people building their own tools instead of buying software. But there’s a top-down story too: the structural obsolescence of traditional software companies.

Doug O’Laughlin makes the case using a hardware analogy—the memory hierarchy. AI agents are fast, ephemeral memory (like DRAM), while traditional software companies need to become persistent storage (like NAND, or ROM if you’re old school like me). The implication:

Human-oriented consumption software will likely become obsolete. All horizontal software companies oriented at human-based consumption are obsolete.

That’s a bold claim. O’Laughlin goes further:

Faster workflows, better UIs, and smoother integrations will all become worthless, while persistent information, a la an API, will become extremely valuable.

As a designer, this is where I start paying close attention. The argument is that if AI agents become the primary consumers of software—not humans—then the entire discipline of UI design is in question. O’Laughlin names names:

Figma could be significantly disrupted if UIs, as a concept humans create for other humans, were to disappear.

I’m not ready to declare UIs dead. People still want direct manipulation, visual feedback, and the ability to see what they’re doing. But the shift O’Laughlin describes is real: software’s value is migrating from presentation to data. The interface becomes ephemeral—generated on the fly, tailored to the task—while the source of truth persists.

This is what I was getting at in my HyperCard essay: the tools we build tomorrow won’t look like the apps we buy today. They’ll be temporary, personal, and assembled by AI from underlying APIs and data. The SaaS companies that survive will be the ones who make their data accessible to agents, not the ones with the prettiest dashboards.

Almost a year ago, I linked to Lee Robinson’s essay “Personal Software” and later explored why we need a HyperCard for the AI era. The thesis: people would stop searching the App Store and start building what they need. Disposable tools for personal problems.

That future is arriving. Dominic-Madori Davis, writing for TechCrunch, documents the trend:

It is a new era of app creation that is sometimes called micro apps, personal apps, or fleeting apps because they are intended to be used only by the creator (or the creator plus a select few other people) and only for as long as the creator wants to keep the app. They are not intended for wide distribution or sale.

What I find compelling here is the word “fleeting.” We’ve been conditioned to think of software as permanent infrastructure—something you buy, maintain, and eventually migrate away from. But these micro apps are disposable by design. One founder built a gaming app for his family to play over the holidays, then shut it down when vacation ended. That’s not a failed product. That’s software that did exactly what it needed to do.

Howard University professor Legand L. Burge III frames it well:

It’s similar to how trends on social media appear and then fade away. But now, [it’s] software itself.

The examples in the piece range from practical (an allergy tracker, a parking ticket auto-payer) to whimsical (a “vice tracker” for monitoring weekend hookah consumption). But the one that stuck with me was the software engineer who built his friend a heart palpitation logger so she could show her doctor her symptoms. That’s software as a favor. Software as care.

Christina Melas-Kyriazi from Bain Capital Ventures offers what I think is the most useful framing:

It’s really going to fill the gap between the spreadsheet and a full-fledged product.

This is exactly right. For years, spreadsheets have been the place where non-developers build their own tools—janky, functional, held together with VLOOKUP formulas and conditional formatting. Micro apps are the evolution of that impulse, but with real interfaces and actual logic.

The quality concerns are real—bugs, security flaws, apps that only their creator can debug. But for personal tools that handle personal problems, “good enough for one” is genuinely good enough.

My wife is an obesity medicine and women’s health specialist, so she’s been in my ear talking about ultraprocessed foods for years. That’s why the processed food analogy for AI-generated software resonates. We industrialized agriculture and got abundance, yes—but also obesity, diabetes, and 318 million people still experiencing acute hunger. The problem was never production capacity.

Chris Loy applies this lens to where software is heading:

Industrial systems reliably create economic pressure toward excess, low quality goods. This is not because producers are careless, but because once production is cheap enough, junk is what maximises volume, margin, and reach. The result is not abundance of the best things, but overproduction of the most consumable ones.

Loy introduces the term “disposable software”—software created with no expectation of ownership, maintenance, or long-term understanding. Vibe-coded apps. AI slop. Whatever you want to call it, the economics are different: easy reproducibility means each output has less value, which means volume becomes the only game. Just look in the App Store for any popular category such as todo lists, notetakers, and word puzzles. Or look in r/SaaS and notice the glut of single people building and selling their own products.

Loy goes on to compare this movement with mass-produced fashion as well:

For example, prior to industrialisation, clothing was largely produced by specialised artisans, often coordinated through guilds and manual labour, with resources gathered locally, and the expertise for creating durable fabrics accumulated over years, and frequently passed down in family lines. Industrialisation changed that completely, with raw materials being shipped intercontinentally, fabrics mass produced in factories, clothes assembled by machinery, all leading to today’s world of fast, disposable, exploitative fashion.

Disposable fashion leads to vast overproduction, with estimates that 20–40% (up to 30–60 billion pieces) go unsold. There’s a waste of people’s time, tokens, electricity, and ultimately consumer dollars that AI enables.

The silver lining that Loy observes is in innovation. Entirely human-written code isn’t the answer. It’s doing the necessary research and development to innovate. My take is that’s exactly where designers need to be sitting.