Eugene O’Neill had a line: “Critics? I love every bone in their heads.” I think about it whenever someone proposes that what design really needs is more people who understand it without doing it.

Jon Kolko, writing for Interactions Magazine, argues that design is experiencing a disciplinary “turn”—away from making and toward literacy. Drawing on Richard Buchanan’s 1992 framework of design as a “liberal art of technological culture,” he proposes a future with fewer practitioners and more people who can read, critique, and discuss designed artifacts without designing them.

Rather than viewing design as an applied craft, a liberal art of technological culture recasts design as a way of understanding our role in the designed world around us. It’s difficult for many practitioners to imagine this, because making things is so integral to the idea of design, and embedding design in the humanities is very different from viewing it as an organizing principle like the humanities. But if design is not about making things, but instead about understanding the things that are made, vocation is no longer a goal of design education.

Kolko’s diagnosis is sharp—the layoffs, the AI anxiety, the assembly-line feeling of modern product design. And he sits with the discomfort rather than cheerleading:

As a craftsperson and a maker, I don’t like the way this turn feels, because it appears threatening to the fundamentals of the profession. Understanding design without making things seems impossible. I don’t like this development as an educator either, because it means my students, trained to be practitioners, may find no design jobs, despite getting a very expensive education. But as someone observing the various trends chipping away at what is actually meaningful about being a designer—our ability to humanize the dysfunction of technological change—I am drawn to this turn.

I respect the honesty. But I have a love/hate relationship with critics. It’s easy to throw stones from a perch. When you’re in it—fighting organizational politics, staring at data, listening to customers, compromising with engineering—the outcomes are never as clean as you’d hoped. Design literacy matters. But literacy divorced from practice produces critics, not designers. The world doesn’t need more critics. It needs more people who understand why the compromises were made via lived experience.

I believe in the shokunin mentality. Obsessive iteration, pursuing mastery across decades. But the designers building at the frontier right now are telling a different story.

Mark Wilson, writing for Fast Company, visited Cursor, Anthropic, OpenAI, and Krea in San Francisco. Former Apple designer Jason Yuan, now building his own AI startup:

“You can’t do the old school Apple thing of like, create lickable craft and interface. You can’t because, by the time you’ve done the best interface for ChatGPT 3, you’re on GPT 6.”

That stings a little. The Apple tradition assumes the target holds still long enough to polish. When the platform shifts every few months, polish is a liability.

Anthropic’s head of design Joel Lewenstein is making the same bet:

“Things are moving so fast that we just have to experiment faster. Convergence is hard. Because you have to figure out what’s shared. You have to build that shared path. You have all of the fringe things that people loved on these other systems. And there’s too much changing too quickly.”

Anthropic built Cowork in five or 10 days (depending on who you ask). Ship first, converge later.

What’s telling is who’s embracing this. Yuan and Abs Chowdhury—both former Apple designers, trained in the tradition of lickable craft—have each gone all-in on vibecoding at their startups. Chowdhury transferred rough designs from Photoshop(!) straight into AI code tools. Yuan built his first product mostly alongside AI:

“There’s a new reason to raise lots of money, which is compute. If you have lots of conviction, and you know exactly what you want, like, why would you hire another 20 other people right now to tell you what you’re doing? It’s a coordination cost.”

Yuan calls this the best time to be an “auteur.” The designer who doesn’t wait for engineering to realize the vision, who directs AI the way a film director directs a crew. It’s the orchestrator gap playing out in real time.

I’m not ready to abandon the shokunin mentality. But I’m starting to think the object of obsession needs to shift, from polishing pixels to refining judgment. The craft isn’t in the surface anymore. It’s in knowing what to build.

Wilson’s full piece covers a dozen people across the industry and is worth reading end to end.

Designers are builders by nature. We break problems apart, iterate through uncertainty, and treat process itself as something to be shaped. That instinct is exactly what Pete Pachal, writing for Fast Company, identifies as the dividing line in the age of agents:

We’ve trained a generation of office workers to work within software with clear boundaries and reusable templates. If there’s an issue, they call IT. Any feature request gets filtered and, if you’re lucky, put on a roadmap that pushes it out 6-12 months.

In short, most people don’t have a builder mentality to begin with, and expecting them to suddenly be comfortable working and creating with agents is unrealistic.

Pachal draws the line at mindset, not coding ability:

Builders don’t need to be coders, but they do have characteristics that most workers don’t: They seek to understand the process beneath their tasks, and treat that process as modifiable and programmable. More importantly, they see failure and iteration as tolerable, even fun. They thrive in uncertainty.

That’s the design process. What Pachal frames as rare in the broader workforce is default operating mode for most designers. We want to make things. We fiddle with tools and rebuild workflows for fun. The builder mentality isn’t something designers need to acquire; it’s the reason most of us got into this field.

Pachal again:

You don’t have to build agents to matter in an agent-driven workplace. But you do have to understand the systems being built around you, because soon enough, your job will be defined by defaults someone else designed. Most professionals will not build agents. But everyone will work inside systems builders create.

Pachal is describing the orchestrator gap at scale, not just in design but across all knowledge work. And it suggests designers are uniquely positioned to be on the right side of it. Shaping how people interact with systems has always been the job description.

I’ve rebuilt my personal website more times than I can count. The tools and platforms change; the principle doesn’t: I own my content, and nobody gets to take it away. I have a Substack, but it’s a digest, a syndication channel. The canonical content lives on my site, on my domain. My website can’t be enshittified by anyone but me.

Henry Desroches makes the case through Ivan Illich’s Tools for Conviviality:

In his book Tools For Conviviality, technology philosopher and social critic Ivan Illich identifies these two critical moments, the optimistic arrival & the deadening industrialization, as watersheds of technological advent. Tools are first created to enhance our capacities to spend our energy more freely and in turn spend our days more freely, but as their industrialization increases, their manipulation & usurpation of society increases in tow.

Illich also describes the concept of radical monopoly, which is that point where a technological tool is so dominant that people are excluded from society unless they become its users. We saw this with the automobile, we saw it with the internet, and we even see it with social media.

That’s social media in one paragraph. You don’t join Instagram because you want to; you join because opting out means opting out of the conversation. Desroches argues personal websites are the answer:

Hand-coded, syndicated, and above all personal websites are exemplary: They let users of the internet to be autonomous, experiment, have ownership, learn, share, find god, find love, find purpose. Bespoke, endlessly tweaked, eternally redesigned, built-in-public, surprising UI and delightful UX. The personal website is a staunch undying answer to everything the corporate and industrial web has taken from us.

The practical argument is strong enough on its own. Own your content. Own your platform. Syndicate outward. The moment you frame it as reclaiming the soul of the internet, you lose the people who most need to hear the boring version: just put your stuff on a domain you control.

The behavioral gap, the calcified companies, the startups shipping while incumbents argue about roadmap slides: there’s an economic force underneath all of it. Andy Coenen names it. He picks up from Matt Shumer’s “Something Big Is Happening“ and builds the case that we’re living through a Software Industrial Revolution, where the cost of producing software collapses the way textiles did in the 18th century.

His thesis on what survives the cost collapse:

Because while the act of building software will fundamentally change, software engineering has never really been about producing code. It’s about understanding and modeling domains, managing complexity (especially over time), and the dynamic interplay between software and the real world as the system evolves. And while the ability to produce code by hand is rapidly becoming irrelevant, the core skills of software engineering will only become more important as we radically scale up the amount of software in the world.

Replace “software engineering” with “product design” and “producing code” with “producing mockups” and you have the argument I made in Product Design Is Changing. The artifact was never the job. The judgment was.

Coenen again, on what abundance looks like in practice:

My friend, Dr. Steve Blum, is a brilliant cancer researcher. Steve’s work deals with massive amounts of data, and analyzing that data is a major bottleneck. But writing software to do so is extremely difficult, and there’s no world where Steve’s limited attention ought to be spent on python venv management.

The Software Industrial Revolution means that Dr. Blum and thousands of his colleagues have all, suddenly, almost magically, been given massive new leverage via the ability to conjure up almost any tool imaginable, on demand. This is like giving every cancer researcher in the world a team of world-class software engineers on staff overnight, for less than the price of Netflix. Frankly, I think this is nothing short of miraculous.

Now do that thought experiment for design. Every small business owner who needs a custom tool, every nonprofit that can’t afford a design team. The Industrial Revolution didn’t just make cloth cheap. It made good cloth cheap. That’s the part designers should be paying attention to.

Darragh Curran’s 2× goal reads like a halftime speech. We can do this. The tools are here. The gap is behavioral. Double your output in twelve months.

Claire Vo wrote the post-game report:

If AI adoption had 7 stages of grief, almost all of you would be in denial. No matter how many AI memos your CEO sends, the amount of Claude that’s being Coded, the chatbots in app and the evals in data—I’m here to tell you: you’re not competing. In fact, you probably can’t anymore.

Vo’s target is the company that thinks it’s adapting: AI features shipped, internal power users, a natural-language interface named after a gem. She’s not buying it:

While they try on the bows and ribbons of an AI-native team, they ignore the fact that their bones are old and the company has calcified. For the most part: sales still sells the same and marketing is still talking about channels and CAC and product says “prioritize” and eng says “capacity” and the board is endlessly asking either about Q1 perf and Q2 projections or the ever-elusive “increase in product velocity.”

“Bows and ribbons” versus “bones.” That’s the whole post in one sentence.

I have some sympathy for the incumbents, though. Vo’s startup-swagger framing undersells how much gravitational pull a $100M business carries. Enterprise contracts, compliance obligations, a customer base that didn’t sign up for a pivot. The companies she’s diagnosing aren’t stupid. They’re heavy. And heavy things don’t accelerate the same way light things do, even when both see the cliff.

None of that makes her wrong. It just means even the companies that want to change are fighting physics. But they’ll have to figure it out sooner than later.

Every few weeks another engineering leader publishes their AI productivity manifesto. Most read like press releases. Darragh Curran, Intercom’s CTO, argued it isn’t about the tools:

If we were to literally hit pause on further advancements, I’m convinced any engineering team just leveraging the already existing tools effectively should expect at least double their current productivity – a 2x improvement. Yet most people and teams in the industry at large are not getting close to this today, they aren’t trying, and they probably don’t believe it’s possible, and even if they do, behavior change is hard and the forces or incentives aren’t clear yet.

(By the way, he wrote this in mid-2025. Given how much better the latest models are, I’m sure the number is higher now.)

The tools are good enough. The gap is behavioral. Engineers got good AI tooling early and had clear on-ramps. For designers, the tooling is fragmented and many in the profession are still debating whether AI belongs in the process at all.

Curran makes the economic case:

It’s worth noting this is an entirely different vector to “just hire more people”. Even if we allocated the budget to hire 2x as many people, at our scale, it’s highly improbable we’d double our team size in 12 months. Even if we did, that’d come at huge cost and tradeoffs, hiring and onboarding takes time and carries risk, so we’d be slower for a year or two hoping to then catch up.

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

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

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

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

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

Sten on the broader shift in thinking:

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

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

Why AI isn’t showing up in productivity data? Chetan Dube offers one answer in Fast Company: most companies are bolting AI onto existing roles instead of redesigning the work.

Most managers are using AI the same way they use any productivity tool: to move faster. It summarizes meetings, drafts responses, and clears small tasks off the plate. That helps, but it misses the real shift. The real change begins when AI stops assisting and starts acting. When systems resolve issues, trigger workflows, and make routine decisions without human involvement, the work itself changes. And when the work changes, the job has to change too.

McKinsey data backs this up—78% of organizations now use AI in at least one function, “though some are still applying it on top of existing roles rather than redesigning work around it.” That’s the Solow paradox in one sentence.

Dube’s lost luggage example is a good one:

Generative AI can explain what steps to take to recover a lost bag. Agentic AI aims to actually find the bag, reroute it, and deliver it. The person that was working in lost luggage, doing these easily automated tasks, can now be freed to become more of a concierge for these disgruntled passengers.

The job goes from processing to judgment. And if leaders don’t get ahead of it:

If leaders don’t redesign the job intentionally, it will be redesigned for them, by the technology, by urgent failures, and by the slow erosion of clarity inside their teams.

That slow erosion of clarity is already visible. People less and less sure what they’re supposed to be doing because the tasks they were hired for are quietly handled by a system nobody put in charge.

In 1987, Robert Solow looked at the computer revolution and observed: “You can see the computer age everywhere but in the productivity statistics.” Nearly 40 years later, Apollo chief economist Torsten Slok is making the same observation about AI. Sasha Rogelberg reports in Fortune on new data that makes the parallel hard to ignore.

Among 6,000 executives surveyed, 90% said AI has had no impact on employment or productivity over the last three years. Average executive AI usage: 1.5 hours a week. That’s barely trying.

Slok, echoing Solow:

AI is everywhere except in the incoming macroeconomic data. Today, you don’t see AI in the employment data, productivity data, or inflation data.

The Solow paradox eventually resolved itself. Computers didn’t show up in productivity stats until the mid-1990s—decades after they entered the workplace. The technology arrived long before organizations figured out how to restructure around it.

Slok sees the same pattern forming:

The value creation is not the product, but how generative AI is used and implemented in different sectors in the economy.

That’s the part most companies are skipping. They’re giving employees an AI chatbot and expecting the productivity graph to move. The companies where AI is actually changing output are the ones rethinking their workflows. Most stall at the tooling.

If the Solow parallel holds, the productivity gains are coming. They’ll show up first in the companies that did the reorganization. I have a feeling that this Claude Code trend is going to hold and show up in stats next year.

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

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

He’s right. They do work.

Lawson again:

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

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

Lawson on economic gravity:

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

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

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

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

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

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

He describes what drove the wedge:

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

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

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

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

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

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

In a Jason Lemkin piece on SaaStr, Intercom CPO Paul Adams describes what happened to his design team over the last 18 months:

Every single designer at Intercom now ships code to production. Zero did 18 months ago. The mandate was clear: this is now part of your job. If you don’t like it, find somewhere that doesn’t require it, and they’ll hire designers who love the idea.

Not a pilot program nor an optional workshop. It was a mandate. Adams basically said, “This is your job now, or it isn’t your job here anymore.” (I do note the language here is indifferent to the real human cost.)

But the designers-shipping-code mandate is one piece of a larger consolidation. Adams applies a simple test across the entire org: what would a brand new startup incorporated today do here?

Would they have separate product marketers and content marketers? Or is that the same job now? Would they have both product managers and product designers as distinct roles? The answer usually points to consolidation, not specialization.

There it is again, the compression of roles.

But Adams isn’t just asking the question. He took over two-thirds of Intercom’s marketing six months ago and rebuilt it from scratch—teams, roadmaps, calendars, gone.

All of the above is a glimpse of what Matt Shumer was talking about in “Something Big Is Happening.”

The way the product gets built has changed too. Adams describes Intercom’s old process versus the new one:

The old way: Pick a job to be done → Listen to customers → Design a solution → Build and ship. Execution was certain. Technology was stable. Design was the hard part. The new way: Ask what AI makes possible → Prototype to see if you can build it reliably → Build the UX later → Ship → Learn at scale.

“Build the UX later” is a scary thought, isn’t it? In many ways, we must unlearn what we have learned, to quote Yoda. Honestly though, that’s easier said than done and is highly dependent on how forgiving your userbase is.

Jeff Bezos introduced the two-pizza rule in 2002: if a team needs more than two pizzas to eat, it’s too big. It became gospel for how to organize product teams. Dan Shipper thinks the number just got a lot smaller:

We have four software products, each run by a single person. Ninety-nine percent of our code is written by AI agents. Overall, we have six business units with just 20 full-time employees.

Two pizzas down to two slices. Two slices per person. One person per product. And these aren’t demos or side projects. Shipper’s numbers on one of them:

Monologue, our smart dictation app run by Naveen Naidu, is used about 30,000 times a day to transcribe 1.5 million words. The codebase totals 143,000 lines of code and Naveen’s written almost every single line of it himself with the help of Codex and Opus.

A year ago that would have been a team of four or five engineers plus a PM plus a designer. Shipper himself built a separate product—a Markdown editor—and describes the compression:

An editor like this would have previously taken 3-4 engineers six months to build. Instead, I made it in my spare time.

“In my spare time” is doing a lot of work in that sentence. This is what the small teams, big leverage argument looks like when you stop theorizing and start counting.

I sent this article to both of my kids this week. My daughter is in college studying publishing. My son is a high school senior planning to go into real estate. Neither of them works in tech. That’s exactly why they need to read it.

Matt Shumer has spent six years building an AI startup and investing in the space. He wrote this piece for the people in his life who keep asking “so what’s the deal with AI?”—and getting the sanitized answer:

I keep giving them the polite version. The cocktail-party version. Because the honest version sounds like I’ve lost my mind. And for a while, I told myself that was a good enough reason to keep what’s truly happening to myself. But the gap between what I’ve been saying and what is actually happening has gotten far too big. The people I care about deserve to hear what is coming, even if it sounds crazy.

I know this feeling. I wrote yesterday about how AI is collapsing the gap between design and code and shifting the designer’s value toward taste and orchestration. That essay was for the software design industry. Shumer is writing for everyone else.

His core argument: tech workers have already lived through the disruption that’s coming for every other knowledge-work profession. He explains why tech got hit first:

The AI labs made a deliberate choice. They focused on making AI great at writing code first… because building AI requires a lot of code. If AI can write that code, it can help build the next version of itself. A smarter version, which writes better code, which builds an even smarter version. Making AI great at coding was the strategy that unlocks everything else. That’s why they did it first.

Christina Wodtke agrees something big is happening but thinks Shumer’s timeline for everyone else is off. Programming, she argues, is a near-ideal use case for AI—there’s an ocean of public training data, and code has a built-in quality check: it runs or it doesn’t. Hallucinations get caught by the compiler. Other fields aren’t so clean-cut.

Shumer makes the classic tech-insider mistake: assuming his experience generalizes to everyone else’s. It doesn’t. Ethan Mollick’s “jagged frontier” of AI capability is as jagged as ever. AI is spectacular at some tasks and embarrassingly bad at others, and the pattern doesn’t map to human intuitions about difficulty.

She makes another point that matters for anyone in a creative field:

A nuance Shumer completely misses: industries where there isn’t one right answer but there are better and worse answers may actually fare better with AI. When you’re writing strategy, designing an experience, or crafting a narrative, a “hallucination” isn’t necessarily a bug. It might be an interesting idea.

That maps to what I know is true in design. A wrong answer in code crashes the app. A wrong answer in a design brainstorm might be the seed of something good.

This is why I sent Shumer’s piece to my kids but didn’t tell them to panic. Publishing runs on editorial judgment, taste, and relationships with authors. Real estate depends on physical presence, local knowledge, and trust built over handshakes. Neither field has the clean training data and binary pass/fail that made coding so vulnerable so fast. But that doesn’t mean nothing changes. Wodtke again:

Your job probably won’t disappear. But parts of it will shift, and the timeline depends on your field’s specific relationship to data, verification, and ambiguity. Prepare thoughtfully instead of panicking.

Shumer’s practical advice is modest: use AI one hour a day, experiment with it. Not reading about it, but really using it. I’d add Wodtke’s framing to that: spend the hour figuring out which parts of your work sit on the easy side of the jagged frontier, and which parts don’t. That’s more useful than assuming the whole thing collapses overnight.

I said yesterday that the gap between “designer who orchestrates AI” and “designer who pushes pixels” will be enormous within 12 months. Shumer is making that same argument for every knowledge-work profession. The whole piece is worth your time and maybe worth sharing with someone who’s been resistant to AI. Just keep in mind Wodtke’s nuance.

Every article I share on this blog starts the same way: in my RSS reader. I use Inoreader to follow about a hundred feeds—design blogs, tech publications, and independent newsletters. Every morning I scroll through what’s new, mark what’s interesting, and the best stuff eventually becomes a link post here. It’s not a fancy workflow. It’s an RSS reader and a notes app. But it works because the format works.

This is a 2023 article, but I’m fascinated by it because Google Reader was so influential in my life. David Pierce, writing for The Verge, chronicles how Google Reader came to be and why Google killed it.

Chris Wetherell, who built the first prototype, wasn’t thinking about an RSS reader. He was thinking about a universal information layer:

“I drew a big circle on the whiteboard,” he recalls. “And I said, ‘This is information.’ And then I drew spokes off of it, saying, ‘These are videos. This is news. This is this and that.’” He told the iGoogle team that the future of information might be to turn everything into a feed and build a way to aggregate those feeds.

Jason Shellen, the product manager, saw the same thing:

“We were trying to avoid saying ‘feed reader,’” Shellen says, “or reading at all. Because I think we built a social product.”

Google couldn’t see it. Reader had 30 million users, many of them daily, but that was a rounding error by Google standards. Pierce captures the absurdity well:

Almost nothing ever hits Google scale, which is why Google kills almost everything.

So Google poured its resources into Google Plus instead. That product was dead within months of launch. Reader, the thing they killed to make room for it, had been a working social network the whole time. Jenna Bilotta, a designer on the team:

“They could have taken the resources that were allocated for Google Plus, invested them in Reader, and turned Reader into the amazing social network that it was starting to be.”

What gets me is that the vision Wetherell drew on that whiteboard—a single place to follow everything you care about, organized by your taste, shared with people you trust, and non-algorithmic—still doesn’t fully exist. RSS readers are the closest thing we have, and they’re good enough that I’ve built my entire reading and writing practice around one. But the curation layer Wetherell imagined is still unfinished.

Buying something used to be the end of the story. You liked it, you bought it, you used it. Now buying is the beginning. The real work starts when you film the unboxing. At least according to Lucinda Bounsall. Writing for Print Magazine, she argues that platforms have turned everyday life into a continuous production set:

Platforms have normalised a way of living where everyday life is quietly organised around being watchable. Bedrooms become sets, bathrooms become studios, private routines become content addressed to an imagined audience. The effect can feel faintly dystopian; a distributed Truman Show, in which people are advertising products, habits, and lifestyles to unseen cameras, without ever being cast or paid.

Bounsall traces an inversion that anyone who’s worked on a brand should pay attention to. As brands become more abstract and conceptual, the labor of making them mean something falls on the individual:

As brands move up the pyramid, abstracting themselves into values, worlds, and cultural posture, individuals are pushed in the opposite direction, down into labour. The work of meaning-making, distribution, and identity signalling increasingly falls on the person rather than the company. Brands become lighter, more conceptual, more removed; people become the infrastructure through which those brands are activated, circulated, and made legible.

In a way, Bounsall describes what brand has always been at its core—how customers perceive a company or product. It’s always been in the hands of the people.

In her closing, Bounsall sees people starting to pull back into spaces that can’t be monetized:

This doesn’t signal an end to the brandification of the self, but a growing desire to reclaim parts of the self that don’t need to be performed, optimised, or read. Not everything is meant to circulate. And increasingly, that is kind of the point.

That last line pairs with the Dan Abramov piece I linked previously. Abramov argues for an architecture where your data outlives the apps you create it in. Bounsall is making the cultural case for the same impulse: some things should belong to you and not be put into circulation just because a platform makes it easy.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

But Scher’s real critique goes beyond aesthetics.

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

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

Scher puts it plainly:

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

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

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

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

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

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

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

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

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

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