Patrick Neeman is making an argument I’ve returned to repeatedly: as AI makes production cheap, designers’ value shifts toward judgment—knowing what good looks like, choosing the right problems, and owning the outcomes. I’ve called this the orchestrator gap: agents execute; judgment stays human. Neeman extends that argument by locating craft itself in that judgment, without pretending execution no longer matters.

The production layer — the wireframe, the boilerplate, the competent first draft of a screen — is collapsing toward free, which changes our own perceived value proposition.

When making gets cheap, much of what you called craft turns out to be production wearing craft’s clothes. What survives is the part that was never about the file: choosing the right problem and owning the outcome it moves. Not a loss but a relocation you can get ahead of. Here is where craft goes.

Craft is not decoration on the product. It is part of what makes the product worth trusting.

When a tool can generate a thousand plausible screens before lunch, the scarce skill is no longer making one; it is knowing which one deserves to exist. That skill has a name, taste, and most people have been outsourcing it to whoever runs the critique.

None of this means polish stops mattering. It means polish is table stakes, not the differentiator. The differentiator is the judgment that points all that cheap production at a problem worth solving in the first place.

That judgment is also what earns trust. Users never see your process, but they feel its absence. A product built on the right calls feels coherent and reliable, and reliability is what brings people back; one built on plausible guesses feels off in ways people cannot name and do not forgive.

Neeman on teaching that judgment to a machine:

Most craft is tacit. You know a layout is wrong before you can explain why. You feel that a flow has one screen too many. Michael Polanyi named this decades ago: we know more than we can tell.

Your taste lives mostly below the waterline of language, in pattern recognition you built over years and never had to state, because your own hands did the work. That gap is harmless when you do the work yourself. It becomes the whole problem the moment you hand the work to a machine.

Point a model at a vague brief and it fills the silence with its own defaults, which is the average of everything it has seen. Average is exactly what craft is supposed to beat.

I agree with Neeman: writing the standard requires the same judgment the standard is meant to preserve.

Tom May profiles creative director Gemma Phillips, whose work follows one test: does it meet people in the reality they already inhabit?

Brands have an instinct to sugarcoat. Maybe they think we can’t handle the truth. But we’re already living the truth; that’s the irony. The grit is where it’s at.

Bluntness delivers the message. Recognition gives it force.

I look at the work they’re already doing. Who’s taking risks? Who’s trying to do something differently? Who’s willing to say the thing that no one else is saying? Who wants to change things, rather than do more of the same but with nicer design?

Humour can be incredibly respectful because it acknowledges reality. It’s a sign that you genuinely understand the audience; you’re one of them, not a machine hovering above them, selling them something they know isn’t true.

Phillips’s work is provocative because it acknowledges the truth and doesn’t gloss over the uncomfortable.

Marcin Wichary, author of Shift Happens and the Unsung essays on software craft, has been cataloging how software fails our hands for years. This new 7,700-word interactive essay has 38 live playgrounds that let you feel the argument in your fingers rather than just read about it.

Wichary’s central argument is that software keeps rediscovering a century of research into how hands actually work: overlapping keystrokes, motor memory, spring-loaded modes, dead zones. For designers, the lesson is that responsiveness at finger scale is not polish. When an interface blocks or delays the narrow timing window our hands rely on, it breaks motor memory and flow.

It turns out, fingers are time travellers. At any given moment, each one is living in a slightly different time – as one finger is moving down to press a key, another is already travelling to the next one, and your brain is thinking of a few keys in advance, visualizing your hands moving to the right place.

[…]

None of this requires touch typing. What we eventually called overlapping happens even if you reside at the awkward intersection of “hunt” and “peck.” Overlapping is a small miracle happening in front of your eyes, and it happens pretty much to everyone.

A capability of our hands and brains to treat our fingers relatively independently, and allow them to move at their own pace without waiting for other fingers (on the same hand) to finish.

The essay walks from 1960s terminal echo buffers through Chrome’s reload-button disabling trick to the moment iOS broke cardinal contracts of programming for the sake of scroll:

[…] competitors reportedly recorded the interactions with a high-speed camera to confirm they were, indeed, running at a constant 60fps.

[…]

iOS stopped running my code in the middle of a function just so it could go back to making sure scrolling was as smooth as possible. No modern programming language would ever dare interrupting your function halfway through; iOS was so dedicated to its user’s fingers that it broke cardinal contracts of programming.

That commitment, prioritizing fingers over execution contracts, is the standard Wichary is asking us to hold in design crits. He closes by turning delight away from decoration and toward restraint:

Sometimes they say that confidence is absence of confidence. […]

In a same way, I think often delight is absence of delight. In places and apps that welcome fast fingers, delight can be abstaining from a transition or something cute but deathly. Pushing for delight of the right kind can mean long fights with frameworks to reduce even one-frame delays…

The interactive format is fantastic. Experiencing painful buffers or re-experiencing how early Mac windows could be dragged around, makes the argument visceral in a way no static screenshot ever could. Start with the playgrounds; they make the timing failures impossible to unfeel.

Taras Bakusevych, a UX designer and writer, synthesized 39 principles for designing human-AI interaction across nine domains: probabilistic foundations, expectation setting, calibrated trust, transparency, control, graceful failure, co-creation, responsible autonomy, and sustained reliance. What makes the piece useful is not the count. It is the insistence that AI behavior is interface work.

The whole framework starts from non-determinism: as Bakusevych puts it, “the same input can produce different outputs.” Standard UI patterns were not built for that property. His framing:

AI introduces interaction problems that conventional UI patterns don’t resolve:

• When should the system suggest, ask, or act?
• How should uncertainty appear on screen?
• What evidence should accompany a generated answer?
• How much autonomy does a given action earn?
• Etc

These are not cosmetic questions. They determine whether users can judge output, recover from mistakes, and remain responsible for consequential decisions.

Principle #14, on sycophancy, is the one I would pay most attention to. It turns “the model is too agreeable” into an interface responsibility:

A model that agrees to keep the user happy inflates trust exactly where it should fall.

When the user’s request contains a false assumption, weak reasoning, missing evidence, unsafe instruction, or likely error, the system should have a way to push back.

Build affordances for disagreement — flag weak reasoning, surface the counter-case, say “this looks wrong.” Sycophancy is overreliance manufactured by tone.

Bakusevych backs that with Sharma et al.’s sycophancy research: five production assistants showed sycophancy across varied tasks, models wrongly admitted mistakes on up to 98% of questions, and the preference model favored sycophantic answers 95% of the time. Design the disagreement in: a flag, a counter-case, a refusal to smooth over weak reasoning just because the user sounds confident.

Emily Campbell, designer and writer, on AI’s position in the design stack:

AI asks designers to go one layer deeper again: into the model, the harness, the context, the policies, and the emergent behaviors that produce the experience before it ever reaches the interface.

Jesse James Garrett’s The Elements of User Experience asked designers to look past the surface layer they owned. Jamie Mill’s The Elements of Product Design asked them to look past the product and into the conditions around it. Campbell maps the next step in that arc with a six-layer architecture: User Interface, Context, Harness, Model, Governance, Emergence.

We cannot control for every outcome directly through the interface, but we can design the conditions that shape a model’s generation. In that regard, the work of design looks less like specifying every expected state, as Garrett’s model encouraged, and instead closer resembles system design, identifying and manipulating the leverage points in a system that exist in the layers below the surface.

Of the six layers, governance puts designers in the least comfortable position. The rules that shape AI behavior often come from legal, compliance, security, and executive choices before the interface team ever sees them. When that reasoning is not documented for the people designing the experience, assumptions pile up and harden into product behavior. Campbell’s conclusion is about fluency, not ownership:

The expectation going forward should not be that every designer works across every layer. Full-stack AI designers need to have a general fluency across all inputs into the experience, so they can influence, mitigate, or receive the impacts that upstream work has on the end experience.

[…] Technical designers are more likely to focus on the Model, Harness, and Context levels, and the role is more than just “design engineer”. Other designers may focus further down the stack, as we might see design-specific titles pop up in policy making and emergent research (these roles exist today, under titles like “business designer”, but have not reached critical mass within the industry). And of course, classical design will remain, but its workflows, tools, and outputs will evolve.

Marina Krutchinsky, the writer behind UX Mentor Diaries, spots the part designers tend to miss: they have internalized the belief that design work is secondary unless someone else translates it into business language.

Here’s the thing: most executives don’t understand what design is.

To them, designers are the people who make things pretty after the real decisions get made.

And every time you present your work in design language, you confirm that belief.

Her client had just shipped a checkout redesign that cut abandonment by 35%. Real work, invisible to the CFO who walked past her in the hallway. Three slides changed the conversation:

“Our checkout flow was losing $1.2M annually in abandoned carts.”

“We identified 3 friction points and redesigned the payment experience.”

“We recovered $840K in the first two quarters. Projected $1.4M annually.”

That’s it. 3 slides. Maybe 45 seconds of talking.

The CFO asked her to stay after the meeting. First real conversation they’d ever had.

Krutchinsky’s three-part structure is familiar: name the leak, name the intervention, name the result. The sharper move is the business-language translation that follows:

CFOs don’t care about usability scores. They care about margin, revenue, and risk.

When you connect your work to those things, you stop being “the design person” and start being someone who solves expensive problems.

That imbalance will not fix itself. Designers already know the first language: usability, friction, flows, trust. The second one is finance’s language: margin, revenue, risk, and the expensive problems design actually solves.

Wouter de Bres built a free online book about psychology for designers. Forty chapters, organized around four areas: the people you design for, the interface you put in front of them, your own cognition while designing, and the organization that can override all of it before you ship. The introduction explains why he made the site:

Every decision you make as a designer is a claim about how a person will think, feel, or behave. Where you put a button is a claim about where people look. What you show on an empty state is a claim about what people need when they feel lost. Whether you use a progress bar is a claim about how people experience effort. You make these claims every day. The only question is whether you make them with understanding of how people actually think and work, or just with a gut feeling and a deadline.

That is the useful provocation: design is already full of behavioral claims, even when nobody names them that way. Chapter 14 goes after “intuitive”:

“Intuitive” is one of the slipperiest words in a design review. Designers say it all the time and nobody pushes back because it sounds like evidence. Usually it is not. Most of the time it is just a description of how familiar the designer feels with the thing they made, and that is a weak way to judge whether it will work for someone else.

Most of the time, intuitive just means familiar.

That chapter is the internal trap: designers can mistake their fluency for the user’s. Chapter 27 is the external version of the same problem, where teams underestimate how expensive it is for users to leave an existing routine:

This is what teams underestimate when they say users are irrational for sticking with a worse tool. They are not running a fresh comparison every morning. They are moving inside a routine that already became cheap to repeat. Less thought. Less searching. Less risk. Your product may be better once it is learned. The old one is better at 9:03 a.m. on a busy Tuesday.

A lot of product strategy gets built around the wrong moment. Teams compare tools in a calm demo state. Users switch in the middle of real work, with deadlines, interruptions, and habits already in motion.

The two chapters work well together because they correct the same designer bias from opposite sides. Inside the team, “intuitive” often means “familiar to us.” Outside the team, a worse incumbent can still win because it is familiar to the user. The design implication is brutal but useful: better is not enough. The experience has to be easier to understand, easier to try, and cheaper to switch into during real work.

Ethan Mollick, Wharton professor and author of Co-Intelligence, has been running careful benchmarks across models and workflows. His main finding for designers: the shift from chatbots to agents rewards domain expertise, not job title.

What actually mattered was not the profession of the user, but their expertise. The more domain experience someone had, the more successful they were in using Claude Code in that domain. And, even more interestingly, the more useful output they got from Claude from each prompt.

That framing reorients the usual anxiety (“will AI replace designers?”) into a different question: how deep is your domain knowledge, and are you using agents to extend it or to paper over gaps? The underlying shift Mollick is describing:

We are moving from a world where non-experts use chatbots to fill in gaps to one in which experts use agents to get work done. And the best way to use agents is to think of yourself as a manager.

[…]

Being on an exponential means each change over a fixed window is larger than the one before it. If your organization wrote an AI plan any time before the winter of 2025, it described a system that could do a couple of hours of work with a fairly high error rate. A few months later, you can get sixteen hours or more of work from a single prompt. This is why AI keeps feeling like it is making leaps, even though it is a curve on a graph, we keep experiencing a steady doubling of capability as a series of shocks. We are very bad at feeling exponentials from the inside, and we are currently inside one.

The management framing also carries a real cognitive cost. Running multiple agent streams and deciding what to keep draw from the same finite attention budget as the design work itself. Orchestration is its own job.

Drew Breunig, an analyst and developer who writes about AI infrastructure, has a name for the slow accumulation of fixes, workarounds, and escalating all-caps instructions that eventually choke an AI application: prompt debt.

The plain-English prompt that makes prototypes effortless turns out to be a poor way to specify how a system should behave, and the bill arrives slowly, disguised as ordinary progress, until the application can barely move. The problem is not any single prompt. It is that natural language was never meant to be a specification language for engineering, and treating it as one quietly caps what you can build.

Breunig’s model-lock-in evidence is the warning sign. A recent Datadog report shows GPT-4o is still the most-used model in observed traffic; Breunig also says multiple large inference providers put GPT-4o and similar-vintage models above 50% of all calls. His proposed escape hatch is to stop treating hand-written prompts as the durable layer:

Every mature engineering discipline eventually stops doing by hand the very thing it once prided itself on doing by hand. Assembly gave way to compilers, hand-tuned queries gave way to planners, and manual memory management gave way (mostly) to machines that do it better. Prompt-writing is no different.

Coaxing the model with exactly the right words is a real skill, and for one-off tasks it’s often optimal. But to build reliable, improvable, and portable systems we should not be hand-tuning prompts.

For designers, the useful warning is not that prompt craft goes away. It is that fragile prompt craft stops scaling once the AI behavior becomes part of the product. If the system has to survive a model upgrade, the design work has to move into measurements and typed specifications: schemas or contracts that constrain what the model can produce and give the next model something stable to inherit.

In June 2026, Stack Overflow unveiled a full rebrand by studio Koto, repositioning from Q&A platform to “the world’s most vital source for technologists” right as monthly new questions on the site are down roughly 77% since ChatGPT launched. The brand investment and the traffic freefall are happening simultaneously. That is the context for Ishan Gupta, a software engineer at Amazon, and his five-phase history of how the old engineering workflow collapsed.

Software engineering was a craft you absorbed slowly, then practiced in a long, predictable sequence: Dive deep on the technology, write the code, ask Stack Overflow when stuck, escalate to a senior engineer when Stack Overflow failed, ship the ticket. The product manager owned the funnel. The engineer owned the build. Both sides treated this division as physics.

That division is dissolving. Gupta traces it through the IDE-native era (e.g., GitHub Copilot and Cursor), the spec-driven era, and the Claude Code Routines era (Anthropic’s scheduled, persistent agents). At each step, another piece of work that used to require a human gets handed off. Gupta’s diagnosis:

Anthropic recently told its growth team to hire more product managers, not fewer. The reason, as reported in industry coverage, was that Claude Code had quietly turned its engineering org into a team that ships at roughly three times its actual headcount, and the bottleneck moved from the integrated development environment (IDE) to the people deciding what to build.

That detail is easy to miss in the noise of every AI productivity claim. It is also the structural shift the rest of the industry is now living through. The bottleneck in software is no longer typing. It is deciding what to type. And the engineers who treat that as someone else’s problem are about to plateau.

That same shift is what Koto’s rebrand is responding to. Cat Hill, senior strategist at Koto, put the rebrand angle plainly: “In the AI era, everyone wants faster answers. But speed is useful only if the knowledge underneath is trusted.” For designers, that is the opening: the product-thinking gap is no longer a soft skill around the edge of engineering work. It is where the work is moving.

Gupta’s clearest description of the new engineering identity is also the case for why product judgment matters more:

The 2026 version of a great engineer is not the one who writes the most code. It is the one who knows what to build, can prove it is worth building, and has the agent fleet plus the review discipline to ship it without the system collapsing under its own velocity.

The first time I retrofitted a URL scheme onto an existing web app, it wasn’t easy and the engineers on my team were reluctant. The work itself looked like engineering cleanup, but the problem was design debt: the product had no shared model for what its pages, states, and resources were called.

Routes accumulate around backend data models and frontend file conventions rather than the resource hierarchy a user or linking system would recognize. Ownership fragments across teams; each team names things for its own context. By the time someone wants to clean it up, the redirects are locked in by downstream dependencies and analytics instrumentation is tangled around the old slugs. The retrofix was necessary groundwork for new features that needed stable, meaningful URLs to work at all. The real lesson was that we should have had this conversation at the start, not mid-build.

JSTools.Space explains why that cleanup is so expensive:

A URL is part navigation, part application state, and part public interface. Once users bookmark it, search engines index it, monitoring systems record it, and other applications link to it, changing that URL becomes an architectural decision rather than a cosmetic edit.

Good URL design is therefore less about making every address look pretty and more about making it predictable, stable, and unambiguous.

The decision framework should be a team contract from day one: path for identity, query for optional state, fragment for in-page location or client-only state. Inconsistent routes are what make a migration touch everything. Designers should care because this is information architecture in production, not just routing syntax.

Heenesh Patel links Apple’s WWDC 2026 moves (Siri now able to invoke app functions without the user ever opening an app) to a larger skill shift for designers. The polished-UI moment isn’t ending, he argues; its shelf life is just shorter than we think.

This moment might be shorter lived than expected, as we enable agents to execute more tasks on our behalf, screen-based flows fold in on themselves to intents, replaced by API calls and lightweight confirmations. Here the beautifully crafted experience still matters, but it’s not where the experience lives.

As designers continue to rapidly evolve their skills in an AI first world, taste judgement can elevate the experience but only so far and the real differentiator in app design becomes the overall experience architecture, and how flexible and robust apps are in embedding into the platform.

Patel locates the new value in how flexibly and robustly an app’s functions embed into the platform. That is a systems problem before it is a screen-design problem.

Taste is the skill of this moment. Systems thinking is the skill that will become indispensable in the next chapter of design. Designers who start building that capability now will be the ones setting the standard when the shift arrives in full.

The uncomfortable implication in Patel’s urgency: Job Stories (a way to frame user intent in context) and state charts (maps of the states an experience can reach) have been in the UX toolkit for years. What changes is the operating system. If Siri can trigger app functions directly, and if users can move through an experience by intent instead of by screen, designers need to understand the states, permissions, handoffs, and failure paths that sit behind the interface.

Christian Cleberg, an independent developer, traces the internet across his lifetime, from the family Gateway PC in 2001 to the 17-step obstacle course it takes to read a headline in 2026. The essay is nostalgic the way a good memoir is: it names real years and real machines.

Once upon a time, the internet didn’t even exist. When it did, the internet was a place. It was a place you went. You selectively chose to visit the internet, based on your own free will. If you wanted to visit a chat room, or perhaps preview a fancy new Flash game, you visited the internet for a few minutes in the evening before going back to your family or friends. This has changed dramatically in the last 20-30 years. Today, it’s 2026 and woven into nearly every part of daily life for the majority of the Earth’s population.

The transformation Cleberg describes is behavioral, not technical. The internet stopped being something you opted into and became the condition of modern life. The independent web is now infrastructure you rent through friction and attention extraction, not just because of how we use the internet, but because of who decided what it became.

However, there was a dark side to this revolution. As these apps progressed, and the underlying technologies progressed, the companies and investors driving these efforts took a turn. Efforts pushed into the world of micro-transactions, psychological rewards for utilizing a platform, profits over value, and a slow descent into a disregard for the users.

To me, that 2012 era was a turning point. You may personally love a different era (1980/1990s gamer, anyone? Any former phreaks out there?), but to me, it felt like we kept making leaps in technological capability until we reached the point of economic profitability in the 2000s-2010s era, where corporations, investors, and governments took a serious interest in controlling the internet.

Cleberg’s closing distinction: the internet didn’t disappear, the experience of it did. The infrastructure is still there; the sense of it as a place worth exploring is not.

That loss already had a response. Jeffrey Zeldman—web-standards pioneer, founder of A List Apart, and longtime open-web advocate—wrote on his own blog after attending a preview of filmmaker Bao Nguyen’s documentary Code for the People, a film about the builders of the open web:

The answer to this destruction of our shared digital commons by a handful of billionaires is the same as it has always been: own your content on the open web (your domain on a server, like mine on this one), and replace proprietary software with open source alternatives.

Cleberg is writing about the disappearance of a feeling. Zeldman’s post is smaller and more practical: own your domain, publish on the open web, choose tools you can keep. That does not solve the larger fight for the open web, but it does make the response personal. A domain is not nostalgia. It is a small claim of custody over your own work.

The web is forking. Sara Guaglione reports that publishers are starting to build one version of their sites for humans and another for agents. The phrase that matters is Time chief operating officer Mark Howard’s “separating out that traffic.”

“[The bots are] just getting the content itself and the metadata, but they’re not getting the full page experience, and we’re routing all the humans to the full page experience. So we’re separating out that traffic,” Howard said.

“Now we’re starting to think about, as the volume of bot traffic continues to increase significantly – and we see through a number of our vendor partners that we have very high domain authority with AI bot traffic – there’s value in that,” he added.

Howard is making the operational case. Toshit Panigrahi, co-founder and CEO of TollBit, makes the economics explicit:

“Part of onboarding to TollBit is we create your agent site for you,” said Toshit Panigrahi, co-founder and CEO of TollBit. “It really comes down to the token economy. Websites have a lot of HTML tags and JavaScript and CSS and things that don’t have to do with the content. That creates a big bloat in the actual size of the page.”

Markdown can make websites “friendlier” to agents, he added. “AI can comprehend more of your article because they’re not spending money parsing out other HTML that’s on the page. We see, on average, a 90% reduction in tokens, because we have converted the content to markdown.”

That efficiency argument is real. But independent publisher consultant Scott Messer, principal of Messer Media, pushes back:

Yet, even as more publishers quietly spin up agent-friendly feeds, stripped down pages and custom schemes, not everyone is convinced they should be racing to re-architect the web for bots. Independent publisher consultant Scott Messer, principal of Messer Media, argues that building for agents should be a highly qualified decision, not the default. His reasoning: traffic isn’t the reward in an agentic environment – if there is no click, no ad impression and no check, the build is pure cost.

“If you believe there’s a value to being discovered by these bots and agents, then you should build them. If you don’t believe [that], I would ask, why would you build them?,” he said.

That is the question under all of this. The rendering layer—the HTML, CSS, and JavaScript that turn server content into pages—is exactly the surface designers build, and publishers and content creators are now deciding which parts of that surface matter when the visitor is no longer a person.

I’d argue that RSS can be easily consumed by agents too.

I wrote about who killed Google Reader because Reader’s shutdown felt like losing a whole way of using the web: the curation layer, the accidental social network, the daily habit. Matthew Guay, editor at Buttondown, is interested in the part that survived. His answer is blunt: nothing important died.

The feeds walked out intact: three million people moved to Feedly in two weeks, and the content never left the blogs. Guay’s point is that we were mourning the right thing—the curation layer, the accidental social network—at the wrong level of the stack: the aggregation service, not the open protocol underneath it.

Not an iota of data was lost, as the content that filled the feeds lived on individual blogs and websites. Google+ users wouldn’t be so lucky, six years later, when that network too was shuttered, taking with it their non-portable social graphs and ephemeral posts.

That contrast is the spine of the piece. Google+ and Google Reader died the same administrative death, both casualties of the same corporate pivot, but they died completely different technical deaths. Reader’s users lost a habit. Google+ users lost everything. The portability of the underlying protocol made the difference, and it’s why early RSS developer Dave Winer could be so clear-eyed about Reader’s shutdown at the time:

“I won’t miss it,” said early RSS developer Dave Winer more cantankerously—or, perhaps, more clear-eyedly—of Google Reader. “Never used the damn thing. Didn’t trust the idea of a big company like Google’s interests being so aligned with mine that I could trust them to get all my news.”

But that’s the thing about RSS. Winer didn’t need to love Reader for people to follow his writing there. And when it went away, those same readers could still follow him directly, could still read the words on his site that yesterday they’d read under Google’s auspices.

Designer and author Marcin Wichary picked up the same portability-survival thread in his blog Unsung, marking the 13th anniversary, and he quoted my February post in the process. His read: “I am worried about the open web, but excited seeing some resurgence in RSS usage, and more and more people wanting to come back to the feeling of control, care, and intentionality that using Reader represented.”

That resurgence Wichary is watching is what Guay’s closing points toward, too:

It was the open protocols, the RSS feeds and email, that alone offered a direct connection to your favorite writers and publications, unmediated by algorithms. Sure, they didn’t come with built in sharing features, they were harder to discover, they required more work to turn into a community. But once you did find them, they were sticky, a connection no one other than the publishers themselves could take away.

This blog is my version of that direct channel: a website, built one reader at a time, outside the platforms that decide what gets seen. I still miss Reader’s curation layer. The win is that the open-protocol layer underneath it—RSS, personal blogs, the direct connection—survived anyway.

We haven’t talked too much about AI and e-commerce here on this blog, but as much as any other area in our digital life, AI agents will change how we shop online.

Elizabeth Pizzuti, writing on the Automattic Design blog, explains the two definitions for how “agent” can be used in the e-commerce context.

The word “agent” is overloaded in 2026 commerce.

Two unrelated things share it:

1. Agentic commerce: AI shoppers buying from stores.
2. Agentic merchant operations: AI workers operating for the merchant.

The distinction matters because the two sides ask designers to make different things legible. On the machine-buyer side, Pizzuti’s first principle is basically agent readiness applied to commerce:

AI agents don’t browse websites like humans, they read structured data from the backend. Considerations here include providing an “AI readiness” score or dashboard for a clear, visual indicator of product catalog health, and a preview of how the AI agent sees that data. This demystifies the structure and allows the merchant to see exactly what an algorithm is evaluating. Additionally, make sure that context is part of the catalog—blog posts, buying guides, FAQs, and reviews all determine sentiment and trust and should be linked to the product schema.

For merchant-side coworkers, the problem flips. The interface is there to help a human judge whether the system did the right work. Pizzuti on the interface merchants use to judge and approve the agent’s work:

Designing for trust means exposing the agent’s backend homework. A merchant will never click “Approve” out of blind faith, especially in high-risk areas like pricing or inventory replenishment. Every automated recommendation must include the underlying context and trigger. Instead of “Drop price of item X by 10%”, the UI should show the reasoning chain:

• Observation: Competitor price drop detected.
  • Impact: Your listing’s conversion rate fell by 14% over the last 48 hours.
  • Reasoning: Lowering the price by 10% restores your competitiveness while preserving an 18% net margin.

That’s the right design shape for AI coworkers: controllable over perfect, with proof of work, a visible undo path, and enough context for the merchant to approve the change without pretending the system is magic.

Nolen Royalty, a software maker who writes at eieio.games, gets at a problem with AI-generated work that shows up before judgment: the effort signal. His examples include tldraw, the collaborative drawing tool, closing AI-generated pull requests, warm-cream Claude websites, and record collecting, but the point is simple. Polish used to be a proxy for care. Now it isn’t.

What software (and writing, to an extent) is missing now is legibility of effort - the ability to tell at a glance whether something took a human meaningful work.

Until recently, “someone cared enough to write this” was an ok heuristic. Plenty of writing on the internet was bad, but you could convince me that you cared about something just by writing it down.

Of course, generating plausible-looking text - or a plausible-looking website - is trivial now.

For designers, that broken proxy is already visible on the surface. We can all spot the default Claude style now, which is funny until you realize that a visual pattern has become an accusation about how much thought went into the site.

There’s nothing objectively wrong with making a website with a warm-cream background and hero text in a sans-serif font with a single accent word that uses an eye-catching color and a different font.

But when I see a website that has the default Claude style I assume that the author put ~no thought into how the site should look. And I often assume that the author didn’t put too much thought into the rest of the site either.

That’s not fair of me! But “someone made this website” is no longer enough to tell me that the website was important to them. So “default Claude style” is one of my new heuristics.

Taste sounds less mystical when you put it this way. A designer doesn’t make a screen human by avoiding beige or picking a stranger typeface. The work is in the decisions: why this hierarchy, why this contrast, why this interaction, why this amount of friction.

The proliferation of digital music and streaming made having a music collection easy and frictionless. And so a subculture evolved to re-add that friction.

And in small ways I think you see the same things happening now.

I’ve seen people joke about adding typos to emails to prove that they wrote them. MS Paint-style image macros read as more human than detailed, funny images (the image could be AI slop). Websites that look intentionally bad are more interesting than websites that look beautifully bland.

The easy story about AI in creative work is that it closes distance: idea, prompt, output, iteration, all compressed. It’s Nice That gets at the more designerly version of that question by putting creative technology’s appetite for “happy accidents” next to design’s need for control:

“From the technology approach, the metaphor I equate it to is the classic ‘happy accidents’ you have when you are in a design tool,” Seth says, finding expected moments of creativity. “The best happy accidents aren’t just between a person and a tool; they happen between people.” It’s perhaps in this notion that co-creation is at its most visible, not in the technology itself, but rather in the conversations and unexpected developments that occur when people with different perspectives work closely together. For Talia, however, this isn’t the case. “Nothing we do is experimental by nature,” Talia says, “everything is incredibly controlled – or, better yet, ‘designed’,” stressing the importance of the role of the designer and the meaning behind design itself. “Design is about creating solutions; there is a sense of control, there is a purpose, there is a function,” she continues, “even the beauty is controlled to a degree.” An example is the generative motion graphics system that Talia created, in collaboration with Mother, for the Crypto coin USDC.

Designer and coder Talia Cotton’s line clarifies the whole piece: “controlled – or, better yet, ‘designed’.” Cotton’s point is that the speed of generation only makes the designer’s eye more important, because someone still has to decide the boundaries before the machine starts producing variations.

Cotton’s USDC system makes that concrete:

Within the visual identity, Talia developed a custom tool that generated guilloché patterns, in reference to the historical patterns used in traditional finance. Alongside set, systematic parameters – including height, width, density, and speed – Talia had to create algorithmically constrained rules within those limitations. “As you adjusted one parameter, another parameter would automatically change its available range,” Talia says, “that ensured every possible output looked good.” As Talia suggests, especially considering the ease with which people can generate things, the “designer’s eye” is now more important than ever. “The designer’s job is to create an airtight generative system that considers every possible case and every possible output,” she says, “so that every single output always looks great, no matter how different it is.”

Karo Zieminski, in her newsletter Product with Attitude, is writing for builders, founders, and PMs, but the design translation is straightforward: AI fluency without critique is just a faster way to lose your ability to evaluate the output for yourself.

She draws the distinction:

Plain AI literacy means knowing how to use AI tools. It means learning to prompt, create automations, and bring AI into your workflows.

Critical AI literacy goes further. It adds systems awareness: understanding that AI is not just a tool on your screen, but part of a larger system of model choices, product decisions, business incentives, policy constraints, ethical tradeoffs, and human consequences.

Attitude is the posture that turns AI literacy into critical AI literacy.

That word, posture, matters. It is the same split in not outsourcing the learning: the tool doesn’t determine whether you get sharper or softer; the way you use it does.

Zieminski puts research behind that concern:

The data is on the table now. Microsoft Research surveyed 319 knowledge workers in 2025 and found that higher confidence in the AI is associated with less critical thinking, while higher confidence in yourself is associated with more. MIT Media Lab’s “Your Brain on ChatGPT” study measured the same erosion at the level of brain activity. The muscle is real, and it atrophies on schedule.

For designers, the warning is: don’t let the tool do so much of the looking, choosing, and checking that you stop building those muscles yourself.

Zieminski defines the working posture plainly:

AI with attitude means using AI with judgment, boundaries, curiosity, and scrutiny. You enjoy powerful tools without worshipping them, panicking about them, or letting them decide how you think, work, create, and learn.

Tiina Golub, writing in UX Collective, points at the right version of “personalization” for enterprise software:

I have spent most of my career working on the large-scale computer programs designed to operate and automate complex business processes for big organisations, known as enterprise software. Due to their size and complexity, these products are often slow to innovate, relying on outdated usability principles and legacy systems long after the rest of the industry has moved on. However, recent technological advances (yes, I’m mostly talking about AI) have both enabled and compelled them to evolve at an unprecedented pace. No one can tell for sure what the future will look like, but there are some clear trends reshaping the user experience of enterprise software right now.

The interesting part is not that enterprise tools should start feeling like consumer apps. That usually leads to dashboards with the user’s name on them and a recommendation panel nobody asked for. The better version is software that understands the work well enough to reduce how much process the user has to remember.

That makes AI less useful as a standalone feature and more useful as embedded guidance:

No longer a stand-alone feature, AI is increasingly woven into the fabric of the interface, deeply embedded into every workflow, and offering contextual guidance right when the user needs it.

That is the useful frame: enterprise personalization is not taste. It is role, permission, workflow state, and organizational context. The product gets “personal” when it knows what kind of decision the user is trying to make, what constraints surround that decision, and what help belongs at that exact moment.

Jenny Xie, writing for Figma, collects a set of community sketches about what AI-native software might feel like. The useful part is how concrete the sketches get: controls that appear only when they’re needed, systems that change pace when the user is overwhelmed, and interfaces that treat intent as the starting point instead of the final prompt.

Figma Weave marketing director Itay Schiff starts with creative tools:

When you’re working with a creative tool, select an element—a frame, a sentence, a scene—and state what you need to do. The right controls appear around it, surfacing only what’s relevant to that moment. No hunting through menus, no memorizing where things live. When you’re done, they disappear. Someone editing a video that feels too slow selects a clip and sees options for timing, pacing, alternate cuts, and sound bridges. You’re not losing touch with your craft, but accessing the right controls more directly, through context. This bridges the gap between how people think and how tools are structured. Creative work starts with intent—make this clearer, more nuanced, more intense—but traditional software is organized around persistent menus, panels, and modes. When users can focus on decisions rather than mechanics, the conversation shifts from what buttons we pressed to what we changed, and why.

This extends the generative UI debate from generated content into the surrounding interface: what controls appear, when they appear, and when they disappear.

Anna Oh, Head of Product and Design at Norbert Health, pushes the same idea into domains where software has to adapt to the person using it:

An intelligent system continuously adjusts how it communicates and acts based on how you respond. It offers structured guidance when you seem lost, steps back when you don’t need it, and shifts between voice, text, and visuals based on the context. It controls pacing, simplifies language, or breaks down information into smaller steps to reduce overwhelm. For decades, humans have had to adapt to machines. The mismatch between system capability and human readiness has only grown more visible as software becomes more powerful, and in domains like healthcare and education, especially with an aging global population, that gap has real consequences. As AI becomes the intelligence layer, this reverses: Systems meet people where they are, instead of the other way around.

For design teams, that means pacing, language, modality, and restraint become interface decisions, not polish applied after the workflow is done.

Tech anthropologist Jésabel DC shifts from adaptive behavior to the sensory cues that help people understand where they are in a product:

Sound, motion, and pacing are reintroduced as signals that orient you inside an experience. In the early 2000s, digital interfaces were full of these situational cues: the dial-up sound as you went online, the progress bar acting as a passage to the world you were entering, the voice announcing “You’ve got mail.” As technology became faster and more seamless, these cues disappeared, replaced by notifications engineered to grab attention rather than provide orientation. Because our users’ overall tech experience is already so dysregulating, it’s not enough to design something that isn’t overwhelming. We have to actively design experiences that counterbalance the rest of our users’ tech stack—otherwise, we risk losing users not because our product is bad, but because their nervous systems are already maxed out before they arrive. Think: always visible progress bars, sounds that mark transitions, and consistent visual language.

Sen Lin, writing in UX Collective, has a useful reference for designers who want Claude Code to fit their workflow instead of acting like a generic engineering agent:

Claude Code is an agent, and an agent is only as good as how you configure it. That’s the part worth paying attention to as a designer: Out of the box it leans engineering, but you can set it up to fit how you actually work — to understand design, respect your workflow, and carry the right capabilities — so it produces better results, faster.

A technical stack is the set of technologies you decide on before writing a line of application code. A design stack is the same idea, applied to Claude Code: the brief, the design knowledge, and the tools you hand the agent upfront.

The useful move is treating Claude Code setup as a design operation, not a prompt-writing trick. Give it a project brief, a design-system guide, and the right tools before it starts touching the work.

If CLAUDE.md is the brief, DESIGN.md is your design system translated into something an agent can read and obey. It’s a format specification that describes your visual identity to a coding agent: the exact values, and the reasoning behind them.

The file works on two layers, and both matter.

The first is machine-readable design tokens, written as YAML front matter — the exact values, so the agent never has to guess what gray-500 resolves to or which surface color a modal should use: […] The second is human-readable design rationale, written as prose — the part that explains why a value exists and how to apply it. Tokens tell the agent what primary is. The prose tells it there should never be more than one primary button per view, that a primary action is always paired with a neutral or subtle one for cancel, that button width is set by the parent and never hardcoded.

The tool/instruction split is the part worth saving:

MCP gives the agent access to tools.

Skills give it the knowledge to use those tools well.

Where MCP is access, a Skill is a markdown-based guide that teaches Claude how to perform a specific task in a specific way. It’s a set of instructions, scripts, and resources — a training manual that keeps the agent from wandering down expensive detours and burning tokens on the wrong approach.

Good checklist. The designer’s job is not just to ask Claude Code for UI. It is to onboard the agent into the product, the design system, and the working style before generation begins.

Michael Riddering’s Dive Club interview with Loredana Crisan, Figma’s chief design officer, is about how Figma wants a bigger, faster, more explicit design loop.

Riddering asks Crisan whether taste gets less defensible when everyone can make more things faster:

I actually think that what happens when everyone has the power to build is actually it elevates the need to stand out. You could buy those pretty funny or soulful congratulatory cards, birthday cards, whatever cards, and they have the message written inside. And it’s a great message. Do you just give somebody that card? You could, but that’s not what you do if you’re a good friend. That’s not how you show up. And so I think that the more software is getting created, the more articles are being written. Basically, we’re in a place where everything is getting produced at such high, high rate. And we already had trouble consuming what was already there. And so what we’re going to try to do is look for even more authenticity. […] So this is why I think it’s not taste. It’s just your point of view, your human intuition, what you want for that experience needs to come through. And then the tools that they build are very much important to help you drive that.

I think Crisan is right about the greeting card metaphor. When production gets cheap, the work that still feels made for someone will matter more, not less.

That matters for designers because AI abundance changes the filter. The scarce thing is knowing why this draft, this interaction, this bit of motion belongs in this product.

Riddering then pushes on control, which is where Crisan gets concrete about Figma’s tool bet:

The premise is that AI could get you to 70%. And this is true with motion. You could prompt your frame and then you will get the first animation set up. But then from there, you need to make it yours. So it’s almost like AI sets up the workspace. It gives you the parameters, but then you are the one that makes that thing. […] If there is a color that I want to put in my design, a color wheel will never be replaced by a prompt. So there are moments where you just want to take control yourself. […] And it’s an interesting way of working because increasingly as designers, I believe we’re creating systems, not just screens. […] Design is never done alone. Design is evolved through critique. It’s a place where one of the tools of design is other people. And so it’s really fun to be able to have AI, have agents, have the direct manipulation and direct control and your team in one space.

This is the version of AI design tooling that makes sense to me: the tool accelerates the setup, the first draft, but the product still gives designers enough control to make taste visible in the final result.

When working with AI design tools, we tend to think we need to one-shot a prompt to get everything. That, of course, is far from true. We iterate—a lot—by describing the changes we want, then waiting, and inevitably, iterating again. Crisan is describing a tool that still leaves room for the hand: sliders, variables, shared artifacts, and other people.

And she points to evals as part of the designer’s new job:

Increasingly, we’re working with non-deterministic systems, right? So a lot of what the experience is, is produced by an LLM. Previously, it could be produced by an algorithm. I worked at Meta and can tell you, we’ve had a lot of conversations about the buttons that would exist on a feed story. Those buttons are important, but when you think about what people really experience when they open one of those products, it’s the content. And so all of the conversations that we had about buttons as designers were far, far less important than the conversations that we should have had about the algorithm itself, right? And when it comes to these non-deterministic systems, how do you ensure that they meet your quality bar? There’s this thing called the evals is, on the one hand, the least sexy thing in the world, because you are now in a place where you’re trying to specify what good looks like and how systems that could either recognize that themselves or be augmented with humans that could do that. And it’s fascinating to try to do this on an unverifiable domain like design, because design is not, there’s not a correct answer to design, but there are many incorrect answers.

Figma’s own Config 2026 recap makes its strategy clear: it shipped code layers that bring editable, inspectable code onto the canvas; Figma Motion with timelines, keyframes, exports, Dev Mode inspection, and MCP compatibility; shader fills and effects generated by the Figma agent; generative plugins that let teams create canvas-native tools by describing them; Weave tools for reusable generative workflows; and a broader Figma agent with skills, connectors, attachments, and shared chats. The through-line is not one more AI feature. It is Figma trying to make the canvas the place where code, motion, generative media, team-specific tools, and agent context all live together.

The old design-tool space was mostly canvas versus canvas: Sketch, Figma, XD, Framer, whichever product made design teams move faster. Darren Yeo, writing in UX Collective, is looking at a different fight: Figma against the possibility that the canvas becomes optional.

Figma’s enterprise strength has always depended on breadth. Designers used it first, then product managers, engineers, marketers, writers, and executives followed. The more people needed to review, comment, inspect, or reference design work, the more seats Figma could sell. The same applies for the product bench, with the rapid expansion of Slides, Buzz, Sites, and now Motion and Weave.

AI complicates that logic. If an engineer can generate or inspect UI directly inside a coding environment, or if a product team can translate structured design intent into working software without opening a shared canvas or applications, the need for passive, underutilised seats weakens. Config 2026 actually confirms this tension by bringing code layers and agent workflows closer to the main product, Figma Design. In other words, Figma is acknowledging that an increasing number of people want to participate in product and code creation without relying on traditional file-based design behaviour.

That does not kill Figma’s seat model overnight, but it does chip away at the assumption that every stakeholder must enter Figma to participate or experience design. Thus, the deeper issue goes beyond whether the team has seats at the table (canvas). The table of collaboration resides in a code-native environment and workflow, where the moment of truth shifts closer to implementation, and that reduces the number of times a team needs to return to a design file as the source of record.

The handoff-is-dead argument usually shows up as a claim about what designers can do now: move closer to implementation, write production-minded specs, and stay in the work longer. Yeo adds the business-model version of that argument. If collaboration moves into code-native environments, Figma is not just losing a handoff step. It is losing the shared room that made every reviewer, PM, engineer, and executive need a paid license.

Figma is not standing still. Even before Config 2026, the company pushed beyond static collaboration and into AI-connected workflows. Features like MCP, Code Connect, and Figma Make on local code point toward a future where design data can move more fluidly into development environments and AI tools.

That is a smarter response than pretending the canvas can win by becoming a slightly better canvas. Figma’s best path is to become the system that preserves design intent, component logic, and implementation alignment across tools. In that model, Figma is becoming an operating layer.

This is also why the company’s product strategy feels more important than its individual features. A single new AI button will not change the story. What matters is whether Figma can make design data more portable, more structured, and more useful outside the file itself. Config 2026 suggests that Figma understands this, but it also shows how hard the transition is: the company still has to make the canvas relevant in a world where many teams want to begin and finish elsewhere.

Yeo’s warning is blunt: “if teams can skip past the canvas by accelerating from intent to implementation with less translation, the value of designing to handoff vanishes.” The answer he points toward is less about file ownership and more about whether design intent can survive the trip across tools. For designers, that shifts the work from drawing the artifact to making the intent durable enough for other tools to read.

The future of design is likely to be built around reusable tokens, readable structures, and tool-agnostic metadata rather than locked files that only live well inside one platform. The winning systems will be the ones that can travel between editors, browsers, codebases, and AI agents without losing meaning.