159 posts tagged with “tech industry”

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.

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

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.

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.

Tom May, writing for Creative Boom, says the old bargain for independent creatives is breaking: make good work, publish it well, and the web would direct a few customers to you. The old SEO problem was already bad enough after Google’s AI Overviews, but May is pointing at the next step, where the answer is presented to the user without having to visit websites.

The web, it said, is moving “beyond the traditional search-and-click model toward a more conversational and generative web,” where brands now compete “not just for attention, but for recommendation, relevance and action”. That might sound like a boringly technical sentence, but buried within it is something very profound that affects every creative working today.

Because what it describes isn’t just a change in how Pinterest sells ads, but a fundamental change in how people find information and inspiration online. And if you’re a creative, the implications for whether you actually get work in future are huge.

May again:

Nowadays, when someone types “find me an illustrator who works in cut-paper collage for a children’s book”, AI returns an answer, not a list of links to explore. It decides who gets named, and there’s no way to influence it: no ad slot to buy, no SEO lever to pull.

And how does it reach this decision? AI platforms lean on aggregate signals: who’s already cited, listed, written about, and linked to. This favours the already-famous and the big studios with a deep web footprint, leaving the vast majority of smaller independents floundering.

It’s a virtuous circle for the former, a vicious one for the latter. The visible gets recommended, and the recommendation makes them more visible. The talented new graduate with a thin online presence isn’t in AI’s field of view, so they stay invisible forever.

For designers, that changes the portfolio from a gallery into a set of reputation signals: named projects, credited collaborations, interviews, and references that point back to a specific person or studio.

In a market where output gets easier to generate and distribution gets harder to earn, distinct judgment and identifiable work become business-development assets. The work has to be specific enough, and trusted enough, to be requested by name before an AI system is asked for a recommendation.

In this shiny new world of AI, you can’t optimise your way into a recommendation, the way you once keyword-optimised a website. Recommendation runs on reputation signals that a system can read: being named in other people’s work, on lists, in interviews, in the press, and in collaborations. So the answer for creatives isn’t to play the algorithms harder. It’s to become the name people and systems already trust enough to surface.

One part of that is to own your relationships. A newsletter list, for example, is a direct connection that no algorithm can intermediate away. A community of people who’ve chosen to hear from you isn’t subject to a platform’s recommendation logic. Look at how designers like Liz Mosley have built something genuinely resilient: a website, a podcast, templates, resources; an audience that actively follows her work rather than stumbling across it.

Another is to get cited and named, because getting talked about (positively, of course) is the new currency. This means leaning on the channels no algorithm can gatekeep: word of mouth, referrals, events, and real rooms. And in your work, aiming to be a category of one, with a style so specific it gets requested by name rather than retrieved by attribute. The creatives who get asked for by name are the ones that AI can neither replace nor substitute.

Lee Brown, Pinterest’s chief business officer, frames it this way: “The future of discovery won’t be driven by keywords alone. It will be shaped by context, taste, and trusted recommendations.” He’s describing his platform’s perceived advantage. But he’s also, accidentally, describing yours.

A Singaporean software engineer who goes by Airing is writing for devs who can already see the AI curve from inside their own work: docs, code, review comments, all moving faster than the human capacity to verify them. The design translation is pretty direct. AI changes who can produce, but judgment stays human, and the more production accelerates, the more expensive weak judgment gets.

Over the past year, every piece of my work that I could hand off, I handed off to AI, piece by piece. The design doc — it wrote. The code — it wrote. The first drafts of documents and review comments — it wrote. What I can now run in parallel in one evening would have taken a full quarter two years ago. By rights I should be idle, but the truth is the opposite — I am busier than I have ever been. The content of “busy” has simply changed: I almost never produce anything with my own hands now. I spend the whole day reviewing what it produces.

This is the embryo of the end-state workflow. In it, there are only two things left for humans to do: review the design, and verify the result.

Notice what these two have in common: neither of them is production. They are gatekeeping.

That changes the clock as much as the craft: more time spent checking outputs, less time making the first pass by hand.

That gatekeeping word applies to designers too. When AI can generate the interface, the screen, the copy, and the prototype, the remaining work is deciding whether any of it should exist in that form. Airing says the temptation is simple: “lower your own standards.”

Read one fewer line of code. Skip one step of reasoning. Don’t ask one of the “whys.” When the little voice in your head says “eh, probably fine,” nod and let it pass. Project this forward and you can already predict the next few years: nearly every collapse in engineering quality will not be because one specific person was lazy — it will be structural. When production is infinitely fast, the verification standard becomes the only compressible variable in the system, and every incentive in sight pushes you to compress it: the boss’s expectations, your peers’ speed, the performance-review whip — they’re all telling you to let go.

But think clearly about what letting go means. The reason you have not yet been optimized away from the verification step is precisely that your standard is higher than the machine’s. A gatekeeper who keeps lowering the standard is personally building the case for their own replaceability. My stance on this has never moved: slower is fine. The standard, not one inch.

Airing refuses to make this only a productivity story. The professional risk is cognitive atrophy: forwarding the problem to the model, forwarding the answer back, and losing the stretch where judgment is formed. For designers, the warning runs through the same place: don’t outsource the taste-building, the principled refusal, or the logic of why a thing should be this way and not that way.

A real question, most of the time, does not have a deterministic answer. Cognition does not fall from the sky. It is ground out by humans through derivation, argument, and exchange — bit by bit, through a process that cannot be skipped, because that process is the human. If cognition is handed to you directly by AI — whether or not it is comprehensive, whether or not it is critical — the mere absence of that middle stretch of thinking is enough to let subjecthood retreat, inch by inch, until what is left is the silhouette of someone waiting in front of a Jenny to be retired.

AI cannot replace humans in perceiving and experiencing the world — and this isn’t a pep talk; it has a structural basis. I wrote, in an earlier essay on AI and psychological healing: human cognition is not just information processing — it is an experience interwoven from sensation and emotion. We perceive the real world through our bodies; we assign meaning through feeling. AI is unmatched at processing information and generating text, but what it lacks is precisely this dimension of experience — it can process data, but cannot experience the real world that the data represents. In one line: AI’s understanding is instrumental, not existential. It can help us understand certain facets of the human condition, but it cannot replace the insight we obtain through lived experience and inner reflection. A painting can imitate nature, but it can never become nature itself.

The reed’s entire dignity is in its thinking. Please do not hand it over.

The useful thing about this AI layoffs simulator is that it turns an abstract workforce problem into something you can see: if every company cuts workers to save money, fewer people have money to spend.

Raj Nandan Sharma built the interactive page from “The AI Layoff Trap,” an arXiv paper about what happens when many companies automate at the same time. Sharma summarizes the mechanism this way:

Rational, forward-looking firms competing on cost are trapped in an automation arms race. Each captures the full savings of replacing a worker — but bears only 1/N of the resulting collapse in demand. The rest falls on rivals. The race is a dominant strategy. This simulator makes the trap visible as parameters change.

In the default model, each company keeps cutting until about 65% of workers are replaced. The healthier stopping point for the whole market is closer to 35%. That thirty-point gap is the trap.

The default setup is simple: each company has 100 employees, workers earn $50k, only 30% of lost income is replaced, and workers spend half their income at the same local companies. The key moment is when the chart crosses from “this is good for my company” to “this is bad for everyone”:

Past the sweet spot. At 31% automation, profits hit their peak. But every company is still cutting — because each firm saves the full wage bill privately, while only 1/1,000 of the lost demand lands on its own books. Profits are now falling, but still above the starting line.

The policy section gets denser, but the plain-English point is this: helping workers afterward matters, but it does not change why each company keeps cutting. The simulator argues that the cost of the decision has to change too:

Foresight alone cannot prevent the race toward the cliff.

I’ve been broadly bullish about AI, and regular readers here know that. The tools are useful already, and designers who learn to direct them will have a real advantage.

That is why I want to make room for Matthew Butterick’s more pessimistic argument. Butterick is a typographer, writer, programmer, and lawyer who has been directly involved in legal challenges to generative-AI training practices. His argument belongs in the AI conversation precisely because it does not require a rogue model or a Skynet story:

Among AI risks, we should take more seri­ously the poten­tial conse­quences of AI working as intended. AI is a capi­talist instru­ment. Its prin­cipal func­tion is to concen­trate capital. Its intended mech­a­nism is large-scale labor replace­ment. But it is also inher­ently polit­ical tech­nology. As AI makes it harder for workers to capture value from their labor, they will increas­ingly have to rely on goodies from Big AI, priva­tizing what were once func­tions of govern­ment. If Big AI subsumes the func­tions of workers and govern­ment, both will tend to realign polit­i­cally around Big AI’s inter­ests. What­ever term describes this system, it is not liberal democ­racy as US citi­zens have tradi­tion­ally under­stood it. AI-centered capi­talism risks an extinc­tion of demo­c­ratic possi­bility. It will be America. But it will no longer be Amer­ican.

The AI job grief piece was about what happens when old roles stop feeling stable. Sarah Gibbons, writing for Nielsen Norman Group, gets at the next question: what are we actually supposed to call the new work?

When someone says “AI design,” everyone in the room pictures something different.

One person is thinking about using AI to generate component variations for a design system. Another is designing a chat interface. A third is structuring data so an AI agent can parse it. A fourth is defining an LLM’s behavior.

They all fall under “AI design” but they are not the same work.

I see this in job postings, LinkedIn posts, and conference talks. Someone says, “We need to figure out our AI design strategy,” and every person at the table nods — while imagining a completely different thing. Six months later, everyone’s frustrated because the “AI-design initiative” was not what they expected. 

The conversation around AI and design is forking. What used to be a single (admittedly vague) topic has split into at least four distinct orientations. Each one focuses on a different type of design work, sits in different organizational structures, and uses different definitions of what “good” looks like. Most teams are staffed for only one of these orientations, confused about which one they’re doing, or trying to dance between all of them without realizing it.

Gibbons’s agent-facing category moves the taxonomy beyond the human interface:

This one is going to feel like a departure from user experience. Stay with me.

In this type of work, you design content, data, or interactions that AI agents (not humans) will read, parse, or act on. You’re building the infrastructure that autonomous systems navigate. If AI agents are the self-driving cars, you’re designing the roads, the signage, and the lane markings. AI agents are your users.

That might mean structuring product data so a shopping agent can compare options on behalf of a user, writing instructions that an AI assistant will follow, or optimizing content for AI search and discovery instead of (or in addition to) human search and discovery.

Some of this infrastructure won’t even be human-readable. A road sign designed for AI-controlled vehicles might encode information in ways no human driver could parse — data transmitted via radio or embedded in nonvisible parts of the spectrum. The “user” of that sign is an agent, and the design constraints are entirely different.

This is the orientation most design teams are still ignoring, but mostly because many organizations don’t have anyone explicitly responsible for how AI agents experience their product. Which means it’s either not happening, or it’s happening by accident inside an engineering team with no design input.

Designing for AI agents matters because it involves design decisions. What data gets exposed? How is it structured? What can an agent do versus what requires human confirmation? These shape the end-user experience just as much as any interface, they’re just one layer removed.

She then ties that category shift to the market for design expertise:

Understanding which type of AI design you’re building expertise in matters because the market is moving fast. Right now,  few designers have deep experience across multiple orientations. However, this window won’t stay open for long. Within a year, many more designers will have meaningful AI experience. Those who build depth in a specific direction now will have a significant advantage over those who stay broadly “AI-adjacent.”

Here’s where the field is right now:

Most designers today are using AI as a tool in their workflow. A growing number are designing AI products and features. Very few are designing for AI agents or designing the AI itself.

The demand for those last two is growing. The supply of designers who understand them barely exists. So, if you’re a designer, its an opportunity gap that’s widening.

Jack Maguire writes about AI displacement as a grief problem, not only a labor-market problem:

Knowledge workers hold a different relationship to their labor than manufacturing workers did. For a cognitive professional, expertise is not only an activity. It is a large part of the self. A data scientist who has spent a decade building statistical judgment does not experience that judgment as a detachable tool. It is closer to a personality trait. When automation threatens the work, it reaches past the income and touches the identity.

I can certainly relate—my profession is my identity and sense of self, unhealthy as that may be.

Maguire on disenfranchised grief and AI layoffs:

Even where grief exists, workers are denied social permission to feel it, and the denial makes the grief worse.

The relevant concept is disenfranchised grief, a term coined by the grief researcher Kenneth Doka for loss that is not acknowledged or socially supported. As one accessible summary puts it, disenfranchised grief is “grief that is not acknowledged or socially supported, often because the loss does not conform to societal expectations of what should be mourned.” When a loss is not recognized by others, the grieving process stalls, and the grief stays “hidden and unresolved.”

Tech layoffs are engineered to produce exactly this condition. They are framed as strategic pivots, restructurings, and efficiency measures. The language is designed to read as ordinary corporate hygiene, and it forecloses mourning by refusing to name a loss at all. There is no ritual for the end of a profession, no obituary for a career, and no socially sanctioned grief leave for the worker who has watched the meaning drain out of work that technically still pays.

The default cultural model for grief still tends to be the five stages of grief, popularized by psychiatrist Elisabeth Kübler-Ross: denial, anger, bargaining, depression, acceptance. Maguire’s point is that AI displacement does not behave like a bounded loss moving toward acceptance:

The Kübler-Ross framework assumes that acceptance is reachable, because the loss it was built to describe is finite. When a person dies, the absence becomes permanent. The bereaved adjusts to a stable, if painful, new reality. Acceptance is possible because there is something fixed to accept.

AI displacement does not offer a fixed endpoint. The process is ongoing and accelerating, with no stable post-AI equilibrium to adapt to. A worker who retrains into the safe role of this year may find that role automated within two years. There is no permanent absence to grieve, only a moving frontier. Workers are being asked to accept a process rather than an outcome, and the process keeps advancing.

Simon Willison thinks the AI labs have found product-market fit. Here’s his own monthly usage priced at API rates against the $200 he actually pays:

• $1,199.79 for Anthropic Claude Code
• $980.37 for OpenAI Codex

That’s $2,180.16 worth of tokens for $200—not bad at all! I’m a moderately heavy user of these tools, but I’m certainly not running agents every hour of the day and night.

That discount is gone: since April 2026 enterprises pay full API rates. Willison’s read:

Coding agents really did change everything. These are tools which burn vastly more tokens, but are also quickly becoming daily drivers for the work carried out by extremely well-compensated professionals. Right now that’s still mostly software engineers, but a coding agent is a tool that can automate anything you can do by typing commands into a computer… so they are clearly applicable to a much wider set of skilled knowledge workers.

Right now the bill falls on engineers. Designers may be next. Anthropic has already rolled out a separate usage meter for Claude Design. And Figma is charging for AI usage overages.

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.

Dan Shipper, CEO of Every, has spent the last few years running his company as an early-adopter lab for AI tooling. The report from inside is that aggressive automation has not shrunk the team. The work has changed shape, but the volume of expert human work has gone up, not down. The reason, Shipper argues, is structural.

Slop is not any one particular mistake. It is not the use of em dashes, or a certain sentence rhythm, or purple accents on a landing page. Slop is visible sameness, repeated ad nauseam. It is what gets produced by default when humans in many different circumstances use the same tool, trained on the same corpus, without thinking too hard. It is what happens when everyone has access to an expert who has the same default tendencies. When someone in operations can issue a pull request, marketers can create YouTube thumbnails in seconds, or engineers are writing product guides, it’s easy to end up in a world where your output has gone up—but the quality, coherence, and differentiation of what you’re producing has dropped.

Sameness as the failure mode lines up with what BetterUp Labs researcher Kate Niederhoffer and her co-authors named workslop: AI-polished output that shifts the burden of judgment downstream onto whoever has to interpret, correct, or redo it. Shipper’s contribution is to follow the mechanism one more turn: once everyone is producing the same default output, the work that doesn’t look like the default becomes the scarce thing. Difference becomes the new status game, and difference has to come from a human who is alive to this moment, this customer, this codebase, this conversation.

The second half pushes the same logic up to AGI. Shipper on why even AGI doesn’t escape the loop:

In any hypothetical AGI built by any of the major labs, there is still going to be a framer—a human—directing the model to achieve a goal. And because the frame is not the framer, we’ll see the same pattern repeat: AI turns yesterday’s framed competence into something cheap; people use that cheap competence in more places; the results become abundant; experts move to the edge to decide what matters now; their judgment creates the next frame; and then the model climbs that, too.

At the end, Shipper drops the analytical voice and writes:

The race is over. You can almost feel your muscles beginning to atrophy, useless in the face of this mechanical copy of you and everyone you’ve ever met, of the whole of humanity. A ghost chasing a ghost, and winning. But then something strange happens. The model turns to you. Your cursor blinks, off and on, in the blank text box, expectantly. Waiting.

According to Harvard Law School, Eric Ries tells Lenny Rachitsky, only 20% of venture-backed founders are still CEO three years after going public. Every founder gets told by their lawyers, bankers, and VCs that they’re the exception. Statistically, they’re not. Ries, author of the Silicon Valley textbook The Lean Startup, treats this as a structural problem with a structural answer in his new book Incorruptible. The analogy he spins:

This is like you’re building a bridge. And if your bridge collapses, and Lenny, I say you’re an engineer, and I say, “Lenny, why did my bridge collapse?” If you’re like, “Well, ‘cause of gravity.” I’m gonna be like, “Dude, yeah. Thank you for that genius insight, right?” […] I call it financial gravity. […] Yeah, but I want to know why did this bridge collapse? And more importantly, how come other bridges didn’t collapse? And they say, “Oh, for that, we need to study the load, load factor, wind load, shearing tension.” And we go look up close. We say, “Oh, look, all the metal bolts have been corroded.” They’re rusted. No wonder it collapsed. And then if you say, “Well, I want to build a new bridge, but I don’t want this one to collapse. What can I do?” You won’t say, “Well, gravity, what can you do?” No. You say, “Why don’t we use stainless steel next time on the bolts so they don’t get corroded?” Oh, yeah, good idea. So this book is about what are the organizational equivalents of stainless steel?

This is the move that makes Incorruptible a design book. Most writing about founder ouster and mission drift treats those outcomes as moral failures: bad people taking shortcuts or unlucky breaks in the market. Ries refuses that. Corrosion is predictable. Stainless steel is a material choice. Your bolts are going to rust unless you specified otherwise before pouring the foundation. The governance documents a founder signs in year one are the structure of the company itself. And the people advising them on those documents (the lawyers, the bankers, the VCs) are not the people who will be standing on the bridge in year ten.

Ries on a related diagnosis:

I could tell that this restaurant got taken over by private equity. I could taste it. And I’ve told that story a bunch of times now. And so many different people have told me, “Oh yeah, I know what restaurant you’re talking about!” And then they name like 12 different restaurants. So what’s going on that like you can taste the ownership structure of a company in the food? How many people have had a famous brand that they love get ruined? […] all kinds of famous companies where the thing that destroyed them was not competition. It was not someone else came up with a better product. No, their very success became a liability because the more gold in the goose, the greater the temptation to butcher.

You can taste the ownership structure in the food. That’s a designer’s instinct, even if Ries doesn’t call it that. It’s the same thing that tells you, holding a product, whether the team that built it still cares, and whether anyone at the top is protecting the people who do. The Sonos app rewrite that wiped half a billion in market value came from decisions inside the company about what to ship and who got protected. The bridge was already corroding. Ries is arguing that the protection has to be installed early, before there’s anything worth butchering. That’s design work, in the most literal sense.

Ries is a captivating storyteller in this episode. I can’t wait to get my hands on his new book.

Peter Yang spent the last few months running OpenClaw, Hermes, Claude Code, Codex, and Gemini through ten capabilities he thinks a personal AI agent needs to handle. The headline is in his subtitle: nobody has won yet.

Yang on OpenClaw, an open-source personal-agent platform:

I estimate that 10% of my time with OpenClaw is spent fixing it instead of using it. Examples: It forgot it had access to edit Google Docs. It randomly started using a robot voice instead of the one I like. It breaks half the time after every update.

He switched to Hermes (a newer personal-agent platform from Nous Research) anyway:

If OpenClaw’s maintenance tax is wearing you down, give Hermes a try. A week in, it’s been more reliable for me.

Yang’s full comparison of Claude Code, Codex, and Gemini—plus the stack he ends up running—is in the post. His advice for the rest of us:

Pick one or two agents that work for you based on the pros and cons above and just commit.

His promise to anyone who picks one and stays:

Once you have an agent that’s available 24/7 and can actually get work done for you, you’ll never go back to a regular AI chat interface again.

The terminal’s return as a serious surface for new tools (Claude Code, Codex, Omarchy) has mostly been read as a developer aesthetic story. Alcides Fonseca reads it as the receipt for thirty years of GUI toolkit churn. He walks the platforms one by one (Windows, Linux, macOS), then through Electron, then through the failed restarts (Google’s Flutter UI, Zed’s GPUI), and ends on TUIs as the place developers go when none of the layers above hold up.

Fonseca on macOS:

Apple used to be a one-book religion. Apple’s Human Interface Guidelines used to be cited by every User Interface course over the world. Xerox PARC and Apple were the two institutions that studied what it means to have a good human interface. Fast forward a few decades, and Apple is doing the best worst it can to break all the guidelines and consistency it was known for.

This isn’t a nostalgia complaint. Fonseca lists the live breaks (Fitts’ law getting ignored, the Tahoe window-resizing saga that didn’t stay fixed, the icons cluttering Apple menus) and treats them as the same class of failure as Microsoft’s WinForms-WPF-Silverlight-WinUI-MAUI parade. The mechanism differs but the outcome is the same: the platform stops being a place a designer can rely on.

Fonseca on Electron:

Looking at my dock, I have 8 native apps (text mate and macOS system utilities) and 6 electron apps (Slack, Discord, Mattermost, VScode, Cursor, Plexampp). And that’s from someone who really wishes he could avoid having any electron app at all. […] These are actions that should be the same across every macOS application, and even if there are shortcuts, they are not announced in the menus.

The dock count is the right way to measure it. RAM is the visible cost of Electron; the invisible cost is that every Electron app becomes its own little keyboard regime, with shortcuts that often don’t match the rest of the system and aren’t announced in menus when they do exist. Fonseca’s Cursor example (can you keyboard from the agent panel to the agent list and archive an item) is the kind of question any pre-Electron Mac app would have answered yes to. Most Electron apps answer maybe, with a shortcut their vendor invented.

His prescription that follows (make HCI mandatory in CS curricula, fail student projects with bad UIs, push OS vendors to invest in toolkits developers want to use) is correct in shape and probably wrong about leverage. Students aren’t the bottleneck. Apple and Microsoft have already read Norman. TUIs are back because the platforms quit, and the curriculum can’t fix that.

Fonseca’s diagnosis is right. The prescription is narrower. The TUI escape hatch works for developers because their work is text. Designers don’t get the same exit when the canvas is the medium itself.

Bonus: Speaking of TUIs, TUIStudio is a macOS app for designing terminal UIs, just like Figma!

George Anders, in the Wall Street Journal, makes the case that the 1920s offer a usable template for the AI decade. His strongest evidence is the spillover-jobs data:

By 1930, more than 80,000 people were working as electricians, a profession that hardly existed a decade before. Census data also showed that 168,000 people were working in rubber factories, most of them making tires to accommodate Detroit’s booming production of cars, trucks and buses. Another 450,000 people were building roads, bridges and other structures needed by the ever expanding auto industry.

The ATM parable had the same problem: the version that ends in 2010, with bank-teller employment intact, is the one we love to retell. The version that ends in 2022, with teller jobs cut in half by the iPhone, is the one we leave out. Anders’s 80,000 electricians are real. So is the question of which of them got displaced when the next technology arrived.

Anders does, to his credit, take the costs seriously. He spends a section on the radio fight:

In 1927, H.G. Wells, the British author and intellectual, called radio “inferior” entertainment that should be listened to “only by the sick, the lonely and the suffering.” David Sarnoff, general manager of Radio Corp. of America, shot back that he was trying to improve “the happiness of the nation” by delivering popular music to millions of people. Nearly a century later, that same argument still flares, though now it is more likely to involve TikTok, Reddit or YouTube, instead of dear old radio. The doubters always have a point; with the passage of time, the innovators usually win out.

The early evidence on AI’s job-creation side is thinner than the 1920s comparison flatters: Anthropic’s own researchers find a 14% drop in the job-finding rate for 22-to-25-year-olds in exposed occupations since ChatGPT launched, even as overall unemployment holds. The new electricians of our decade may exist. They just may not be the people getting hired right now.

The safety side of Anders’s case is the one I want to see more of. Cars in 1920 killed at twenty times today’s per-mile rate, and the country chose not to live with that:

Auto safety got better, too, with both industry and government taking action. Better mirrors, better brakes and shatterproof windshields became standard. Cities such as Los Angeles and Detroit installed red-yellow-green traffic lights that governed drivers’ actions on busy streets. New Jersey became the first state to insist on driver’s licenses, with the state’s motor-vehicle commissioner in 1924 declaring: “It is an absolute necessity to do this in order to conserve human life.”

Whether the next century treats our decade as kindly depends on whether we put rearview mirrors and traffic lights on AI before the death rates make us, and whether we do it under the same kind of duress the 1920s did.

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.

Obviously, I’ve been pro-AI on this blog, actively trying to understand and figure out how it’s affecting UX design and how to use it for leverage instead of being replaced by it. In Silicon Valley and tech companies everywhere, including BuildOps, we’re racing to incorporate AI into our daily work to increase velocity, and adding it to our products to stay relevant.

Nilay Patel, in a Decoder monologue, lays out the polling that should rattle anyone shipping AI products:

There’s that NBC News poll showing AI with worse favorables than ICE, and only a little bit above the war in Iran and Democrats generally. That’s what the nearly two-thirds of respondents saying they’d used ChatGPT or Copilot in the last month. Quinnipiac just found that over half of Americans think AI will do more harm than good. Well, more than 80% of people were either very concerned or somewhat concerned about the technology. Only 35% of people were excited about it. And poll after poll shows that Gen Z uses AI the most and has the most negative feelings about it. A recent Gallup poll found that only 18% of Gen Z was hopeful about AI, down from an already bad 27% last year. At the same time, anger is growing. 31% of those Gen Z respondents said they feel angry about AI, up from 22% last year.

The killer detail is buried halfway through. The Gen Z curve is striking: heaviest users, and yet the fastest to sour. Anger is up nine points in a year. These aren’t non-users reacting to coverage. They’re the daily customers, and the answer is no. Sam Altman has called this AI’s marketing problem. The polling rebuts him: public exposure has grown, public favor has not.

Patel’s title line:

Regular people don’t see the opportunity to write code as an opportunity at all. The people do not yearn for automation. I’m a full-on smart home sicko. The lights and shades and climate controls of this house are automated in dozens of ways, but huge companies like Apple and Google and Amazon have struggled for over a decade now to make regular care about smart home automation, and they just don’t. AI isn’t gonna fix that.

Patel grounds the title in his own smart-home enthusiasm, and the comparison clicks because the failure pattern is identical: decade-plus of effort, billions in marketing, working products, and persistent indifference. Apple, Google, and Amazon ran that experiment. AI will not crack a problem that smart-home automation hasn’t.

John Gruber connects the same dissonance to the Mos Eisley cantina from Star Wars. Luke walks in with C-3PO and R2-D2. The bartender, Wuher, barks: “We don’t serve their kind here. Your droids. They’ll have to wait outside.” Gruber:

As a kid, I didn’t get it. Why would you not want droids? Star Wars made robots seem so real, so fun. Why would you ban them? That scene has stuck with me for my entire life. I didn’t get why, but I understood what it meant about that galaxy: the underclass deeply resented droids.

Gruber leaves the question open. He says he didn’t get why the droids weren’t welcome. The cantina’s animosity wasn’t arbitrary. Mos Eisley sits in the Outer Rim, where droid armies killed millions and occupied worlds during the Clone Wars. After the war, droids became a subjugated worker class across the galaxy, and Outer Rim spots like Mos Eisley held the line hardest. Wuher’s verdict comes from experience.

That’s the parallel for AI. Public distrust is earned. People have lived with AI overviews getting facts wrong and feeds drowning in slop, while every product asks them to bend a little more toward the database. Patel:

And so the tech industry is rushing forward to put AI everywhere at enormous cost, energy, emissions, manufacturing capacity, the ability to buy RAM locked into the narrow framework of software brain, without realizing they are also asking people to be fundamentally less human. And then they’re sitting around, wondering why everyone hates them. I don’t think a couple haircuts are gonna fix it.

As an industry, we need to continue to show the value of AI by being truly useful, not just market it.

In design circles, the AI debate splits into two responses: principled resistance and principled engagement. Dan Cohen offers a third: historical context.

Writing for Humane Ingenuity, Cohen uses Tracy Kidder’s The Soul of a New Machine—the 1981 Pulitzer-winning account of Data General’s minicomputer team—as a mirror for the current moment. He opens with a scene that reads like a 2026 AI company profile before revealing it’s from 1979:

A crack team of hardware and software engineers, inspired by breakthroughs in computer science and electrical engineering, are driven to work 18-hour days, seven days a week, on a revolutionary new system. The system’s capabilities and speed will usher in a new era, one that will bring transformative computing to every workplace. The long hours are necessary: the team knows that every major computer company sees what they see on the horizon, and they too are working around the clock to take advantage of powerful new chips and innovative information architectures.

The team is almost entirely men, men whose affect and social skills cluster in a rather narrow band, although they are led by a charismatic figure who knows how to persuade both computer engineers and capitalists. This is a helpful skill. Money, big money, is flowing into the sector; soon it will overflow. Engineers are constantly poached by rival companies. Hundreds of new competitors arise to build variations on the same system, or to write software or build hardware that can take advantage of this next wave of computing power. Some just want to repackage what the computer vendors produce, or act as consultants to the companies that adopt these new machines.

Sounds a bit like today’s Silicon Valley 996 culture, but that’s Data General in 1979. The team also worried about the Pentagon weaponizing their machine, job displacement, and whether their work might eventually produce true AI and destroy humanity. Those concerns date to 1979.

Cohen’s argument is about scale: the minicomputer moved millions of companies from paper to digital for the very first time; that was a genuine revolution. AI, he argues, is improving workflows that are already digital. His question: is that the same order of disruption?

Carl Alsing, one of the engineers who built the Eagle, told Kidder when asked about artificial intelligence:

“Artificial intelligence takes you away from your own trip. What you want to do is look at the wheels of the machine and if you like them, have fun.”

Cohen closes with the historical outcome:

In the 1980s, most of the minicomputer companies, launched with such excitement in the late 1970s, failed. Data General was acquired for a fraction of the billions it was once worth. The minicomputer, however, was broadly adopted, was transformative, became routine, and then was surpassed by a new new machine, the personal computer.

Later, Data General’s domain name, DG.com, was sold to a chain of discount stores, Dollar General.

“Slop cannons” is Darragh Curran’s term for the fear that AI-generated code will degrade craft. The fear is real. The same fear runs through design: AI-generated interfaces will be derivative, generic, indistinguishable from each other. Curran is Intercom’s CTO, and he published a detailed report on what happened when Intercom went agent-first across their entire R&D org. The result: 3x productivity in 16 months, tracked across nine metrics. The code quality results were not what anyone expected.

Curran:

A legitimate worry with the use of coding Agents, is that they won’t write high-quality code and the craft we’ve fought to protect will be undermined by slop cannons. We have a system to rate the structural quality of code contributions using static analysis and various rules/heuristics. It’s clear that prior to agentic coding, this metric would oscillate up and down above the line. As we started to use AI for writing more and more of our code, the overall quality (by this measure) declined. My intuition was that this was inevitable in the short term, but correctable in the medium term, as models and harnesses get better. We are starting to see this and recently had possibly our first ever five-week streak of net positive code quality overall.

Quality did dip. He confirms it. The slop cannon fear describes a real phase: at 93.6% agent-driven PRs, when agent-generated code degrades, the whole org feels it. But there’s a second finding:

There is huge latent potential. Some people are really pushing the limit of what is possible, tokenmaxxing, doing really interesting things, while others have only really made incremental changes to how they’re working and don’t see much change in their personal throughput. Ultimately one of the biggest bottlenecks to progress is with humans; how we work together, how we change behavior, etc.

Intercom’s top 5% of contributors produce 6x the median PR throughput. Those are the people spending over $1,000 a month on tokens. That spread is the real finding from going agent-first. The slop cannon fear is about whether agents can execute well. The 6x gap is about who’s learned to orchestrate them, and Curran’s candid that most of his org is still finding out.

For design, we worry about going too fast, of solving the wrong problem, and building the wrong thing. Those are legitimate fears. Nonetheless, if you’re working in startupland as a designer, acceleration and automation are coming.

Ant Murphy opens with an eyebrow-raising McKinsey number:

McKinsey reports that 88% of organisations say they “use AI” but only about 1% have mature AI deployments delivering real value.

Murphy’s explanation for the gap is familiar: the diffusion of innovation, Geoffrey Moore’s chasm between early adopters and the majority, now applied to AI. What’s less common in the AI discourse is a behavioral explanation for why the adoption keeps stalling. Murphy:

AI is personal. It’s not another tool, to some it’s viewed as a replacement. “AI attacks our identity in a way that most software doesn’t” — Vikram Sreekanti

That resistance shows up in the record: a friend’s “I didn’t sign up for this”. Claire Vo described designers as the most resistant to change in the EPD triad, vocal AI opponents with little appetite for campaigning for resources. None of it is irrational. Daniel Kahneman and Amos Tversky found that humans weigh losses about twice as heavily as equivalent gains. Years of accumulated craft become our identity. AI doesn’t ask you to learn new tools; it asks you to renegotiate what made you worth hiring in the first place. The reskilling conversation treats that as a capability problem. Identity problems don’t resolve themselves through training on new tools.

Murphy on what that requires:

Surviving a paradigm shift like this is less about what your product does […] Instead it’s about you adapting to the change.

The 88% are held back by what AI is asking them to let go of. Murphy’s argument is that organizations clearing the chasm are doing the internal work first—on process, on how teams function—before it shows up in the product.

There’s an old relationship adage that you can’t be a good partner to someone until you’ve worked out your own stuff first. I think Murphy’s argument is the organizational equivalent.