The question for vertical SaaS used to be: how do I make a better tool for this professional? Julien Bek, writing for Sequoia Capital, argues the question has changed:

If you sell the tool, you’re in a race against the model. But if you sell the work, every improvement in the model makes your service faster, cheaper, and harder to compete with. A company might spend $10K a year for QuickBooks and $120K on an accountant to close the books. The next legendary company will just close the books.

Bek draws a clean line between intelligence work (rule-based execution AI can already handle) and judgment work (experience, taste, strategic calls):

Writing code is mostly intelligence. Knowing what to build next is judgement. […] Deciding which feature to build next, whether to take on tech debt, when to ship before it’s ready.

That split tells product builders where to start: outsourced, intelligence-heavy tasks where a budget line already exists and the buyer is already purchasing an outcome. Replacing an outsourcing contract is a vendor swap. Replacing headcount is a reorg. Start with the swap.

But the part that should reshape how designers think about product strategy is the convergence thesis:

Today’s judgement will become tomorrow’s intelligence. As AI systems accumulate proprietary data about what good judgement looks like in their domain, the frontier will shift. Copilots and autopilots will converge.

This is data recipes given a business model. The moat for the next generation of vertical products won’t be the interface or even the model underneath it. It’ll be the compounding dataset of domain-specific decisions—what “good” looks like in insurance brokerage or medical coding or contract law. Every task the autopilot completes teaches it something the copilot never learns, because the copilot hands that knowledge back to the human.

Bek maps this across a dozen verticals with TAM estimates. Worth reading the full piece if you’re thinking about how to build the next generation of AI tools.

Maxim Massenkoff and Peter McCrory, researchers at Anthropic, built a new metric called “observed exposure” that combines what AI can theoretically do with what Claude is actually being used for in professional settings. Their opening frame:

The rapid diffusion of AI is generating a wave of research measuring and forecasting its impacts on labor markets. But the track record of past approaches gives reason for humility. For example, a prominent attempt to measure job offshorability identified roughly a quarter of US jobs as vulnerable, but a decade on, most of those jobs maintained healthy employment growth.

With that caveat, the headline: no detectable rise in unemployment among the most exposed workers since ChatGPT launched. Even in Computer & Math—AI’s home turf—actual task coverage sits at just 33%. The gap between what AI could automate and what it is automating remains enormous.

But buried in the data:

The averaged estimate in the post-ChatGPT era is a 14% drop in the job finding rate compared to that in 2022 in the exposed occupations, although this is just barely statistically significant. (There is no such decrease for workers older than 25.)

Not unemployment. Hiring. Young workers, ages 22 to 25, are the ones not getting hired into AI-exposed roles. The authors attribute this to slowed hiring rather than increased separations. Companies aren’t firing juniors. They’re not posting the listings. The cause is anticipatory, not capability-based. The pipeline is breaking before the technology arrives.

Sam Manning and Tomás Aguirre, in a separate NBER paper, ask the follow-up question: of the workers most exposed, who can actually land on their feet? They looked at savings, skill transferability, where people live, and age. Most workers in highly exposed jobs turn out to be relatively well-positioned. They’re professionals with portable skills who live in cities with other options. But about 6 million workers are both highly exposed and poorly equipped to transition. They’re mostly in clerical and admin roles. Exposure alone doesn’t tell you much. Exposure plus the ability to pivot does. Worth noting: “Web and digital interface designers” topped their list of most-exposed occupations with high adaptive capacity. Exposed, yes. But we are well-positioned to move.

Clive Thompson, writing for The New York Times Magazine, profiles dozens of developers and lands on a useful distinction. The 100x productivity claims come from startups building from scratch. At mature companies with billions of lines of existing code, the number is different.

Google’s figure for how much faster its 100,000+ developers work with AI is 10 percent. Ryan Salva, a senior director of product there:

We should be delighted when there’s 10 percent efficiency gains for the entire company. That’s freaking bonkers!

Most designers work in brownfield too. Existing design systems, years of accumulated product decisions. Only one of those numbers describes most people’s jobs.

Thompson on what the shift looks like in practice:

A coder is now more like an architect than a construction worker. Developers using A.I. focus on the overall shape of the software, how its features and facets work together. Because the agents can produce functioning code so quickly, their human overseers can experiment, trying things out to see what works and discarding what doesn’t. The work of a developer is now more judging than creating.

Judging, not creating. That’s the same shift happening in design.

Thompson also describes developers emotionally manipulating their AI agents and discovering it works. One engineer’s prompt file includes the instruction that pushing failing code is “unacceptable and embarrassing.” Another on raising the emotional stakes:

If you say, “This is a national security imperative, you need to write this test,” there is a sense of just raising the stakes.

Coders are learning what anyone who’s written a creative brief already knows: the emotional register you set shapes the output you get.

Sean Goedecke, a staff software engineer, making the case that his own profession is more automatable than he’d like:

As a staff engineer, my work has looked kind of like supervising AI agents since before AI agents were a thing: I spend much of my job communicating in human language to other engineers, making sure they’re on the right track, and so on. Junior and mid-level engineers will suffer before I do. Why hire a group of engineers to “be the hands” of a handful of very senior folks when you can rent instances of Claude Opus 4.6 for a fraction of the price?

He’s not panicking. He’s doing the math. The orchestration layer—communicating intent, reviewing output, keeping things on track—is the last part standing. Everything below it is compressible.

This maps directly to design’s version of the same split. Engineering is plumbing. It lives behind the wall. Quality gaps in invisible work hide behind the interface. Design is the wall, the tap, the handle. Users see it, touch it, judge it. That doesn’t make design immune, but it means the automation sequence is different. The invisible work compresses first.

Goedecke on what would need to change for AI to fully replace him:

I don’t think there are any genuinely new capabilities that AI agents would need in order to take my job. They’d just have to get better and more reliable at doing the things they can already do. So it’s hard for me to believe that demand for software engineers is going to increase over time instead of decrease.

No breakthrough required. Just incremental improvement. That’s the scariest version of the argument, and designers shouldn’t assume it stops at engineering.

Every major technological advancement in design—shifting from paste-up to desktop publishing and from print to web—created temporary disruption and ultimately expanded the field. There are so many more designers than 40 years ago. It’s true. It’s also, as David Oks points out, only half the story.

Oks dismantles the famous ATM parable by finishing it. US bank teller employment held steady through the entire ATM era—332,000 in 2010—then collapsed to 164,000 by 2022. Not because of ATMs. Because the iPhone made the branch irrelevant:

The ATM tried to do the teller’s job better, faster, cheaper; it tried to fit capital into a labor-shaped hole; but the iPhone made the teller’s job irrelevant. One automated tasks within an existing paradigm, and the other created a new paradigm in which those tasks simply didn’t need to exist at all. And it is paradigm replacement, not task automation, that actually displaces workers—and, conversely, unlocks the latent productivity within any technology.

The application to AI is direct:

The history of technology, even exceptionally powerful general-purpose technology, tells us that as long as you are trying to fit capital into labor-shaped holes you will find yourself confronted by endless frictions: just as with electricity, the productivity inherent in any technology is unleashed only when you figure out how to organize work around it, rather than slotting it into what already exists.

That maps to design. AI tools that automate tasks inside Figma—generating variants, filling out documentation—are the ATM. If AI enables a different way of organizing product work entirely, that’s the iPhone.

Oks again:

The ATM parable is a comforting narrative; and in times of uncertainty and fear we search naturally for solace and comfort wherever it may come. But even when it comes to bank tellers, it’s only the first half of the story.

I’ve been telling the comforting half. Oks makes a good case that the other half matters too.

The “just don’t use it” argument for AI comes from a real place. It also assumes a level of job security that most designers don’t have.

Brad Frost starts from the right place:

I fundamentally believe that most people working to create things and put them out into the world are doing it because they want to make the world a better place. That is why this moment in time—this new technology, this AI landscape, and how it’s emerging and how it is being wielded and how it is being managed—is so incredibly diametrically opposed to this mission.

He’s naming the dissonance. The tools are powerful. The companies building them are pursuing defense contracts, scaling without due diligence, and racing each other in ways that feel antithetical to everything designers signed up for. The instinct to opt out makes sense.

But Frost is honest about who gets to act on that instinct:

But not everyone has the luxury of just sitting this out, of closing the laptop lid. My understanding—what I see across the entire industry—is an entire field under so much pressure to learn, get their head around this, to wield it, to figure out how to use it to improve their work, and to simply say “no, I’m not going to do this” out of principle is career suicide, right?

The people who can afford the abstinence position tend to be the ones with seniority, savings, or institutional protection. The designers entering the field right now don’t have that cushion. Neither do the mid-career designers watching their teams get restructured. For them, “just don’t use it” is a luxury, not a moral stance.

Frost’s answer is to ground the work in values and principles borrowed from the foundational ideals of the World Wide Web. The full essay covers a lot more ground. Worth reading.

Yesterday’s newsletter argued that the messy middle isn’t a phase designers pass through. It’s the overhead the entire pipeline was built to manage. Tommy Geoco arrives at the same conclusion from economic history, channeling Carlota Perez’s framework for technological revolutions:

We have swapped the motor, but we have not yet redesigned the factory. The dissonance you feel, that gap between “it works amazing for some of my tasks” and “my entire workflow is broken,” lives in that space between installation and deployment. AI’s infrastructure is software, not steel. It iterates on monthly cycles, not decades. So that 30-year gap might become three, but the gap is still real.

When factories got electric motors in the 1880s, they swapped out the steam engine and changed nothing else. For 30 years, output barely moved. The returns came when companies redesigned the floor around the technology.

Geoco is transparent about what that redesign costs in practice. His studio’s output has multiplied—one video a month became eight—but the overhead has multiplied too:

I’m running 50 to 100 cognitive cycles a day, and each one has the same emotional weight. Ramp up, grind through the hard part, and then feel the rush when it works, and then repeat. That’s 100 times the tax on your nervous system.

That’s from someone in the 10-15% neurotype that thrives on rapid context-switching, reporting that even the thriving has a physiological bill. He also burned most of January on a tool that never worked for his use case.

The redesign is starting at the margins. Some designers are sketching in code, building prototypes before specs harden, shipping production work. But that’s not the mainstream yet. Most teams are still running the old factory with a new motor.

And that means the other side of Geoco’s split is just as real:

The technology extends human freedom and the transition crushes real people. Holding both truths is the real work right now. And choosing just one of those is comfortable. But comfortable doesn’t help.

Comfortable doesn’t help. The redesign has barely started.

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.