311 posts tagged with “product design”

David Pierce, writing for The Verge, dates the inflection precisely: late 2025, when an update to Claude Code crossed the line from “surprising when it worked” to “surprising when it didn’t.” That’s the moment vibe coding stopped being a demo and started being a tool ordinary people could actually use.

In late 2025, an update to Anthropic’s Claude model turned its Claude Code tool from a code generator that was surprising if it worked to one that was surprising when it didn’t. Suddenly, all you needed was $20 a month and a half-formed idea, and an AI model could build you functional software. If you could explain what wasn’t working, Claude Code could probably fix it. Andrej Karpathy, an educator and researcher who was on OpenAI’s founding team, had called this new behavior “vibe coding.” Suddenly the vibes were off the charts.

The reliability threshold matters more than the headline number. Twenty dollars a month was already true. What changed is that the output stopped breaking when you asked it to do something real. That’s what made the personal software lineage—from HyperCard in 1987 through Lee Robinson’s essay, the home-cooked-app idea, micro-apps, and fleeting apps—turn from a niche aesthetic into something a normal person could actually do over a weekend.

Pierce documents his own version of that weekend: building Timetable, abandoning it, building Spring and forgetting what it did, getting stuck on Twilio bills. The realization that pulls him out of the loop is the one that’s worth dwelling on:

What saved my efforts was the realization that personal software doesn’t have to be built from scratch. Knowledgeable developers might be newly capable home cooks, but the rest of us are more like customers at Chipotle. We don’t make the food, we don’t even really assemble it, but we get to decide what goes where and how it’s served to us. For most of us, the future of software is not building our own Excel from scratch, it’s using the models to build spreadsheets wildly more capable than we could create ourselves. It’s building the Chrome extension for your favorite app that is really only missing a Chrome extension. It’s tweaking the way things look to suit your exact taste and needs.

Most coverage of vibe coding implies the future is everyone becoming a one-person engineering team. Pierce’s actual claim is narrower and more useful: like ordering a Chipotle burrito, you’re picking ingredients and toppings, not running the kitchen. The point is not to replace Notion or Obsidian or Todoist. It’s to bend them an inch closer to how you actually work.

My whole publishing workflow for this blog switched from Payload CMS to a custom admin UI and now a custom Obsidian plugin.

Which brings the conversation to where Pierce lands it: taste.

In this new world, the most important thing you’ll need is taste. Not objectively good taste, necessarily, so much as a keen sense of your own. You need to be like Rick Rubin, the famous music producer, who once told 60 Minutes that what made him successful was not any particular technical ability, but “the confidence I have in my taste, and my ability to express what I feel.” Rubin practices that art with A-list celebrities; you need to be able to do it with AI. Otherwise, you’ll land in what Lovin calls “doom loops,” telling your chatbot only what you don’t like and counting on the model to be the creative one. That way lies madness — and bad software.

Yan Liu’s working definition of taste cites the same Rubin formula—sensitivity times standards—and that’s the part of Pierce’s argument that designers should sit with. The $20 vibe-coder has the tool. What they often don’t have is the trained eye to know when Claude’s purple gradient is wrong, or why the icon looks like a butthole instead of a planner. Pierce learned this the hard way and concluded, sensibly, that he didn’t have opinions about databases but did have opinions about typefaces. That’s the right diagnosis. It also undersells what designers actually do—Raj Nandan Sharma’s warning about taste-as-end-of-pipeline selection is the other half of this. If designers don’t show up as authors here—shaping what gets generated, not just thumbs-upping it after the fact—the personal software era will produce a lot of bespoke purple gradients and not much else.

Gess Puglielli, writing on LinkedIn, argues that the speed of AI interface generation has revealed something other than a new tool. It has revealed that a lot of companies were never working from a real definition of design:

But interfaces were never the real value of design. They were just the artefacts left behind. The output. The visible layer of a much deeper process involving human behaviour, systems thinking, psychology, usability, strategy, communication, emotion, culture and invention. Design was never about moving pixels around a canvas. Design is how humans shape the world around them.

Jakob Nielsen made an adjacent argument about the shift from artifact production to intent shaping. Puglielli is pointing at something sharper. Nielsen describes a shift in what designers do; Puglielli says the shift has exposed a category of companies that mistook the artifact for the work in the first place.

The diagnostic part is what stayed with me:

In many organisations, designers were already being treated like production software long before generative AI arrived. The process often looked something like this: Product defines requirements. Engineering defines constraints. Leadership defines strategy. Then design is invited in to “make it look good.” At that point, the designer has already been removed from the act of designing. They’ve become decorators of predetermined decisions.

This is what makes “AI replaced our designers” make sense inside certain rooms and sound absurd inside others. If your design function had already been narrowed to ticket-taking execution, AI can replicate execution. Karri Saarinen pointed at the same misunderstanding when he wrote that the hard part of design is understanding the problem well enough to know what should exist at all. Puglielli’s contribution is the corollary: the companies that don’t know that won’t notice it’s missing when it gets cut.

Puglielli argues what AI isn’t good at:

AI can generate screens. It cannot independently define meaningful problems worth solving. It cannot deeply understand cultural nuance, emotional context or human contradiction in the way experienced designers can. It cannot navigate organisational politics, align competing stakeholder priorities, recognise ethical implications or identify latent human needs before users themselves can articulate them.

Most importantly, it cannot care. And care matters more than the industry likes to admit.

Care is the right word for designers and a weak word for industry, because businesses don’t pay for care. They pay for the outputs care produces—taste, the ability to see a problem before it’s named, and the thing we call judgment.

The headline says it all: “Uber president says AI spending is getting ‘harder to justify.’”

Jess Weatherbed, writing in The Verge:

After reportedly exhausting its annual AI budget just four months into 2026, Uber is now questioning whether it’s actually seeing meaningful returns on its investments. In an interview with Rapid Response, Uber president and chief operating officer Andrew Macdonald said the company isn’t seeing a connection between rising token consumption for Claude Code and more useful features being delivered to consumers.

“That link is not there yet, right? I think maybe implicitly there is more that is getting shipped, but it’s very hard to draw a line between one of those stats and, ‘Okay, now we’re actually producing 25 percent more useful consumer features,’” said Macdonald. “I think over the coming quarters and years, maybe that will become clearer, but I think today it’s hard, even if some of the underlying metrics are trending in a really astronomical direction.”

Two quick thoughts. First, engineering—and by extension, product and design—velocity gains like 2x, 3x, or 10x show up in the output. They aren’t showing up directly in the outcomes. Getting to a design faster doesn’t mean you designed the right thing.

Second, we haven’t redesigned the factory floor yet. It’s a metaphor I’m borrowing from Tommy Geoco. When factories converted from steam power to electricity in the 1880s, they swapped out the engines and did nothing else. The floor plan and workflow didn’t change. For three decades, output barely moved. Only when companies redesigned their factories and process around the new technology did they see an increase in output.

We haven’t quite figured this out as an industry or discipline yet. As I’ve written previously, it’s foggy but the shape is unmistakable. The answer is out there.

The artifact-to-intent argument has been working its way through design writing for a while now. What Jakob Nielsen adds to it, writing in UX Tigers, is a name for the failure mode that comes with the territory:

We used to accumulate design debt when teams shipped inconsistent components or patched over poor flows. Now we will accumulate intent debt: undocumented assumptions, vague brand guidance, missing escalation rules, untested agent permissions, and research insights that never become usable by the systems doing the work. Intent debt will be harder to see than visual inconsistency, but it will be more damaging because it compounds invisibly through every generated output.

Nielsen’s prior writing on intent-based UX argued that evaluation has become the new bottleneck for the user. A chat completes the task in seconds, and you spend the next half hour checking whether it actually did what you meant. Intent debt extends that bottleneck to the organization. The team ships ten variants in an afternoon, and nobody can tell which ones violated a brand rule that was never written down, or bypassed an escalation path that only lived in a senior designer’s head.

Nielsen puts the failure plainly:

The new danger is that AI will produce many adequate screens that all seem defensible in isolation and incoherent in aggregate. Mediocrity will arrive well-dressed. The designer’s role is to prevent the organization from drowning in plausible options.

Which is why the design system has to grow up:

The design system thus stops being a component library and becomes an operating system for taste. Tokens, components, and usage rules are only the visible layer. Underneath must be a deeper set of instructions about brand behavior, interaction philosophy, accessibility standards, motion logic, content tone, escalation patterns, and product judgment. The system must know not only which button to use, but when not to add a button at all.

Developer Mark Anthony Cianfrani has argued that LLMs finally let us ship the reasoning behind a token alongside the token. Nielsen draws the consequence of skipping that work: a weak design system in the AI era becomes an active liability. Agents will faithfully build with whatever’s encoded, and faithfully invent the rest.

Michael Riddering brings Tommy Geoco on Dive Club fresh off field visits to Vercel, Perplexity, Metalab, Ramp, and Snowflake. Geoco and his team are making a documentary after roughly 200 conversations with designers and design leaders this year. The survey finding he leads with is the one I would have least expected: designers who have moved more of their work into AI-assisted prototyping are also more satisfied with their workflows. The hierarchy of who is actually doing that work is the part worth sitting with:

The number one thing that stood out to me was that designers who are currently vibe coding are more satisfied with their workflows. […] And I did not expect that. […] People seem to dig it in this survey. […] It’s the people who are currently doing the majority of their workflow on vibe coding activities. It’s design engineers. That makes sense. Lead principals. [After that] it’s non-designer roles, which might be students and researchers. Then it’s managers. And then it’s your general junior mid-level IC. And that part was fascinating that managers are doing more than junior and mid-level ICs. Either things are trickling down and people are experimenting and then they’re going to pass learnings down, which is kind of what we’ve seen on location. But it also might mean that like some managers or teams haven’t yet made room for the rest of the team.

Design engineers and leads at the top is unsurprising. Managers above juniors and mid-levels is the inversion, and remains basically unchanged from two years ago when Geoco’s 2024 survey found the same thing.

Leadership-IC Divide. Leaders adopt AI at a higher rate (29.0%) than ICs (19.9%)

So what’s the read? Geoco gives it the generous read first—learnings cascading down—and then concedes the other possibility: some teams haven’t made room for the rest of the team. Riddering puts it more bluntly: “I’m looking at a bunch of junior and mid designers that are getting cut out of the process.”

The other finding is that 59% of designers have built their own tool for their workflow. The example Geoco brings back from Vercel makes the builder-mode shift concrete:

When I went over to Vercel, they had this brand designer, who had never coded before. And now was vibe coding a tool. Their marketing team would put out blog posts. And they were like, “Why does the design team need to create the OG blog post cards for every page? That’s not a good use of [their time].” So he built a tool that just allowed them to insert any sort of images. And it just already had all of the branding and the sizing baked in. And they just roll these [tools] out quickly. And I’m like, that just became a tool, an internal tool. That’s cool. And so because it was really interesting that they started referring to him as a brand engineer… And I’m like, okay, that kind of qualifies it actually.

A designer who had never coded solves an actual marketing-team problem, ships the tool, and the role title arrives after the work. That is how the next batch of “blank engineer” titles is going to land. Riddering then describes how the orchestrator pattern works in his own day-to-day, offering a concrete account of the workflow I have been writing about as orchestration from a working designer:

Part of me is almost slightly self-conscious about it. But I do the vast, vast majority of my messy explorations with AI now. I feel like I have made the jump to the quote unquote creative director where I’m just working with AI to show me a certain thing 50 different ways. And then I’m pulling the pieces that I like and then combining them again. And finally I get to somewhere where I’m like, yep, that’s good. And then I take that from paper, run it through cloud code, and now it exists on localhost. And then I will sweat the details and actually do the precision designing in code, which is, that’s crazy, man. That’s a very, very different workflow than I’ve done at any point in my career.

The orchestrator gap is opening where I thought it would. What I did not account for is who is getting invited into that work first. The data Geoco surfaces points to leads, managers, and design engineers getting more chances to build with AI than junior and mid-level ICs.

Here’s a hypothesis I’ll put out there: leads are more used to directing. I’m personally comfortable with orchestrating, being the editor because I’ve been a creative director and leader for so long. The loop is right there: frame, review, direct.

Last week I linked Ravi Mehta on the three layers of context engineering for AI prototyping: functional spec, visual wireframe, structured data. Karo Zieminski, an AI PM writing Product with Attitude, makes the same case at the product scale and cites Mehta directly. Mehta wrote about prototyping one screen; Zieminski writes about designing the whole product around an agent.

Zieminski puts it in one line:

Prompt engineering is deciding what and how to ask the model. Context engineering is deciding what the model knows when it answers.

Then the asymmetry:

A well-crafted prompt in a poorly engineered context still fails. A poorly crafted prompt in a well-engineered context often succeeds.

That asymmetry is the argument for treating context as the underlying system.

If that asymmetry is real—and a year of using these tools tells me it is—then most teams are still optimizing the wrong layer. The visible artifact is the prompt. The work that actually decides the output is everything around it.

The piece I want to underline is who owns the work:

PMs define what goes in each context layer. Engineers build the infrastructure to fetch and store it… If the PM isn’t doing this, one of two things happens. Either an engineer makes the product decision by default, or nobody makes it and the agent gets every available signal dumped into the window.

Zieminski calls the alternative abdication. I think she’s right and I also think most PM job descriptions in 2026 haven’t caught up. The hiring filter still selects for ticket-shaping and roadmap maintenance, not for “decide what the model should know about the user, what should age out, what should never get re-fetched.” Those are product decisions about how memory is organized, and the people best positioned to make them—PMs who understand the product and the user—are often the ones least equipped to talk about retrieval and eviction. The gap is one of vocabulary and authority.

Both write for PMs, but the work is also design work. The context an agent sees is a designed surface: what gets included, what gets hidden, what should age out, what should persist between sessions. Mehta’s three-layer brief—spec, wireframe, JSON, twenty minutes in Figma, real data—is daily prototyping for designers working with agents now. Zieminski’s architecture is the system those prototypes live inside. If designers don’t show up here, PMs and engineers will design this surface for us.

My terminal setup these days is cmux layered on top of Ghostty, so I can run multiple workspaces side by side without losing my place. Most of my actual work happens there now, as the primary surface.

MC Dean spent real time building UIs for her designpowers agents, looked at what she’d made, and tore them down:

I’d taken something that was direct, alive in a particular way, that would show you its thinking if you let it, and I’d dressed it up. Made it presentable. Wrapped its reasoning inside a crisp ui. In doing that I’d introduced distance between the person using it and the thing they were actually talking to and trying to collaborate with. I’d made it more comfortable, predictable and less true. I killed the delight of using designpowers.

Dean on why she killed it:

The GUI was scaffolding. Brilliant, necessary, world-changing as an innovation, but nonetheless created around a fundamental limitation so invisibly useful that we forgot what it was for.

The scaffolding was for humans who couldn’t speak the machine’s language. When the machine starts speaking ours—even partially, even just inside certain conversations—the scaffolding becomes friction for anyone trying to learn how the underlying system actually thinks.

Dean then connects this back to design craft, instead of letting it become a “designers should learn the terminal” finger-wag:

Designers are really good at this important way of thinking already. Every time you decided how an error message should make a person feel. Every time you chose what to surface and what to hide. Every time you designed for the person who didn’t fit the assumed user, you were encoding values into a system. That work doesn’t go away when the interface does. It moves upstream, into the reasoning layer itself, and it has no canvas. That’s design literacy for the world that’s coming.

Dean’s argument pairs with the other end of the same expansion: designers gaining authorship downstream in the code. The easing curve and the hover state at one end; what the agent gets to surface and who counts as the assumed user at the other. The reasoning layer is the upstream end without a canvas to hide behind.

Nick Babich asks if the old surface still earns its place. Dean is pointing at where the new surface already is.

Dean closes with:

We are early enough that the agents are still legible. You can still watch one think. You can still feel the shape of how it reasons before it’s been wrapped in chrome and shipped with a logo.

That window is why I bother with cmux at all. Ghostty by itself is already a genuine pleasure to use; cmux lets me keep a Claude Code session running per project without losing context when I switch. Just enough plumbing to make watching agents think a habit rather than a stunt. Dean’s right that the legibility won’t last. Worth being here while it does.

Nick Babich, writing in UX Planet, takes inventory of where Figma still earns its place once teams stop treating the mockup as the deliverable:

One thing is clear: the conventional process in which UI and UX designers spend hours and days pushing pixels to create perfect layouts is no longer the reality for many organizations. The reason is simple: in the AI era, time-to-market has become a critical metric, and most companies would rather ship a “good enough” product quickly than spend extra time perfecting every detail.

The concept of Figma as a design tool originated from the conventional design process. You could say that Figma is an almost perfect design companion for designers who follow a traditional UI/UX workflow.

But the problem is that the conventional design process is no longer the reality for most organizations.

Organizations that embrace rapid prototyping are switching to tools that allow them to build and ship quickly. Instead of starting with static UI mockups in Figma, they jump straight into the prototyping phase using tools like Claude Code. In this phase, teams create coded prototypes that later evolve into fully functional products.

Figma’s role is narrowing from everything-tool to exploration-and-iteration tool, and narrowing is not the same as dying. Babich is now drawing the lines around what that specialized future actually looks like: design systems (especially the ones already living in Figma), complex enterprise workflows with real business logic, and the brand and visual-identity work where taste is the whole point.

On Figma Make, Babich is blunt:

But the problem is that Figma Make is still nowhere near tools like Codex or Claude Code in terms of output quality and overall user experience. Claude Code and Codex are significantly more capable, flexible, and comfortable for rapid product development workflows. Even for simple tasks like creating a prototype of design imported from Figma, Make tends to add a lot of visual defects.

I scored Figma Make 58 out of 100 at launch. It has improved since, but Babich is right about the gap. Make is competing against tools that were born for code generation against a working repo; Make was retrofitted onto a vector editor. That difference shows up in every prototype that looks fine until you zoom in.

On design systems, Babich:

In other words, you don’t necessarily need to maintain your design system in Figma; as long as you can provide access to a GitHub repository containing your design system, you’re in a good position to generate consistent interfaces.

If the design system can live in the repo and the agent can read it directly, the Figma library becomes a mirror rather than the source. That doesn’t kill the Figma file. It does change who has to maintain it and why.

Nearly nine in ten organizations now use AI in at least one business function. Ninety-four percent aren’t seeing significant value from it. Gale Robins, writing for UX Collective, argues that the gap is a framing problem, not an adoption problem. Her earlier piece on discovery judgment made the same case; the new one sharpens it with an anecdote that shows the trap:

A team I spoke with recently had compressed their discovery cycle from six weeks to ten days using AI. They were proud, and the throughput was real. When I asked what the work had taught them that they did not already believe, the answer was: not much. Same questions, faster. Same answers, sooner.

Same questions, faster. Same answers, sooner. Her analogy for the wider pattern is the electric factory one I’ve used before:

When factories first installed electricity, productivity barely moved. Manufacturers replaced steam engines with electric motors and kept the line-shaft layout. The breakthrough came later, when they redesigned the factory around what electricity made possible. The technology was only part of the answer.

Robins maps McKinsey’s three waves of AI value—productivity, differentiation, transaction-cost reduction—and finds most teams stuck in the first one. Robins on where they have to go to get out:

These decisions are upstream of every artifact a team produces. They are also where AI productivity gains help least, and where human judgment compounds the most.

Robins’s evidence undersells her own thesis. She leans on Generative AI at Work—the Stanford-and-MIT customer-support study by economists Erik Brynjolfsson, Danielle Li, and Lindsey Raymond that became the canonical citation for “AI helps novices most”—to argue AI raises the floor, not the ceiling. Novices gained 34%; experienced workers, basically zero. That’s why so many designers who have never coded—like me—are now suddenly shipping with this newfound superpower. It’s the same finding behind the junior designer crisis. But LinkedIn’s Full Stack Builder rollout found the opposite: top performers adopted AI fastest and got the most out of it, because they had the judgment to know what to ask for. The floor-not-ceiling story is only true where the questions are fixed. Once the questions are the work, the pattern inverts. That’s exactly the territory Robins is mapping. If AI rewards the experienced most when the work is judgment-shaped, framing is where the gap between teams widens.

Brandon Harwood opens with Picasso’s Guernica. He asks you to look at the painting, then tells you the story behind it—the bombing of the Basque town, the civilian deaths, Picasso’s intention to communicate that horror—and asks you to look again.

If you didn’t know the story of this painting beforehand, now you do, and it might strike a different chord, if just slightly. The details of the painting now have the context that shows us what Picasso was thinking when he painted Guernica. […] It’s this kind of context that drives meaning in art. Guernica is not just a painting. It’s communication.

Harwood uses it to draw a line between what AI can generate (the aesthetics of a thing) and what humans build (the context that makes a thing communicate). His answer: instead of asking AI to make meaning, design around the fact that it can’t.

Meaning Machines are, at their core, “signifiers, randomized into a fixed grammar, and read for new meaning.” […] The randomized signifiers are the contextual data surrounding our creative pursuit, the data the AI is trained on, and the relationships built on that data through its training. These signifiers, the data, are then placed into a fixed grammar through agentive interaction and/or agentic actions, and the user can then interpret the result to stimulate their creativity, build new meaning, or explore ideas they might not have considered before.

Tarot doesn’t know what your week looks like. Oblique Strategies doesn’t know what song you’re stuck on. The cards work because they hand you raw material and you do the interpretation. Harwood’s claim is that an LLM, used right, can sit in that same chair. Provoke the human. Dr. Maya Ackerman calls this same arrangement “humble creative machines”: the AI is not the creator, it’s the prompt the creator responds to.

Harwood breaks co-creative AI into three roles:

The Puller: The AI system gathers information about the context the user is working in through active question generation and passive information collection on the works. […] The Pusher: The AI system uses some/none of this context to synthesize considerations for the user to employ throughout their creative journey. […] The Producer: The AI system creates artifacts for use as elements of the users’ larger creative output.

The Puller / Pusher / Producer vocabulary is what I wish more design teams had before they shipped their first AI feature. Each role is a constraint, a way to keep the human in the chair the work actually belongs in. Most AI tools for creatives flatten all three into one button that produces a finished thing. Harwood’s whole argument is that the finished thing is where the meaning has to originate; it can’t be the destination.

When I wrote about the forward-deployed designer squad model earlier this year, I was working from the outside in: what the model should look like, who it serves, why it matters. Ron Bronson ran it for four years as director of a 40-person design division at 18F, the now-defunct US government’s in-house digital services agency. His post is the inside view and he diagnoses why most orgs never get there:

The real reasons that design roles aren’t being considered for this is the ways orgs constrain how designers show up on cross-functional teams. If your designers are only good for handoffs, you’re not going to invest in the headcount.

The people are the key, but you have to be opinionated about what you’re looking for your designers to do. If you’re looking for pixel-perfect, portfolio polish then you’re doing it wrong. Due to the quirks of federal hiring rules, we weren’t allowed to consider portfolios. It didn’t mean we couldn’t look at them, they just couldn’t be part of the criteria someone got an offer or not.

Take the portfolio rule: federal hiring restrictions sound like the kind of constraint that makes a practice worse, and instead they forced 18F to evaluate designers on the things that actually predict forward-deployed performance—ambiguity tolerance, collaboration, low ego, willingness to work in the open. The portfolio gauntlet that dominates tech-industry design hiring optimizes for the opposite skill: producing pixel-perfect artifacts in isolation. Bronson’s team got better signal because they were prevented from looking at the worse one.

Bronson on the multidisciplinary bar:

hired designers who can do more than one thing. Some impressive UX researchers would show up on our doorstep often, and if they talked to me, I’d be very direct with them about how we worked and that our designers often had to wear more than one hat out of necessity. The other constraint? Headcount. Design often has to justify itself more than other practices, so we couldn’t afford people who were too “special” to be staffed to a broad array of partner engagements. What this meant in practice? Designers who could code, researchers with content strategy & information architecture chops, service designers who could lead and/or PM projects, and every designer being a strategist on some level.

Generalist breadth in this context is a structural requirement of the engagement. That’s what Bronson means by “wear more than one hat out of necessity.” You can’t deploy a specialist into a six-week problem-scoping sprint and expect them to be useful for more than one week of it.

Bronson on where designers should sit:

As I explained in Design as Repair at IxDA Oslo last September: we need designers embedded where problems happened, not downstream after it’s been scoped, broken and all the framing has been done and asked to execute.

Most design orgs are structurally downstream: invited in after PM and engineering have already decided what’s being built, given a brief that pre-resolves the questions design should be asking. Bronson’s 18F was built to refuse that posture by default, which is why the model worked there before it had a name.

Luke Wroblewski shared his notes from the Design Futures Assembly, a gathering of about a hundred senior designers and leaders from AI labs, big tech, and startups in San Francisco:

When everyone can ship, you get a different kind of problem. One design leader described it perfectly: they let everyone build and push whatever they wanted. And you could feel it in the product, because nothing made sense together.

This is the part of the AI-in-design story that the toolkit numbers obscure. Wroblewski reports roughly half of designers had shipped AI-generated code to production this year, and that the typical designer’s toolkit had doubled in size over twelve months. Those are real numbers. But once production stops being the bottleneck, the bottleneck moves. A single word surfaced repeatedly:

Several people at the assembly used the word “editorial” to describe where design leadership is heading. Less about making the thing, more about deciding what gets made and ensuring it all holds together. The skill of saying no is becoming one of the most important skills in the profession.

The “saying no” line echoes something Chad Johnson wrote a few weeks back: the designers who shape direction “learn to say no with evidence and to disagree without drama.” The Assembly’s framing makes that posture mandatory at a portfolio level, not just on individual features. One tool company founder, Wroblewski notes, preferred “coherence”: the sense that a product came from one shared point of view. I like that word better too. Coherence describes the thing the user actually feels.

Taras Bakusevych closes his walkthrough of ten dying UI patterns on the heuristic that matters:

Execution UI: Interfaces that help humans perform deterministic work — entering data, configuring rules, following process steps, executing repetitive operations. 🟠 Shrinking. As AI automates execution, these surfaces lose their reason to exist.

Judgment UI: Interfaces that help humans evaluate, guide, and correct work done by machines — reviewing outputs, verifying changes, understanding reasoning, intervening at exceptions. 🟢 Growing. As AI takes on more autonomous work, humans need better surfaces to supervise it.

The supervision problem is what Jakob Nielsen called evaluability—the new central UX metric—and Bakusevych is doing the screen-by-screen translation. Every pattern in his list gets re-examined under one question: is this surface helping the human do the work, or helping the human check the work?

The HubSpot quote flow makes the friction concrete:

Creating a single sales quote in HubSpot requires navigating seven sequential screens. The rep manually selects the contact, adds company details, configures line items, chooses signature options, sets payment terms, picks a template, and previews the result — before a single quote reaches the buyer. Each step assumes the system doesn’t know information it already has in the CRM.

Bakusevych’s replacement gives the rep a different role: review what Shopify Sidekick assembled, correct what’s wrong, ship.

That’s the test he leaves you with. Open one screen in your product and ask which job it’s doing. If it’s interrogating the user for context the system could have inferred, it’s on the shrinking side.

Nathan Beck, a product designer in Amsterdam, opens his essay with the title “The death of design” and an immediate retraction: “LOL only jk design still alive.” Then he spends a few thousand words on why, walking through what AI tools actually do to a working designer’s day and what they conspicuously do not do.

The pivot quote is buried two-thirds in:

If you call yourself a designer and—be honest with yourself—the bulk of your role has been the production of flat pictures of user interfaces, then I’m sorry to break it to you, but you are not designing. You are styling.

That line is the whole post compressed. Beck is not arguing that AI threatens designers. He is arguing that AI threatens styling, and that a lot of people who call themselves designers have been styling for a decade and are now discovering that the part of the job AI is good at was the part they were doing.

What’s left over, in Beck’s telling, is the reflective work: the thing that happens during design, not in the final file. He quotes Kaari Saarinen on output isn’t design:

In the same way that one writes in order to understand what one is writing, one designs in order to understand what one is designing. As Kaari Saarinen explains, “Working visually keeps me close to the problem and is slow enough [sic] gives me time to think while I work. Moving things around, testing relationships, and refining structure is not separate from the thinking. It is part of how clarity emerges.”

This is the part the “designers are cooked” discourse misses. The understanding accumulated while making the Figma file was the asset all along. The file was the receipt.

Beck has a second argument running underneath the first: AI output, on its own, is aesthetically average. He quotes Nick Foster’s Dezeen piece on what software feels like after a decade of optimization:

The apps I use to hire plumbers look and feel remarkably similar to those I use to watch skiers do backflips. Every brand feels the same, every function feels the same, every interaction feels optimised, streamlined and joyless. By any measure, these pieces of software are miracles of engineering and triumphs of logic, yet they feel profoundly underwhelming to live with.

A designer who only ever produced flat pictures of those interfaces has been replaceable by a model for a while now. The judgment about which of those generic outputs should ship and which should be thrown out and rebuilt is the part no model has managed yet.

Beck closes:

However, I am cautiously optimistic that as we weather this historical conjuncture, and machine intelligence loses its sparkly aura, and weekend vibe coders increasingly learn how substantial the gap is between a prototype and a product, the role of design, however it is redefined, will be just as essential as it ever was.

That unsexy gap is the whole game. Greg Kozakiewicz updated the old construction line: we used to confuse the drawing with the building; now we confuse the prototype with the product. The demo works on a good laptop with someone who knows what the app is supposed to do. The product has to work for the user who doesn’t. Closing that gap is the orchestration job—defining the thresholds and deciding what the system should refuse to do—and when the weekend demos lose their shine.

Scott Berkun lists three portable superpowers most designers underrate in themselves: investigative curiosity, the ability to translate between people who can’t understand each other, and a working grasp of tradeoffs. The first one is where he starts:

If we can spend hours reading about the 16th-century French history behind the beloved font Garamond, or studying the details of the design prototypes Jonathan Ives made to create the first iPhone, we have the rare capacity to discover and digest layers of complex information for practical use in solving problems.

Designers tend to file “I went deep on Garamond’s history” as a hobby or a tic, not a transferable skill. Berkun’s point is that the depth is the skill, and the subject is interchangeable. Aim it at a thing your CEO is worried about and you’re suddenly the person who knows the most about it in the room.

On translation:

Someone who explains things clearly, including through insightful sketches, diagrams, or metaphors, has tremendous value. Explainers help people make sense of each other. Designers are often shy about their ability to explain things, but typically we’re better at this than other professionals, since our work is rooted in communication (even visual design is rooted in semiotics, the study of symbols and their meaning). If we can be curious about our coworkers’ perspectives, objectives, and frustrations, we can be translators.

Berkun has made the curiosity argument before, in the negative, when he listed lack of curiosity as one of the five worst habits a designer can have. Reading this piece next to that one, the two halves connect: the habit he warns against in one post is the superpower he’s asking us to revive in this one.

Talking to Peter Yang, Ravi Mehta—former CPO of Tinder, now teaching AI prototyping at Reforge—walks through a live demo of building the same Spotify-style genre page three different ways. The first attempt uses a short functional prompt and produces something that, in Mehta’s words, kind of feels like AI slop. The third uses what he calls a full-stack context bundle: a functional spec, a 20-minute Figma wireframe, and a JSON file of real album data pulled together in Claude with an MCP server. The output is night and day.

His definition of the shift:

Context engineering is designing and building systems that provide an AI model with the right information and tools to accomplish the task. And I think a lot of the common mistake I see with prototyping is people don’t think about context within that 360 degree way. And as a result, people just, you know, write a quick prompt or a quick little mini spec and expect the prototype tool to be able to create something as high fidelity as what they used to create before when they had all of these different artifacts that are a critical part of the product lifecycle.

That definition will sound familiar to anyone who saw Philipp Schmid’s framing of context engineering when it first circulated. Same emphasis on “right information and tools.” It’s the working definition the field has settled on. What Mehta adds is the concrete answer to “okay, what are the three things you actually have to assemble?” Functional context (a spec), visual context (a wireframe), and data context (real structured JSON, not lorem ipsum). Skip any of them and the prototype either looks generic, behaves wrong at edge cases, or breaks suspension of disbelief the moment a real customer touches it.

The piece I want to underline is his defense of visual thinking, because the “designers are obsolete” takes haven’t stopped, and Mehta gives them a clean rebuttal:

So if you start to think differently about the different types of context that are available, you can actually get much more specific and have a lot more control over what gets built and build something that’s a lot more robust. This is functional context. The next level that is really important is visual context. […] And so here, I very quickly in Figma, just taking 20 minutes, done a wireframe, and sort of outlined what I want this interface to look like. […] The prototype needs to have a level of fidelity that’s hard to get with sort of traditional prompting techniques.

Twenty minutes in Figma, then a short prompt that says “use the attached wireframe.” A wireframe does what a 17-page PRD and three rounds of trying to describe a layout in English to the model can’t. The wireframe is part of the input to the deliverable now.

The corollary cuts the other way too. If the wireframe is now an AI briefing document, the people who can produce a decent one in twenty minutes have a real edge over the people who can’t. That’s still designers, still us. It’s just that the wireframe now feeds the model directly, not only the engineer reading the spec next sprint.

In product orgs, the word “autonomy” tends to get attached to seniority and titles. Sara Paul, writing for Nielsen Norman Group, puts the bar somewhere else:

Our research shows that autonomy is about becoming sufficiently informed to credibly shape shared product decisions.

You’ve earned design autonomy when you’ve collected enough context to make a recommendation that holds up under scrutiny. Until then, you haven’t. Low-autonomy designers, in Paul’s terms, “execute predefined solutions.” High-autonomy designers shape what gets prioritized, because they know things their stakeholders don’t.

The four-part pipeline is the practitioner half:

The designers who achieved high autonomy kept information flowing to them from all sources within their organization. Their pipelines consisted of four parts: (1) Gathering information from across teams and channels, (2) Building relationships with people who provide information, (3) Creating crossfunctional spaces for information to be shared, (4) Synthesizing information to form a “big picture” of context that empowered credible recommendations.

Paul’s examples are specific enough to put to use. The opening one is a lead designer at an online review platform whose ad-setup experience lived across mobile, desktop, and web. Three teams owned different parts of the experience and the whole was nobody’s job. Here’s how the story ends:

She saw the problem, took the initiative to gather the information she needed, and synthesized it into a recommendation that boosted her influence over what got built. This is design autonomy.

None of this required a new title. It required a tracker, a few standing meetings, and the willingness to do the synthesis work nobody assigned.

The designers I want—and have—on my team are the ones who can fill in for a PM when they’re on vacation. Paul’s article is the mechanism for getting there. The PM-shaped skill is holding the information context that lets you make a defensible call.

Alex Dapunt, VP Design and Brand at Moonfare, opens with a research session in which a senior client laid out exactly what to build next, with the roadmap, rationale, and feature list ready inside a minute. The client was wrong, Dapunt writes, but not because he was stupid. He was wrong because he had been asked the wrong question and his instinct was to answer it anyway.

The smarter your users, the more convincing their wrong answers. A user says they want ice cream. While they say they want ice cream, what they need is to cool down. Their body wants sugar. It’s hot. There’s a memory somewhere in there, a summer ritual, something cold in their hand. The want closes off options. The need opens them. Take “I want ice cream” at face value and you sell them ice cream. Understand the need and you can sell them a popsicle, a cold drink, air conditioning, a swim in the sea.

The want-versus-need split is older than this piece. Dapunt credits Jared Spool for it. The part Dapunt adds is about who tends to give you the worst version of a want. He argues the failure intensifies in premium and B2B contexts, where the people you most want to talk to are the people most trained to produce confident answers under pressure.

The Moonfare client wasn’t an outlier. I think a lot about why this happens. Part of the answer, I think, is that the people we were interviewing had been trained, explicitly, to produce answers. At Bain, where I spent time earlier in my career, the core discipline is what’s called the answer-first approach, or the A1. You lead with the answer. Then you work backwards. […] It’s a disastrous way to sit in a research session as a user. An executive trained that way walks in and the instinct takes over. They feel the absence of an answer as pressure. They want to be useful. They want to look smart. They give you the A1, and it’s precise and articulate because producing precise articulate answers is what they are paid to do.

Dapunt’s observation about ambiguity is worth carrying into the next interview transcript you read. When a regular user says “I dunno, maybe?” he argues, the fuzziness is signal that the question is wrong. The executive doesn’t give you that signal, so you have to know to discount the clarity.

Dapunt then turns the same lens on metrics. His version of the metrics-as-avoidance failure mode is more specific: the wrong moment, not just the wrong number.

At Moonfare we tracked logins. More logins looks good on a dashboard. Looks like engagement. But private equity is a 5-to-10 year product. For most of that time nothing is supposed to happen. […] The right moment isn’t a platform question. It’s a life question. When does this person have cashflow? When’s bonus season? What does their portfolio look like right now, and is there a product we offer that fits the gap? The real need isn’t log in more. It’s be present when a decision is being made. Five well-timed touchpoints in a year beat fifty random ones.

The piece closes on the part of research practice that gets least attention.

Research is intake. You take it in. You synthesise. Then someone has to make the call and own it. […] In practice I’ve watched it produce three biases averaged into a consensus nobody owns. Someone has to own the interpretation. It can be a researcher, a designer, a founder, a PM. But it’s one person’s job, and it comes with the accountability for the call that follows. The alternative is research-as-stalling.

Dapunt is careful here. He likes continuous discovery, he likes the product trio in theory, and he is not making a contrarian case against any of it. His point is narrower. A team can run all the right research rituals and still end up with a process whose actual function is to ensure no single person has to take responsibility for being wrong.

Nick Babich on agents in UX Planet. A useful pair to his earlier writeup on Claude skills, since the two words get used interchangeably and they are not the same thing. Babich opens with the plain-language version:

Think of an AI agent as a program you run when you need to solve a particular problem in design. For example, you can create an AI agent that helps you with usability testing, code review, UI/UX audit, etc.

A program you run is the right mental model. A skill, the way Babich described it in his earlier piece, is a recipe: a markdown file Claude reaches for when a task matches. An agent is what runs once Claude has the recipe in hand. It carries state across steps, picks tools, reports back.

Babich’s four attributes of a well-designed agent get at that distinction without saying it out loud:

1. Good clarity (intent alignment). A strong agent understands what success looks like, not just the task. This understanding helps it translate vague prompts into clear objectives.
2. Context awareness. Good agents maintain and use context effectively. Not only do they remember previous steps, constraints, and user preferences (which is well-expected behavior nowadays), but they also adapt output based on the environment (tools, data, stage of workflow).
3. Tool orchestration. Agents can perform the workflow autonomously and they have the ability to use the right tools for a task at hand is what makes an agent so powerful. Well-crafted agents can chain tools together into workflows, and they don’t overuse tools when simple reasoning is enough.
4. Explainability (transparent reasoning). When you interact with an AI agent, you need to understand why something happened. Thus, an AI agent should provide a rationale behind decisions surface assumptions, and trade-offs.

Context awareness and tool orchestration are what separate an agent from a prompt template. A skill can ship intent alignment and explainability in plain markdown, but state across steps and the ability to chain tools require a runtime. That’s why Babich’s specs include Boundaries sections and “When Not To Use It” blocks: a stateful, tool-using program needs guardrails that a one-shot prompt does not.

If you haven’t built one yet, his five specs—Research Synthesizer, Competitor Intelligence, Problem Definition, Idea Generation, UX Flow Designer—are a clean starter pack. Pick the one closest to a workflow you already do by hand, and notice how much of the spec is about what the agent will not do.

Tommy Geoco’s $13,100 OpenClaw harness, ninety days in, is one way to build a personal AI agent. Anton Sten went the other way. He tried OpenClaw and Hermes, found the setup was “days, sometimes weeks, for minutes of return,” and built something smaller. Five Claude Code instances on a Mac mini, named after Suits characters, each handling one role. Architecture is a shared repo and a pile of markdown files. That’s it. Most AI-agent posts pitch what Sten calls “a team of bots that runs your business while you sleep.” His basement firm is the inversion.

Sten on what he actually wanted from his agents:

What I actually wanted was smaller. A handful of tools, each with a narrow job, that I could build in an afternoon and shape around how I actually work. So that’s what I did.

The names of his AI agents are from the show Suits (with Wendy borrowed from Billions), picked so the show’s personalities double as memory aids for each agent’s job. Harvey handles contracts and pricing. Donna takes Harvey’s notes and drafts the emails and follow-ups. Mike stores what Sten would otherwise forget. Louis worries about money. Wendy reads the others’ logs and points out where they’re slipping.

Sten on the autonomous-revenue pitch:

The team in my basement isn’t running anything autonomously. They don’t make decisions for me. If I unplugged the Mac mini tomorrow, my business would keep running. The conflation in the current AI conversation — between playing and building a thing that prints money — is the part I find a bit tiring. They’re treated as the same activity, when they’re almost opposites.

Sten’s right that the autonomous-revenue pitch is a fantasy. Less right on the binary that follows. Geoco’s harness is doing meeting prep, ingesting his survey research, and distributing his content across ten platforms while he sleeps. That counts as “running while you sleep,” and his $50,000 in sponsorship revenue from one survey project isn’t trivial. Play and revenue can sit on the same side. What matters is whether the human stays in the loop. Geoco does, and so does Sten.

The shape of what they’re building is also the same. The Harvey-to-Donna handoff Sten uses most and Geoco’s survey-prep loop are both the specialization-is-the-whole-game pattern: narrow specialists, human in the loop, work compounding into the system. Sten calls it play and Geoco calls it work. The architecture underneath does the same job either way.

Sten on practice:

I’d argue this is the business case for designers right now. Not the agents specifically — the playing. Because in a year or two, every job worth having is going to assume you understand how these tools work, and the only way to understand them is to spend time in them when nothing’s on the line.

The people who’ll do interesting work with this stuff in two years are the ones playing with it badly today.

Geoco is what Sten’s last sentence predicts. The person playing badly today is the person doing interesting work in two years. Sten describes that person as hypothetical. Geoco isn’t.

Tommy Geoco spent ninety days and $13,100 tinkering with OpenClaw. His agent runs his capture loop, prepares his meetings, codes the survey for the state-of-prototyping report his studio shipped, and distributes his content across ten platforms. Tom describes the harness like this:

When you install OpenClaw, it is like a starter kit project car. It is a car frame with a swappable engine. The engine being any AI model you choose to use. It is basically a folder that you install onto your computer that contains about seven markdown files. […] When you stop thinking of a custom agent as just a chatbot and start thinking of it like an operating system, some useful questions are going to start to pop up like where does the memory live? What is the source of truth? How do I enforce my rules better? What should stay manual?

The seven files are plain text. soul.md holds the agent’s voice and judgment, agents.md defines permissions, memory.md handles long-term recall, and four others cover identity, the user, tool instructions, and a heartbeat. Tom layers an Obsidian vault on top as long-term knowledge and Slack as the chat surface. Tom on what actually limits an agent:

The agent’s limitations aren’t just about the model. They’re a lot more about the system that you have built around it because you can’t control the quality of the model, but you can control the quality of the system. […] The most important part of my setup is the knowledge vault. This is my alternate memory, and it is built around the work that I actually do.

Geoco says curation is what keeps the whole thing from drifting. The agent runs the loops on top of a vault Geoco curates, and the taste lives with him; the model itself is interchangeable. The challenging part is somewhere else entirely:

The most challenging part of this whole thing is the unlearning. Many of us have old habits that have calcified into our brain. It is why my 17-year-old is able to run laps around us. He has no baggage about how things are supposed to work.

Geoco is right that the unlearning is where the difficulty lives. The harness is just markdown and the model is rented; the orchestration skill Benhur Senabathi described as what designers actually picked up in 2025 is what you practice through the unlearning. Geoco closes the video by saying nobody’s harness is right and everybody’s works for them, which sounds about right to me too.

Jake Albaugh wrote a piece on X called “Design is the work” that splits design from the artifacts it produces. Mocks, prototypes, screens, guidelines: those are outputs. Design itself, in his telling, is the upstream act of intent: figuring out what something should be and why, before anyone makes it. Bingo. That distinction matters now because AI is very good at the artifact and unable to do the deciding:

AI cannot do that part. You intend to do something that has not yet happened. You have to bring those parameters to the table to do anything novel. AI doesn’t know your constraints. It doesn’t know your strategy. It doesn’t know what moment in the market you’re in, what your team is trying to prove, or what your customers actually need versus what they’ve said they want. The expectation — the definition of what good looks like — is something only you can provide. AI’s job is to meet that expectation. Not to define it.

The piece made the case that intentionality has to come before execution and that AI changes neither requirement. The closer is where it gets interesting. After all that, Albaugh tells the reader he used AI to draft the essay:

It may surprise you to learn that I used AI to write this. The structure, the sentences, a lot of the phrasing — generated. But the argument existed before any of it. I knew what I was trying to say. I knew what examples mattered and which ones were wrong. I knew when a paragraph was close but not quite right, and I revised toward a target I’d already defined. […] That’s the point. The tools changed. The work didn’t. Design is the process. Design is the intentionality.

It’s a risky reveal. Most readers will read it as self-undermining at first. But the argument and the artifact are doing the same job: Albaugh had a target, and he used AI to reach it. The fact that the prose was generated is exactly why it matters that the argument wasn’t. He knew which examples belonged in the piece and which ones to throw out. The model couldn’t have known that either way, because the criteria for “good” didn’t exist anywhere outside his head until he wrote them down.

Karri Saarinen made a version of this same split when he argued that output isn’t design. The hard part is understanding the problem well enough to know what should exist at all.

Cat Wu, Anthropic’s Head of Product for Claude Code, describes the hiring filter on her team in her interview with Lenny Rachitsky:

I think all of the roles are merging. PMs are doing some engineering work. Engineers are doing PM work. Designers are PMing and also landing code. You can either hire a lot more engineers who have great product taste, or you can keep your engineering hiring the same and hire a lot more PMs to help guide some of their work. On our team, we’re pretty focused on hiring engineers with great product taste. This way we can reduce the amount of overhead for shipping any product. Like there are many engineers on our team who are fully able to end to end go from see user feedback on Twitter through to like ship a product at the end of the week with almost no product involvement. And this, I think, is actually like the most efficient way to ship something. So I think like engineer and PM are kind of overlapping and you will get a lot of benefit from having more of either. I think product taste is still a very rare skill to have and we’ll pretty much hire anyone who we feel has demonstrated this strongly.

This is what the Full Stack Builder pattern looks like as a hiring filter. The headline is the merging of roles. Wu’s own background says where the bench comes from:

Yeah, I was an engineer for many years. I was then a VC very briefly before joining Anthropic. And actually almost all the PMs on our team have either been engineers or ship code here on Claude Code. And so that’s one of the things that I think helps build trust with the team and also just enables us to move a lot faster. And then actually our designers also have been front-end engineers before.

So to be clear, Wu doesn’t say that the roles have merged, but what she’s describing is the continued blurring of lines.

Maggie Appleton, staff research engineer at GitHub Next, wrote up her recent talk on agentic AI productivity. (Video here if you’d rather watch.) Her central claim comes early:

I call it this “one man, a two dozen claudes” theory of the future. The pitch here is that one person with a fleet of agents will do the work of an entire team of developers. The main problem with this dream is it assumes software is made by one person. All these tools are single player interfaces. […] Software is not made by one person in a vacuum. It’s a team sport. Everyone building it needs to agree on what they’re building and why.

The single-player critique is the missing piece in most AI productivity takes. Most demos of a coding agent show one engineer at a terminal. Designers face the same situation with AI prompt-to-code tools. Collaborating isn’t as easy as sharing a Figma link. That’s the actual gap in current tooling, and it’s downstream of the single-player assumption.

Appleton’s second move:

Implementation is rapidly becoming a solved problem, right? Writing code is now fast, it’s getting cheap, and quality is going up and to the right. The hard question is no longer how to build it. It’s should we build it. Agreeing on what to build is the new bottleneck. […] When production is cheap, opportunity cost becomes the real cost. You can’t build everything, and whatever you pick comes at the cost of everything else.

When production is cheap, picking what to make becomes the whole job. The cost difference between two engineering paths is now nearly zero, so the choice between them carries all the weight. Teams that miss this will end up shipping volume and mistaking it for productivity.

A talk like this could be about tooling, and Appleton does walk through Ace, GitHub Next’s prototype multiplayer workspace, in some detail. But the more important argument is about what you do with the hours you free up. Going faster is not the prize. Appleton:

We have an opportunity to not just go faster and build a giant pile of the same crappy software. But instead to make much better software through more rigorous critical thinking and better alignment in the planning stage. By doing more exploration, more research, and thinking through problems more deeply than we could have before.

The reclaimed hours are an opportunity, but they are also a test. Do you spend them shipping more, or do you spend them shipping better? The first answer gets you the giant pile. The second takes work the agents cannot do for you.

Appleton closes on craft:

Many people are now realising that in a world of fast, cheap software, quality becomes the new differentiator. The bar is being set much higher. Craftsmanship is what will set you apart from the vibe-coded slop. But craft still costs time and energy. It is not free, and in order to buy the time and energy for it, you need to do fewer things better, which requires strong alignment.

Andy Matuschak describes two accidental tyrannies that have shaped software for forty years: the application model that traps software in one-size-fits-all packages, and programming as a specialization that crowds out non-programmers from inventing interfaces. He thinks coding agents could break both, and he’s already seeing it happen with the designers he works with:

I’ve been seeing it. I spent 2025 collaborating with two talented designers. Their story with coding agents this past year has been truly wild. I think the impact on my collaborators has been much greater than the impact on me, despite the fact that I’m now building perhaps ten times the speed.

Unlike me, these two started their careers in design and spent their formative years in the arts culture. They can program a bit, but the process was really slow and difficult enough to pose a significant barrier. At the start of 2025, coding models could implement small one-off design ideas—but their outputs would just fall apart after a couple of iterations. By the end of the year, my collaborators were routinely prototyping novel interface ideas and sustaining that iteration across weeks.

“The impact on my collaborators has been much greater than the impact on me.” Matuschak is moving ten times faster, and he still thinks his designers are the ones whose careers just turned over. That observation is rare from the person on the receiving end of the bigger gain in raw output.

Matuschak’s diagnosis of why the old arrangement was such a trap for designers:

Non-programming designers are trying to invent something in an interactive medium without being able to make something meaningfully interactive. So much of invention is about intimacy with the materials, tight feedback, sensitive observation, and authentic use. So it’s a catch-22: to enter into proper dialogue with their medium, a non-programmer needs to get help from a programmer. That generally requires the idea to be at least somewhat legible and compelling. But if they’re doing something truly novel, they often can’t make it legible and compelling without being in that close dialogue with their medium.

The old design-engineering separation trapped designers in a less obvious way. They often couldn’t even tell whether their ideas were brilliant, because they couldn’t get their hands on the material to find out. You can’t iterate on a feeling. You have to push something around until it pushes back. For most of my career, designers did that pushing in flat mockups and click-through prototypes, working through dynamic behavior they had never actually felt. Of course the technical ideas fell short. The designers themselves hadn’t felt the thing yet either.

That’s the asymmetry coding agents collapse. The loop between “I have an inkling” and “I am tinkering with a working version of the inkling” has finally closed for non-developers. They still can’t and mostly shouldn’t ship production code, but they don’t need to. The prototype is enough to do the design work. Once the gatekeeping melts, the next question is institutional: where does the next generation of interface inventors come from? Matuschak’s answer:

So, what now? We’ve spent decades building HCI programs that mostly look like computer science departments with design electives. But if we’re moving toward a world where invention is bottlenecked more on imagination than on technical expertise, we may have that backwards. We may need programs that look a little more like art school with technical electives—learning to develop ideas from intuition before being able to express them precisely, to discover by playing with the material.