284 posts tagged with “product design”

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.

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.

Every profession, when it feels the ground shifting, reaches for whatever feels most solid. For designers, that’s been “craft” and “taste” (which I’ve used too in my writing). I get the instinct. When the tools you’ve mastered get commoditized, you want to assert that the real value was never in the tools. It was in you always: your eye, your sensibility.

But I’ve watched this play out for over a year now, and I think it’s less strategic positioning than grief response. Nicole Alexandra Michaelis makes the case that designers should be thriving, not panicking, and that much of the panic is self-inflicted. The whiplash:

Seniors are telling juniors to count themselves lucky if they’ll ever find a job. Design leaders are jumping from one AI-tool hypetrain to the next in mere weeks.

Monday, it’s all about prototypes. Thursday, it’s vibe coding. Friday, we’re preaching that output no longer matters (everyone can design now!) and that we should be brilliant strategists instead. By next Monday, we’ll be half-heartedly debating which soft skills are absolutely vital to survive.

Survive. As designers.

A profession trying on new identities in a dressing room. Nothing fits so we keep grabbing the next thing. “Craft” is the one people keep coming back to because it feels the most like home.

Michaelis is blunt about why that doesn’t work:

And listen, I’m not knocking craft. I love writing poetry, painting, throwing pots at the wheel. All that takes craft and skill, just as my designs at work do. But craft should be so obvious to us as designers that we should not make it our main selling point. Obviously, we develop incredible craft as our experience builds. Obviously, individual designers have different styles. Obviously, we put thought and care into what we make.

Craft is the baseline. That’s what we want the executives to know. By debating it and what it even means, we’re again undermining our authority.

She’s right, and I’d push it further. The fixation on craft is a tell. When a profession retreats to arguing about what makes it special instead of demonstrating it, that’s a group reaching for identity because it’s lost agency. The creative class version of quiet quitting.

The junior designer hiring crisis is a subject that’s near and dear to my heart, and Figma’s new hiring study puts hard numbers to it. The headline is encouraging—82% of organizations say their need for designers has increased or stayed steady. But the breakdown by seniority tells a different story.

Andrew Hogan, Head of Insights at Figma:

More than half of hiring managers (56%) say there’s increasing demand for senior design hires, compared to just 25% who are hiring for more junior roles. For many leaders, it’s less of a hiring philosophy and more a matter of bringing on designers who can tackle the problems they’re facing.

56% versus 25%. That gap keeps widening.

Daniel Wert, CEO of executive search firm Wert&Co, calls it out:

It just boggles my mind how few internship programs there are these days. I think it seems shortsighted. The best teams, the best organizations, have a lot of diversity…in terms of years of experience and where people are in their career. You want to have a nice cross-section of junior and mid-senior designers.

Every strong design team I’ve built or been part of had that cross-section. Seniors set the bar. Juniors challenge assumptions and bring energy. Mid-levels hold the whole thing together. Remove any layer and it gets brittle.

Wert again:

Hiring managers are looking for unicorns because they misunderstand how multidisciplinary design is. They want [top-tier] design, but are only willing to hire one person. Great design teams [have] multiple people with complementary strengths—not a single superhero.

This is the real problem. Companies want one person who can do visual design, product strategy, systems thinking, AI integration, and user research. That person doesn’t exist. Great design is a team sport, and the vanishing bottom rung of the career ladder is only making it harder to build those teams.

The fallacy that CEOs and CFOs keep telling themselves is that AI will make this unicorn “product builder” possible. I have my doubts.

Geoffrey Huntley makes a claim that should bother every designer. He’s listing what isn’t a moat in the AI era:

Any product features or platforms that were designed for humans. I know that’s going to sound really wild, but understand these days I go window-shopping on SaaS companies’ websites for product features, rip a screenshot into Claude Code, and it rebuilds that product feature/platform. As we enter the era of hyper-personalised software, I think this will be the case more and more. In my latest creation, I have cloned Posthog, Jira, Pipedrive, and Calendly, and the list just keeps on growing because I want to build a hyper-personalised business that meets all my needs, with full control and everything first-party.

“Features designed for humans” aren’t a moat. Not because design doesn’t matter—because the implementation can be cloned from a screenshot. Huntley himself rebuilt versions of Posthog, Jira, Pipedrive, and Calendly.

Huntley invented the Ralph loop—a technique for running AI coding agents in continuous loops that ship production software at a fraction of the old cost. He’s been tracking the economic fallout for a year:

The cost of software development is $10.42 an hour, which is less than minimum wage and a burger flipper at macca’s gets paid more than that. What does it mean to be a software developer when everyone in the world can develop software? Just two nights ago, I was at a Cursor meetup, and nearly everyone in the room was not a software developer, showing off their latest and greatest creations.

Well, they just became software developers because Cursor enabled them to become one. You see, the knowledge and skill of being a software developer has been commoditised.

Swap “software developer” for “designer.” Anton Sten rebuilt his website and invoicing system without writing code. Édouard Wautier’s team skips Figma after the initial sketch and prototypes directly in code. The commoditization Huntley describes is already arriving for design:

AI erases traditional developer identities—backend, frontend, Ruby, or Node.js. Anyone can now perform these roles, creating emotional challenges for specialists with decades of experience.

“UI designer,” “UX designer,” “interaction designer”—these specializations made sense when each required distinct tools and workflows. When an AI agent can handle the execution across all three, the labels stop carrying weight.

So if the implementation layer isn’t the moat, what is? Huntley’s answer for business is distribution, utility pricing, and operating model-first. The design answer is adjacent: knowing what to build and what to leave out. Taste. Judgment. The ability to look at what Claude generated from a screenshot and know it’s solving the wrong problem.

“People are change averse,” Duolingo’s CEO Luis von Ahn said when users revolted against the app’s 2022 redesign. He refused to offer a revert option. The backlash was just resistance to change, and users would get over it, he argued.

Dora Czerna, writing for UX Collective, makes the case that von Ahn got it wrong. Users weren’t afraid of change. They’d lost something:

That old interface isn’t just a collection of buttons and menus–it’s ours. We’ve invested time learning it, built workflows around it, developed preferences and shortcuts. The new design might be objectively superior in controlled testing, but it requires us to surrender something we’ve claimed as our own.

That’s the endowment effect applied to software. The hours you spent learning an interface have real value, and a redesign zeroes them out. Calling that “change aversion” dismisses the investment.

Czerna points to Sonos as the worst-case scenario—users who’d spent thousands on home audio systems suddenly couldn’t adjust the volume after an app update. But even smaller changes trigger the same psychology. Google changed its crop tool from square corners to rounded ones and got enough backlash to reverse it.

Czerna on what happens when you tell users the new version tested better:

Telling users “we tested this, and it’s better” when they’re actively experiencing it as worse creates a disconnect. Acknowledging that change is difficult, explaining what you’re trying to achieve, and being responsive to legitimate concerns about lost functionality builds more goodwill than insisting everything is fine when it clearly isn’t.

What’s less common is teams treating the transition itself as a design problem worth solving. And of course it is.

Claude skills are structured markdown files that tell Claude how to handle a specific type of task. It is—as the name suggests—a new skill Claude or any AI agent can “learn.” Each one defines a role for Claude to adopt, the inputs it needs, a step-by-step workflow, and a quality bar for the output. You can build them for anything—research synthesis, writing, code review, design critique. Once loaded, Claude follows the workflow instead of improvising.

Nick Babich, writing for UX Planet, put together 10 skills aimed at product designers. The three I’d reach for first are the UX Heuristic Review, the Design Critique Partner, and the Competitor Analysis Generator. All three give a solo designer a structured second opinion on demand: a heuristic eval against Nielsen’s 10, a senior-level design critique, or a competitive feature matrix.

Babich’s skill format is clean and worth studying even if you end up building your own from scratch. (Hint: or use Claude Code to write its own skills.)

Boris Cherny, head of Claude Code at Anthropic, on Lenny’s Podcast:

I think at this point it’s safe to say that coding is largely solved. At least for the kind of programming that I do, it’s just a solved problem because Claude can do it. And so now we’re starting to think about what’s next, what’s beyond this. Claude is starting to come up with ideas. It’s looking through feedback. It’s looking at bug reports. It’s looking at telemetry for bug fixes and things to ship—a little more like a co-worker or something like that.

“Largely solved” is a big claim from the person running the tool that’s solving it. And then he goes further—Claude is starting to decide what to build. That’s product management work.

Cherny on what his team at Anthropic already looks like:

On the Claude Code team, everyone codes. Our product manager codes, our engineering manager codes, our designer codes, our finance guy codes, our data scientist codes.

And on where the role boundaries are heading:

There’s maybe a 50% overlap in these roles where a lot of people are actually just doing the same thing and some people have specialties. I think by the end of the year the title software engineer is going to start to go away and it’s just going to be replaced by builder. Or maybe everyone’s going to be a product manager and everyone codes.

But where does design fit in all this? A PM can define the problem, maybe even come up with a good solution. But does Cherny think that AI will be the designer?

Lenny ran polls asking engineers, PMs, and designers whether they enjoy their jobs more or less since adopting AI. Engineers and PMs: 70% said more. Designers went the other direction with only 55% who said they were enjoying their job more, and 18%—nearly twice as many as engineers—said they were enjoying their job less.

Cherny’s reaction:

Our designers largely code. So I think for them this is something that they have enjoyed because they can unblock themselves.

That’s an engineer’s answer to a design question. Designers at Anthropic are happy because they can ship without waiting on a developer. But “unblocking yourself” isn’t the same as “AI can do the design.” Cherny doesn’t touch the user experience, visual thinking, the spatial reasoning.

My theory: Designers are visual people. Typing to design doesn’t really compute. And who can blame us?

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?”

Victor Yocco lays out a UX research playbook for agentic AI in Smashing Magazine—autonomy taxonomy, research methods, metrics, the works. It’s one of the more practical pieces I’ve seen on designing AI that acts on behalf of users.

The autonomy framework is useful. Yocco maps four modes from passive monitoring to full autonomy, and the key insight is that trust isn’t binary:

A user might trust an agent to act autonomously for scheduling, but keep it in “suggestion mode” for financial transactions.

That tracks with how I think about designing AI features. The same user will want different levels of control depending on what’s at stake. Autonomy settings should be per-domain, not global.

On measuring whether it’s working:

For autonomous agents, we measure success by silence. If an agent executes a task and the user does not intervene or reverse the action within a set window, we count that as acceptance.

That’s a different and interesting way to think about design metrics—success as the absence of correction. Yocco pairs this with microsurveys on the undo action so you’re not just counting rollbacks but understanding why they happen.

The cautionary section is worth flagging. Yocco introduces “agentic sludge”—where traditional dark patterns add friction to trap users, agentic sludge removes friction so users agree to things that benefit the business without thinking. Pair that with LLMs that sound authoritative even when wrong, and you have a system that can quietly optimize against the user’s interests. We’ve watched this happen before with social media. The teams that skip the research Yocco describes are the ones most likely to build it again.

Jonny Burch argued that design’s source of truth is moving from Figma to code. Édouard Wautier is already there. He wrote up a field report on how Dust’s design team prototypes directly in code.

After the initial analysis and quick sketchbook phase, when I need to give the idea shape and pressure-test it, I don’t open Figma. I open my development environment, pull the latest version of our repo, and create a branch. Then I ask an agent to scaffold a new prototype, and I describe what I’m trying to make.

The prototype isn’t a picture of the product—it’s built from the same design system components and tokens. So what is Wautier optimizing for at this stage?

At this point I mostly care about trying the idea and seeing whether the interaction holds. I’ll build small flows, prototype the transitions, and sanity-check the parts that static screens often hide (state changes, error cases, motion, empty states, keyboard/navigation/accessibility basics).

He’s honest about the trade-offs. You occasionally lose 30 minutes to a tooling issue. Prototypes can invite premature polish because they look real too early. And handoff clarity gets muddy—engineers aren’t always sure what’s prototype-only versus reusable.

Wautier’s closing:

More like clay than drafting: you shape, you test, you feel, you adjust — with an instantaneous feedback loop. The artifact is no longer a description of the thing. It starts to become the thing, or at least a runnable slice of it.

I believe this is the future.

The source of truth for product design is shifting from Figma to code. I’ve been making that argument from the design side. Jonny Burch is making it from the tooling side, with a sharper prediction about what replaces Figma: nothing owned by one company.

Burch on where design interfaces are headed:

As product, design and engineering collapse together, design interfaces will start to look more like dependencies in the code itself.

A mature design system already lives in code—the Figma components are a mirror, not the original. Once AI agents can read and build against that code directly, the mirror becomes optional. Burch sees this leading to a fragmented ecosystem of code-first plugins and open tools rather than a single Figma replacement. I think he’s right about the direction, if aggressive on the timeline.

On why the pressure is building:

In modern teams it’s no longer acceptable for a designer to spend 2 weeks in their mind palace creating the perfect UI.

It’s starting to happen on my own team. Engineers with AI agents are producing working features in hours. The design phase—the Figma phase—is now the slowest part of the cycle. That’s a new and uncomfortable feeling for designers who grew up in a world where engineering was always the bottleneck.

Burch on Figma’s position in all of this:

They’re suddenly the slow incumbent with the wrong tech stack and a large enterprise customer-base adding drag.

I watched the same dynamic play out when Figma displaced Sketch. The dominant tool doesn’t always adapt fast enough. Sometimes the market just routes around it.

To be sure, I don’t wish for the death of Figma. Designers are visual thinkers and that’s what makes us different than PMs and engineers. I’m sure we’ll continue to use Figma for initial UI explorations. But instead of building out 40-screen flows, we’ll quickly move into code and generate a prototype that’ll look and feel like what we’re going to ship.

The software development process has accumulated decades of ceremony. Boris Tane argues AI agents are collapsing the whole thing.

On engineers who started their careers after Cursor:

They don’t know what the software development lifecycle is. They don’t know what’s DevOps or what’s an SRE. Not because they’re bad engineers. Because they never needed it. They’ve never sat through sprint planning. They’ve never estimated story points. They’ve never waited three days for a PR review.

I read that and thought about design. How much of our process is ceremony too? The Figma-to-developer handoff. The pixel-perfect QA pass. The design review where six people debate border radius. If an AI agent can generate working UI from a design system in three prompts—which I’ve done—a lot of what we treat as process is friction we’ve institutionalized.

Tane’s conclusion:

The quality of what you build with agents is directly proportional to the quality of context you give them. Not the process. Not the ceremony. The context.

For engineering, context means specs, tests, architectural constraints. For design, it means your design system—the component docs and the rules for how things fit together. If that context is thin, the agent produces garbage. If it’s thorough and machine-readable, the output lands close to production-ready.

Tane again:

Requirements aren’t a phase anymore. They’re a byproduct of iteration.

Same for mockups. When you can generate and evaluate working UI faster than you can annotate a Figma frame, the mockup stops being a deliverable and becomes a sketch you might skip entirely. The design system becomes the spec. Context engineering becomes the job.

I’ve been arguing that the designer’s job is shifting from execution to orchestration—directing AI agents rather than pushing pixels. I made that case from the design side. Addy Osmani just made it from engineering based on what he’s seeing.

Osmani draws a hard line between vibe coding and what he calls “agentic engineering.” On vibe coding:

Vibe coding means going with the vibes and not reviewing the code. That’s the defining characteristic. You prompt, you accept, you run it, you see if it works. If it doesn’t, you paste the error back and try again. You keep prompting. The human is a prompt DJ, not an engineer.

“Prompt DJ” is good. But Osmani’s description of the disciplined version is what caught my attention—it’s the same role I’ve been arguing designers need to grow into:

You’re orchestrating AI agents - coding assistants that can execute, test, and refine code - while you act as architect, reviewer, and decision-maker.

Osmani again:

AI didn’t cause the problem; skipping the design thinking did.

An engineer wrote that. The spec-first workflow Osmani describes is design process applied to code. Designers have been saying “define the problem before you jump to solutions” for decades. AI just made that advice load-bearing for engineers too.

The full piece goes deep on skill gaps, testing discipline, and evaluation frameworks—worth a complete read.

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.

Tommaso Nervegna, a Design Director at Accenture Song, gives one of the clearest practitioner accounts I’ve seen of what using Claude Code as a designer looks like day to day.

The guide is detailed—installation steps, terminal commands, deployment. This is essential reading for any designer interested in Claude Code. But for me, the interesting part isn’t the how-to. It’s his argument that raw AI coding tools aren’t enough without structure on top:

Claude Code is powerful, but without proper context engineering, it degrades as the conversation gets longer.

Anyone who’s used these tools seriously has experienced this. You start a session and the output is sharp. Forty minutes in, it’s forgotten your constraints and is hallucinating component names. Nervegna uses a meta-prompting framework called Get Shit Done that breaks work into phases with fresh contexts—research, planning, execution, verification—each getting its own 200K token window. No accumulated garbage.

The framework ends up looking a lot like good design process applied to AI:

Instead of immediately generating code, it asks:

“What happens when there’s no data to display?” “Should this work on mobile?” “What’s the error state look like?” “How do users undo this action?”

Those are the questions a senior designer asks in a review. Nervegna calls it “spec-driven development,” but it’s really the discipline of defining the problem before jumping to solutions—something our profession has always preached and often ignored when deadlines hit.

Nervegna again:

This is spec-driven development, but the spec is generated through conversation, not written in Jira by a project manager.

The specification work that used to live in PRDs and handoff docs is happening conversationally now, between a designer and an AI agent. The designer’s value is in the questions asked before any code gets written.

Earlier this week I published an essay on how product design is changing, and one of the sources I referenced was Jan Tegze’s piece on job shrinkage. I quoted him on the orchestrator model—using agents to create new capabilities rather than speeding up old tasks. But there’s another section of his article that deserves its own post. It’s the part nobody wants to talk about.

Jan Tegze, writing for his Thinking Out Loud newsletter:

Many people currently doing “strategic” knowledge work aren’t actually that strategic.

When agents started handling the execution layer, everyone assumed humans would naturally move up to higher-order thinking. Strategy, judgment, and vision.

But a different reality is emerging—many senior people with years of experience can’t actually operate at that level. Their expertise was mostly pattern matching and process execution dressed up in strategic language.

That’s a hard paragraph to read if you’re a senior IC or a manager who’s built a career on being thorough and diligent. Tegze isn’t being cruel—he’s describing a structural problem. We built evaluation systems that rewarded execution and called it strategy.

He shares a quote from a CEO of a mid-sized Canadian company:

“We’re discovering that our senior people and our junior people are equally lost when we ask them what we should do, not just how to do it. The seniors are just more articulate about their uncertainty.”

Tegze illustrates the pattern with a story about a friend he calls Jane—a senior research analyst billing at $250/hour at a consulting firm where they deployed an AI research agent:

The agent could do Jane’s initial research in 90 minutes—it would scan thousands of sources, identify patterns, generate a first-draft report.

Month one: Jane was relieved and thought she could focus on high-value synthesis work. She’d take the agent’s output and refine it, add strategic insights, make it client-ready.

Month three: A partner asked her, “Why does this take you a week now? The AI gives us 80% of what we need in an hour. What’s the other 20% worth?”

Jane couldn’t answer clearly. Because sometimes the agent’s output only needed light editing. Sometimes her “strategic insights” were things the agent had already identified, just worded differently.

The firm restructured Jane into a “Quality Reviewer” role at $150/hour. Six months later she left. They replaced her with two junior analysts at $65K each who, with the AI, were 85% as effective.

And then the kicker:

You often hear from AI vendors that, thanks to their AI tools, people can focus on higher-value work. But when pressed on what that meant specifically, they’d go vague. Strategic thinking, client relationships, creative problem solving.

Nobody could define what higher-value work actually looked like in practice. Nobody could describe the new role. So they defaulted to the only thing they could measure: cost reduction.

Tegze again:

We promoted people for the wrong reasons. We confused “does the work well” with “thinks strategically about the work.”

Tegze’s framing of the orchestrator model is the most useful I’ve seen—stop defending your current role and start building one that didn’t exist six months ago. But this section on the strategy gap is worth sitting with on its own. The automation isn’t just changing what we do. It’s revealing what we were actually good at all along.

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.

Steve Yegge has been talking to nearly 40 people at Anthropic over the past four months. What he describes looks nothing like the feature factory world that NN/g catalogs. No 47-page alignment documents. No 14-meeting coordination cycles. Instead, campfires:

Everyone sits around a campfire together, and builds. The center of the campfire is a living prototype. There is no waterfall. There is no spec. There is a prototype that simply evolves, via group sculpting, into the final product: something that finally feels right. You know it when you finally find it.

As evidence of this, Anthropic, from what I’m told, does not produce an operating plan ahead more than 90 days, and that is their outermost planning cycle. They are vibing, on the shortest cycles and fastest feedback loops imaginable for their size.

No roadmap beyond 90 days. They group-sculpt a living prototype. Someone told Yegge that Claude Cowork shipped 10 days after the idea first came up. Ten days. A small team with real ownership, shipping at the speed the tools now allow.

Yegge argues this works partly because of a cultural requirement most companies would struggle with. He describes a three-person startup called SageOx that operates the same way:

A lot of engineers like to work in relative privacy, or even secrecy. They don’t want people to see all the false starts, struggles, etc. They just want people to see the finished product. It’s why we have git squash and send dignified PRs instead of streaming every compile error to our entire team.

But my SageOx friends Ajit and Ryan actually want the entire work stream to be public, because it’s incredibly valuable for forensics: figuring out exactly how and why a teammate, human or agent, got to a particular spot. It’s valuable because merging is a continuous activity and the forensics give the models the tools and context they need to merge intelligently.

So at SageOx they all see each other’s work all the time, and act on that info. It’s like the whole team is pair programming at once. They course-correct each other in real time.

Yegge calls this “the death of the ego.” Everyone sees your mistakes, your wrong turns, how fast you work. Nothing to hide. Most designers and engineers I know would be deeply uncomfortable with that. We like to polish before we share. We present finished comps, not the 13 variations we tried and abandoned.

But if the campfire model is where things are heading—and the speed advantage over the feature factory is hard to argue with—then the culture has to change before the process can. That’s the part nobody wants to talk about.

I’ve seen this at every company past a certain size: you spot a disjointed UX problem across the product, you know what needs to happen, and then you spend three months in alignment meetings trying to get six teams to agree on a button style.

A recent piece from Laura Klein at Nielsen Norman Group examines why most product teams aren’t actually empowered, despite what the org chart claims. Klein on fragmentation:

When you have dozens of empowered teams, each optimizing its own metrics and building its own features, you get a product that feels like it was designed by dozens of different companies. One team’s area uses a modal dialog for confirmations. Another team uses an inline message. A third team navigates to a new page. The buttons say Submit in one place, Save in another, and Continue in a third. The tone of the microcopy varies wildly from formal to casual.

Users don’t see teams. They don’t see component boundaries. They just see a confusing, inconsistent product that seems to have been designed by people who never talked to each other, because, in a sense, it was.

Each team was empowered to make the best decisions for their area, and it did! But nobody was empowered to maintain coherence across the whole experience.

That last line is the whole problem. “Coherence,” as Klein calls it, is a design leadership responsibility, and it gets harder as AI lets individual teams ship faster without coordinating with each other. If every squad can generate production UI in hours instead of weeks, the fragmentation described here accelerates. Design systems become the only thing standing between your product and a Frankenstein experience.

The article is also sharp on what happens to PMs inside this dysfunction:

Picture a PM who spends 70% of her time in meetings coordinating with other teams, getting buy-in for a small change, negotiating priorities, trying to align roadmaps, escalating conflicts, chasing down dependencies, and attending working groups created to solve coordination problems. She spends a tiny fraction of her time with users. The rest is spent writing documents that explain her team’s work to other teams, updating roadmaps, reporting status, and attending planning meetings. She was hired to be a strategic product thinker, but she’s become a project manager, focused entirely on logistics and coordination.

I’ve watched this happen to PMs I’ve worked with. The coordination tax eats the strategic work. Marty Cagan calls this “product management theater”—a surplus of PMs who function as overpaid project managers. If AI compresses the engineering work but the coordination overhead stays the same, that ratio gets even more lopsided.

The fix is smaller teams with real ownership and strong design systems that enforce coherence without requiring 14 alignment meetings. But that requires organizational courage most companies don’t have.

In my previous post about Google Reader, I wrote about Chris Wetherell’s original vision—a polymorphic information tool, not a feed reader. But even Google Reader ended up as a three-pane inbox. That layout didn’t originate with Reader, though. It’s older than that.

Terry Godier traces that layout to a single decision. In 2002, Brent Simmons released NetNewsWire, the first RSS reader that looked like an email client. Godier asked him why, and Simmons’ answer was pragmatic:

“I was actually thinking about Usenet, not email, but whatever. The question I asked myself then was how would I design a Usenet app for (then-new) Mac OS X in the year 2002?”

“The answer was pretty clear to me: instead of multiple windows, a single window with a sidebar, list of posts, and detail view.”

A reasonable choice in 2002. But then Godier shares Simmons reflecting on why everyone kept copying him twenty-two years later:

“But every new RSS reader ought to consider not being yet another three-paned-aggregator. There are surely millions of users who might prefer a river of news or other paradigms.”

“Why not have some fun and do something new, or at least different?”

The person who designed the original paradigm was asking, twenty-two years later, why everyone was still copying him.

Godier’s argument is that when Simmons borrowed the inbox layout, he inadvertently imported the inbox’s psychology. Unread counts. Bold text for new items. A backlog that accumulates. The visual language of social debt, applied to content nobody sent you:

When you dress a new thing in old clothes, people don’t just learn the shape. They inherit the feelings, the assumptions, the emotional weight. You can’t borrow the layout of an inbox without also borrowing some of its psychology.

He calls this “phantom obligation”—the guilt you feel for something no one asked you to do. And I’ll admit, I feel it. I open Inoreader every morning and when that number isn’t zero, some part of my brain registers it as a task. It shouldn’t. Nobody is waiting. But the interface says otherwise.

Godier’s best line is the one that frames the whole piece:

We’ve been laundering obligation. Each interface inherits legitimacy from the last, but the social contract underneath gets hollowed out.

The red dot on a game has the same visual weight as a text from your kid. We kept the weight and dropped the reason.

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.

Anthropic published a study that puts numbers to something I’ve been writing about in the design context for a while now. They ran a randomized controlled trial with 52 junior software engineers learning a new Python library. Half used AI assistance. Half coded by hand.

Judy Hanwen Shen and Alex Tamkin, writing for Anthropic Research:

Participants in the AI group scored 17% lower than those who coded by hand, or the equivalent of nearly two letter grades. Using AI sped up the task slightly, but this didn’t reach the threshold of statistical significance.

So the AI group didn’t finish meaningfully faster, but they understood meaningfully less. And the biggest gap was in debugging—the ability to recognize when code is wrong and figure out why. That’s the exact skill you need most when your job is to oversee AI-generated output.

The largest gap in scores between the two groups was on debugging questions, suggesting that the ability to understand when code is incorrect and why it fails may be a particular area of concern if AI impedes coding development.

This is the same dynamic I fear in design. When I wrote about the design talent crisis, educators like Eric Heiman told me “we internalize so much by doing things slower… learning through tinkering with our process, and making mistakes.” Bradford Prairie put it more bluntly: “If there’s one thing that AI can’t replace, it’s your sense of discernment for what is good and what is not good.” But discernment comes from reps, and AI is eating the reps.

The honest framing from Anthropic’s own researchers:

It is possible that AI both accelerates productivity on well-developed skills and hinders the acquisition of new ones.

Credit to Anthropic for publishing research that complicates the case for their own product. And the study’s footnote is worth noting: they used a chat-based AI assistant, not an agentic tool like Claude Code. Their expectation is that “the impacts of such programs on skill development are likely to be more pronounced.”

I can certainly attest that when I use Claude Code, I have no idea what’s going on!

The one bright spot: not all AI use was equal. Participants who asked conceptual questions and used AI to check their understanding scored well. The ones who delegated code generation wholesale scored worst. The difference was whether you were thinking alongside the tool or letting it think for you.

Cognitive effort—and even getting painfully stuck—is likely important for fostering mastery.

Getting painfully stuck. That’s the apprenticeship. That’s the grunt work. And it’s exactly what we’re optimizing away.