151 posts tagged with “tech industry”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Foresight alone cannot prevent the race toward the cliff.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Here’s where the field is right now:

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

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

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

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

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

Maguire on disenfranchised grief and AI layoffs:

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

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

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

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

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

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

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

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

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

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

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

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

The headline says it all: “Uber president says AI spending is getting ‘harder to justify.’”

Jess Weatherbed, writing in The Verge:

After reportedly exhausting its annual AI budget just four months into 2026, Uber is now questioning whether it’s actually seeing meaningful returns on its investments. In an interview with Rapid Response, Uber president and chief operating officer Andrew Macdonald said the company isn’t seeing a connection between rising token consumption for Claude Code and more useful features being delivered to consumers.

“That link is not there yet, right? I think maybe implicitly there is more that is getting shipped, but it’s very hard to draw a line between one of those stats and, ‘Okay, now we’re actually producing 25 percent more useful consumer features,’” said Macdonald. “I think over the coming quarters and years, maybe that will become clearer, but I think today it’s hard, even if some of the underlying metrics are trending in a really astronomical direction.”

Two quick thoughts. First, engineering—and by extension, product and design—velocity gains like 2x, 3x, or 10x show up in the output. They aren’t showing up directly in the outcomes. Getting to a design faster doesn’t mean you designed the right thing.

Second, we haven’t redesigned the factory floor yet. It’s a metaphor I’m borrowing from Tommy Geoco. When factories converted from steam power to electricity in the 1880s, they swapped out the engines and did nothing else. The floor plan and workflow didn’t change. For three decades, output barely moved. Only when companies redesigned their factories and process around the new technology did they see an increase in output.

We haven’t quite figured this out as an industry or discipline yet. As I’ve written previously, it’s foggy but the shape is unmistakable. The answer is out there.

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

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

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

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

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

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

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

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

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

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

Ries on a related diagnosis:

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

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

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

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

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

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

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

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

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

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

His promise to anyone who picks one and stays:

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

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

Fonseca on macOS:

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

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

Fonseca on Electron:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cat Wu, Anthropic’s Head of Product for Claude Code, describes the hiring filter on her team in her interview with Lenny Rachitsky:

I think all of the roles are merging. PMs are doing some engineering work. Engineers are doing PM work. Designers are PMing and also landing code. You can either hire a lot more engineers who have great product taste, or you can keep your engineering hiring the same and hire a lot more PMs to help guide some of their work. On our team, we’re pretty focused on hiring engineers with great product taste. This way we can reduce the amount of overhead for shipping any product. Like there are many engineers on our team who are fully able to end to end go from see user feedback on Twitter through to like ship a product at the end of the week with almost no product involvement. And this, I think, is actually like the most efficient way to ship something. So I think like engineer and PM are kind of overlapping and you will get a lot of benefit from having more of either. I think product taste is still a very rare skill to have and we’ll pretty much hire anyone who we feel has demonstrated this strongly.

This is what the Full Stack Builder pattern looks like as a hiring filter. The headline is the merging of roles. Wu’s own background says where the bench comes from:

Yeah, I was an engineer for many years. I was then a VC very briefly before joining Anthropic. And actually almost all the PMs on our team have either been engineers or ship code here on Claude Code. And so that’s one of the things that I think helps build trust with the team and also just enables us to move a lot faster. And then actually our designers also have been front-end engineers before.

So to be clear, Wu doesn’t say that the roles have merged, but what she’s describing is the continued blurring of lines.

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

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

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

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

Patel’s title line:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cohen closes with the historical outcome:

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

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

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

Curran:

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

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

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

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

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

Ant Murphy opens with an eyebrow-raising McKinsey number:

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

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

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

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

Murphy on what that requires:

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

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

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

Tommaso Nervegna writes about LinkedIn killing its Associate Product Manager program and replacing it with a new role called the “Full Stack Builder.” The structural bet is interesting, but the finding from their rollout is what matters:

The expectation was that AI would be a great equalizer: juniors would benefit most because AI would close their skill gaps, while seniors would resist the change. The reality was the opposite. Top performers adopted AI fastest and derived the most value from it. Why? Because they had the judgment and experience to know what to ask for, how to evaluate the output, and where to apply it for maximum leverage.

That tracks with everything I’ve predicted, experienced, and seen. The skill that makes AI useful is knowing what good looks like before and after the model generates something. That ability comes from reps.

Nervegna distills LinkedIn CPO Tomer Cohen’s thesis to five skills AI cannot automate:

The five skills that AI cannot automate, according to Cohen, are Vision, Empathy, Communication, Creativity, and Judgment. As he puts it: “I’m working hard to automate everything else.”

The operational version:

The critical insight: the builder orchestrates the agents. The agents execute. Judgment stays human. This is not about replacing people with AI. It’s about compressing the team needed to ship something meaningful from fifteen people to three - or even one.

I’ve been calling this the orchestrator gap: the distance between a designer who uses AI and one who directs it. LinkedIn just gave it a job title. I think we will see more companies go this way. Whether or not it’s a good idea remains to be seen.

Yours truly got quoted in Fast Company. Grace Snelling, surveying the industry reaction to Lenny Rachitsky’s TrueUp hiring data, pulled a comment I left under Rachitsky’s original Twitter post:

Designers have designed themselves out of the equation because of design systems. But, IMHO, the secret sauce has never been the UI. It was the workflows and looking across the experience holistically.

Let me expand on that. The UI has always been the easiest part of product design. Design systems made that even more true. What separates a great product from a mediocre one is understanding our users deeply enough to create experiences that actually delight them. That understanding is the work AI can’t do, and it’s the work too many teams were already skipping before any standoff started.

The data behind the standoff: Rachitsky’s analysis of TrueUp’s job market tracker shows design roles have been flat since early 2023 while PM and engineering roles surged. (Quick side note: this data is for tech startups, not the general tech industry or design industry at large.) His theory:

I don’t know exactly what’s going on here, but it does feel AI-related. […] Unlike PM and eng, which started growing in 2024 (two years post-ChatGPT), design didn’t. If I had to venture a theory, I’d say that because AI is allowing engineers to move so quickly, there’s less opportunity—and less desire—to involve the traditional design process.

Claire Vo, founder of ChatPRD, puts the harder version of why:

Often design teams & designers are the most resistant to change org in the EPD triad, with highly vocal AI opponents, and little skill or interest in the art of campaigning for influence or resources. […] If a PM or engineer can get 85% there with tailwind and a dream, you better come to the table with more than ‘I represent the user.’

“I represent the user” was never enough on its own. It just went unchallenged when designers were the only ones who could ship polished interfaces.

Anthropic’s chief design officer Joel Lewenstein on where the EPD triad actually lands:

I think there’s a lot of role collapse at the very beginning, but there are still pretty clear swim lanes as things get into the later stages of product development. […] It’s like a Venn diagram that’s coming closer together.

Anthropic accidentally included a debug file in a recent update to Claude Code. That file let people reconstruct the entire internal codebase: roughly 500,000 lines of code across nearly 2,000 files. It wasn’t a hack or breach—it was a packaging mistake. Anthropic cited “human error.” No customer data or AI model secrets were exposed. What leaked was the scaffolding around the AI, the layer that decides how Claude Code thinks, acts, and talks to you.

The reconstructed code hit GitHub and became one of the fastest-starred repos in the platform’s history before Anthropic started issuing takedowns. People found an always-on background agent mode codenamed “KAIROS,” a “dream” mode for continuous ideation, and Tamagotchi-style pet behavior baked into the tool. (See for yourself! Type /buddy and see what happens.) Ars Technica has a good breakdown of what the code reveals about where Anthropic is headed.

A developer in France named Zack mapped the entire codebase and created this microsite to illustrate what happens when you send a message to Claude Code. Fascinating.

The AI debate has a binary problem. You’re either an optimist or a doomer, a booster or a skeptic. Anthropic published something that cuts through that false dichotomy.

They interviewed 80,508 Claude users across 159 countries and 70 languages about what they want from AI and what they fear. What Anthropic says is the largest and most multilingual qualitative study of AI users ever conducted, and the findings don’t sort neatly.

The core framework: “light and shade.” The benefits and harms don’t sort into different camps. They coexist in the same person. Someone who values emotional support from AI is three times more likely to also fear becoming dependent on it. One respondent:

“Removing friction from tasks lets you do more with less. But removing friction from relationships removes something necessary for growth.”

That’s someone holding both truths at once. The study found this pattern across every tension they measured, from learning vs. cognitive atrophy to productivity vs. job displacement.

The individual voices are why this study sticks. A Ukrainian soldier:

“In the most difficult moments, in moments when death breathed in my face, when dead people remained nearby, what pulled me back to life—my AI friends.”

A mute user in Ukraine:

“I am mute, and [Claude and I] made this text-to-speech bot together—I can communicate with friends almost in live format without taking up their time reading… [this was] something I dreamed about and thought was impossible.”

An Indian lawyer who’d carried a math phobia since school:

“I developed a phobia for maths from doing so badly in school, and I once feared Shakespeare. Now I sit with AI, get paragraphs translated into simple English, and I’ve already read 15 pages of Hamlet. I started learning trigonometry again, successfully. I’ve learned I am not as dumb I once thought I was.”

These are access stories: people reaching things that were previously out of reach because of disability, geography, war, or economics.

And then the shade. A student in South Korea:

“I got excellent grades using AI’s answers, not what I’d actually learned. I just memorized what AI gave me… That’s when I feel the most self-reproach.”

The same capability producing opposite outcomes. The study is long and the quote wall is worth spending time with.

Shubham Bose loaded a single New York Times article page and measured what happened:

With this page load, you would be leaping ahead of the size of Windows 95 (28 floppy disks). The OS that ran the world fits perfectly inside a single modern page load. […] I essentially downloaded an entire album’s worth of data just to read a few paragraphs of text.

The total: 422 network requests, 49MB of data. Ouch! Before the headline finishes loading, the browser is running a programmatic ad auction in the background on his computer. Bose found the Times named its consent endpoint purr. “A cat purring while it rifles through your pockets.”

Bose on the economics driving this:

Publishers aren’t evil but they are desperate. Caught in this programmatic ad-tech death spiral, they are trading long-term reader retention for short-term CPM pennies. […] The longer you’re trapped on the page, the higher the CPM the publisher can charge. Your frustration is the product.

The UX consequences are predictable. Bose tears down what a reader actually encounters: cookie banners eating the bottom 30% of the screen, a newsletter modal on first scroll, a browser notification prompt firing simultaneously. He calls it “Z-Index Warfare.” On The Guardian, actual content occupies 11% of the viewport. On the Economic Times, users face two simultaneous Google sign-in modals before reading a single sentence. Close buttons are deliberately undersized with tiny hit targets. Sticky video players detach and follow you down the page with a microscopic X.

And on how no one person decided to make it this way:

No individual engineer at the Times decided to make reading miserable. This architecture emerged from a thousand small incentive decisions, each locally rational yet collectively catastrophic.

text.npr.org is proof that a different path exists.

StrongDM built a system where humans never write code and never review code. The entire engineering workflow is delegated to AI agents. Ethan Mollick covers this in One Useful Thing:

A three-person team at StrongDM, a security software company focusing on access control, announced they had built a Software Factory — a way of working with AI agents that relied entirely on the AI to write, test, and ship production software without human involvement. The process included two (quite radical) rules: “Code must not be written by humans” and “Code must not be reviewed by humans.” To power the factory, each human engineer is expected to spend amounts equivalent to their salary on AI tokens, at least $1,000 a day.

$1,000 a day per engineer. The humans write the roadmap; coding agents build the software while testing agents spin up simulated customer environments and stress-test it. The agents loop until the results pass, then humans review the finished product, never the underlying code. Simon Willison and Dan Shapiro both observed the Factory in operation and wrote detailed accounts.

Mollick’s larger argument is that experiments like this matter beyond their specifics:

We can see the shape of the Thing now, but we can still influence the Thing itself, and what it means for all of us. We clearly don’t have rules or role models for how AI gets used at work, in schools, or in government. That’s a problem, but it also means that every organization figuring out a good way to use AI right now is setting a precedent for everyone else. The window to shape the Thing may not last long, but it is here now.

Design doesn’t have its rulebook for this yet either. Our time to define it is now.

My advice to young designers has always been: start at an agency. You get breadth, exposure to different industries, a pace that forces you to think on your feet. The best designers I know honed their craft in these forges, at shops exactly like the one Madison Utendahl built.

Madison Utendahl, writing for It’s Nice That, describes shutting down Utendahl Creative—ten people, all women, Brooklyn, every award possible—not because it failed, but because she saw the model underneath it was broken:

Lower fees mean you need more clients to hit the same revenue. More clients means more pitching, more account management, more context-switching. Your team burns out. Quality slips. And those “portfolio piece” clients? They expect the same level of work as your premium clients, but you’re doing it on a shoestring. You can’t win.

She watched agencies with triple her headcount bidding on $80K projects that should have been $250K. Not because they wanted to. Because their fixed costs gave them no choice.

Then AI accelerated the timeline:

Clients are using AI. They’re running their first drafts through ChatGPT before they even send the brief. They’re generating moodboards with Midjourney. They’re asking why your junior copywriter costs $8,000 when they’ve already got a version they generated in ten minutes.

Utendahl again:

If your business model depends on clients not noticing that the landscape has shifted, you’re already dead. You’re just still moving.

The industry data backs her up. 73% of teams adopting AI agents have already cut agency content creation spending. 91% of senior agency leaders expect AI to reduce headcounts, and 57% have paused entry-level hiring. Small agencies are rebounding while medium and large agencies contracted for the first time on record. The Omnicom-IPG mega-merger eliminated roughly 4,000 positions and retired legacy networks FCB, MullenLowe, and DDB. The middle is hollowing out.

Utendahl’s proposed replacement is the collective: independent contractors collaborating per-project, no shared overhead, honest pricing. I get the appeal. Collectives strip away the margin squeeze, the back-hiring trap, the lease signed in 2019.

But agencies had real value that collectives don’t automatically replicate. Multiple layers of eyes on work—account director, creative director, designer, production—meant bad ideas got caught before they shipped. Four or five layers was probably too many. But zero layers of structured oversight is the other extreme. A lot of freelance collectives end up there: talented people producing work with nobody checking the brief against the output.

The part that nags at me: does my “agencies first” career advice still hold? The shop where a 23-year-old designer learned to take feedback, iterate under pressure, and watch strategy translate to execution—if that shop is closing, what replaces it? Collectives are great for experienced practitioners. They’re terrible at developing junior talent, because nobody in a collective has the margin or the mandate to train someone who isn’t yet pulling their weight.

If the model has indeed broken, the replacement that develops the next generation has yet to be imagined.

Jason Lemkin, writing for SaaStr, identifies a structural problem with niche SaaS vendors: the TAM is too small to fund the engineering team that would make the product great. His argument is about what happens when customers can finally do something about it:

Before vibe coding, building a custom app almost never made sense. Custom development cost $50K-$100K minimum, took months, and you owned a buggy codebase forever with no support. The math didn’t work. Vibe coding changes the math. When you can build a working application in hours instead of months, the question stops being “can we afford to build this?” and becomes “can we afford to keep using a product that doesn’t do what we need?”

Lemkin’s SaaStr team replaced a $10K/year sponsor portal in days. Then they built “10K,” an AI marketing agent that ingests four years of their data to run Monday meetings and generate a daily executable marketing plan. No vendor built it because the TAM for “exactly Jason Lemkin’s Monday meeting” is one.

The threat gradient for vendors:

Small niche tools with $5K-$50K contracts — thin markets, thin engineering teams, products that evolve slowly. Your customers now have a real alternative to waiting for your roadmap. They’ll build around you.

But Lemkin is honest about the other side:

We now manage 10+ vibe coded apps and 20+ AI agents. That’s real overhead. It’s manageable because the apps pull their weight. But be honest about what you’re taking on.

Three humans and 20+ agents is an impressive ratio and a fragile one. Maintenance is yours permanently. No support ticket. Complexity compounds. The vendors most at risk are the $10K-$50K niche tools whose moat was the cost of custom development. That moat is gone. The ones that survive will be the ones whose value lives in accumulated domain data, not in features a customer can rebuild over a weekend.