Most people aren’t listening.

I’m not talking about AI taking your job. I’m talking about the people asking whether we even understand what we’re building, whether we can control it, and what happens when the people in charge care more about valuation than safety. These aren’t fringe voices. Some of them literally built the foundations of modern AI.

And they’re worried.

This post is my attempt to point you toward the people and organizations I think are worth your time. I don’t agree with every single take on this list. But these are the conversations that actually matter, and most people aren’t even aware they’re happening.

The race to the bottom

The AI industry has no meaningful oversight. No regulatory body audits these models before they ship. No accountability when something goes wrong. The companies building the most powerful systems anyone’s ever built are essentially self-governing, and they’re doing exactly what you’d expect self-governing corporations to do: whatever is fastest and most profitable.

Ronan Farrow and Andrew Marantz just published a piece in The New Yorker about Sam Altman, built on over a hundred interviews and internal documents. A board member quoted saying, “I don’t think Sam is the guy who should have his finger on the button.” It’s one company, but it’s not one company’s problem. The entire industry is in an arms race where safety is a line item, and speed is the product. The people on this list have been saying this for years. Testifying before Congress. Writing open letters. Quitting their jobs to speak freely. And still, nothing has changed structurally.

That has to change.

The ones sounding the alarm

Geoffrey Hinton is often called the godfather of deep learning. He spent decades building the neural network architectures that power the AI systems we use today. Then he left Google specifically so he could speak freely about the risks. Yoshua Bengio, the other godfather of deep learning, has done the same. He’s publicly called for regulation and warned about existential risk. When two of the three people most responsible for modern AI are telling you something is wrong, that’s not alarmism. That’s a signal.

Eliezer Yudkowsky has been writing about AI alignment for over twenty years. Long before “alignment” was a word anyone in Silicon Valley bothered with. He’s polarizing. He’s uncompromising. He will test your patience. But he’s been more right about the trajectory of AI development than most of the people who dismissed him, and his writing on the alignment problem is some of the clearest thinking on the subject that exists.

Roman Yampolskiy is an AI safety researcher whose core argument is blunt: we have no proof that AI can be controlled, and we’re building it anyway. Not “we haven’t figured it out yet.” We have no proof it’s even possible. That distinction matters, and most people haven’t sat with it long enough.

Connor Leahy brings something different to this conversation: urgency without the academic distance. He founded Conjecture and now leads Control AI, and he’s one of the younger voices in this space pushing hard on governance and policy. He’s not waiting for consensus. He’s building the case for action now.

Timnit Gebru co-authored a research paper on the risks of large language models while at Google. Google fired her for it. Let that sit for a second. One of the companies building these systems fired a researcher for documenting the harms. She went on to found the DAIR Institute and has continued the work, but her story tells you everything you need to know about how seriously these companies take internal criticism.

The ones making it make sense

The researchers above are doing critical work, but let’s be honest, most people aren’t going to read a paper on AI containment theory. That’s where communicators come in.

Tristan Harris made tech ethics a mainstream conversation with The Social Dilemma. Through the Center for Humane Technology, he’s been one of the most effective people at translating abstract tech risks into something your parents can understand. His focus has shifted heavily toward AI, and nobody’s been better at framing these issues for a general audience.

Hannah Fry is a mathematician who communicates the implications of AI and algorithms without dumbing anything down. She holds complexity and clarity at the same time, which is harder than it sounds, and her work is a good starting point if the more technical voices feel overwhelming.

Karen Hao is a journalist who has done some of the best investigative reporting on AI’s real-world impact, from bias in facial recognition to the human labor behind “automated” systems. Her work at MIT Technology Review and The Atlantic has shown what happens when these systems meet actual people, and it’s not the clean story the press releases tell.

Where to start

If you’re reading this and thinking “okay, but what do I actually do,” here are some places to start:

Watch The AI Doc: Or How I Became an Apocaloptimist. Daniel Roher’s documentary came out earlier this year and features several of the people on this list. It’s not perfect, but it’ll get you up to speed faster than anything else on this list.

The Human Movement is focused on public awareness and grassroots mobilization. If you’ve never engaged with AI safety beyond the occasional headline, this is a good front door.

Human Compatible AI is Stuart Russell’s research center at UC Berkeley, working on the technical side of building AI systems that are actually aligned with human values. Russell wrote the textbook on AI, the one used in most university courses, and this is where he’s putting his energy.

Control AI tackles policy and governance. If you want to understand what regulatory frameworks might actually look like and why they matter now, not later, start here.

This isn’t a doom post

I use AI every day. I build with it. I’m not anti-AI, and I’m not going to pretend otherwise.

But I am paying attention to the people who understand these systems at a fundamental level and are saying, clearly and repeatedly, that we need to slow down and think about what we’re doing. The fact that most people can’t name a single person on this list bothers me. These aren’t obscure academics yelling into the void. They’re some of the most accomplished people in AI, ethics, and tech journalism, and the companies building these systems are not listening to them.

The least you can do is start listening. And if you’re already listening and have others to add to the list, let me know!

I use AI every day. I’m not performing some Luddite rebellion from my standing desk. Claude is open. I reach for it constantly, and it helps. That’s not the issue.

The issue is what happened to the rest of the job while nobody was looking.

The Shift Nobody Named

Writing code is a generative act. You’re building something. You’re in flow, that state where two hours vanish, and you look up, and the thing works, and you feel good. That used to be most of the day.

Now most of the day is evaluation. Reviewing AI-generated output. Reverse-engineering logic that came from somewhere outside your own head, except the “somewhere” isn’t even a colleague you can ask questions to. It’s a model that was very confident and very fast and may or may not have understood what it was doing.

These are two different cognitive gears. Generation gives you energy. Evaluation takes it. And the human brain isn’t built for what we’re asking it to do right now.

Working memory holds about four to five items at once. That’s it. Every PR you review asks you to load up a new context, different feature, different assumptions, different patterns, and hold it all in your head long enough to decide if it’s right. Do that a few times, and you’re fine. Do it dozens of times a day and you’re not reviewing anymore. You’re reacting.

There’s a name for this: decision fatigue. Your ability to make good judgments degrades with every decision you make. By afternoon, fatigued reviewers are approving things with an “LGTM” that their morning selves would have flagged. Not because they stopped caring. Because the brain ran out of capacity to care with precision.

We’re stuck in this mode for hours at a time now, context-switching across PRs that all look plausible but need real attention to verify. Developers on high AI-adoption teams are merging 98% more pull requests, but PR review time increased 91%. The volume doubled. The brain didn’t.

You can’t maintain the same standard of care at twice the volume. Something has to give. And right now, what’s giving is us.

The Dashboards Look Great

Here’s the part that makes it worse: from the outside, everything looks like it’s working. More PRs merged. More tickets closed. Velocity is up. Leadership sees acceleration and assumes the team is thriving.

What they don’t see is that the humans behind those numbers are absorbing the cognitive cost of all that speed. Fortune reported that AI gave workers roughly six extra hours a week. Nobody got to keep them. The workload expanded to fill every minute that got freed up. That’s not productivity. That’s a treadmill that got faster.

And I get it. If you’re a VP staring at a Jira board that’s never looked greener, why would you question it? The metrics are saying exactly what you want to hear. But the metrics don’t measure the developer who stopped reading PRs line by line because there are just too many. They don’t measure the senior engineer who used to catch subtle architectural issues but now has to triage so much volume that she’s pattern-matching instead of thinking. They don’t measure the mass-approval that happens at 4:47 pm on a Friday because everyone’s cooked.

Addy Osmani called this “comprehension debt”, when teams ship code faster than they can understand it. I’d call it something simpler.

We’re tired.

Still Here, Still Caring

This isn’t a post about quitting. It’s not about checking out or going back to writing everything by hand. It’s about the exhaustion that hits people who are still trying to do good work inside a system that keeps raising the tempo without asking if anyone can keep up.

The developers who still read every line of a PR. Who still flags the thing that “probably works fine” but doesn’t sit right. Who are tired because caring takes more effort than it used to.

TechCrunch ran a piece in February with a headline that stuck with me: “The first signs of burnout are coming from the people who embrace AI the most.” Read that again. The ones burning out aren’t the skeptics. They’re the ones who leaned in. The ones who did the thing everyone told them to do.

38% of developers say reviewing AI-generated code is harder than reviewing code from a colleague. Honestly? That tracks. When a teammate writes something, there’s a conversation behind it. A shared context. A Slack thread. When AI writes something, you’re on your own with a diff and a gut feeling.

It’s Friday. We did the work. We reviewed the code. We caught the things that needed catching. We’re tired. And on Monday, we’ll do it again, because that’s what giving a damn looks like.

But someone should probably notice.

Not all at once. It was gradual. A tool I installed to try out six months ago. A dependency that an agent dropped in to get something working. A gem that showed up on a backup restore from a machine I barely remember using. Each one was perfectly reasonable at the time. Collectively, a mystery.

I had no idea what was actually installed on my computer, and for a while, I just lived with that.

It wasn’t always agents

Package sprawl is older than AI. It starts the minute you follow a tutorial that tells you to npm install -g do something you’ll use once and never think about again. Then you restore from a backup without auditing what came with it. A new language ecosystem enters your workflow and brings its own installer, its own conventions, and its own quiet list of things it decided you need.

The problem isn’t that packages get installed. It’s that there’s no master list. No single place to go and say: here’s everything, where it came from, what it does, and whether I actually still need it.

AI agents made this worse. Genuinely worse. Not because they’re doing anything wrong (they’re doing exactly what you asked), but because they move fast and they install quietly. You tell an agent to get something working, and it will, and three deploys later, you’re staring at a global npm package you don’t recognise and trying to remember which conversation put it there.

Too many managers, zero answers

On a Mac, the actual audit goes something like this. You check Homebrew. Then casks. Then, the global npm packages. Then pip. Then Ruby gems, and by the way, are those system gems or gems you installed? Then Cargo binaries. Then the Mac App Store, which technically has a command-line interface if you know where to find it.

A lot of package managers. Different commands, different output formats. At no point do they talk to each other.

I kept a mental model of my machine that was somewhere between optimistic and wrong. I’d run brew list, feel briefly in control, and then remember I hadn’t checked npm in months. It wasn’t a workflow. It was archaeology.

A weekend and an idea

Here’s what I want to say about AI that I don’t say enough: it has genuinely changed what one person can build alone in a short stretch of time.

Stockpile was a back-burner idea for a long time. The kind of thing where you know exactly what you want, you can picture how it should work, and you also know it’ll take longer than you have. So it sits there.

This one didn’t sit. I built it in a weekend. Not because AI wrote it for me. I made every architectural decision, debugged every edge case, and argued with the output constantly. But the friction that usually kills side projects before they start just wasn’t there. The gap between “I want this thing to exist” and “this thing exists” is closing in a way that’s hard to overstate if you build things on your own.

That part still surprises me, honestly.

So I built the thing

Stockpile is a bash script. You run it once. It scans all seven package managers, assembles the results, and opens a browser-based dossier of everything on your machine: every package, every version, install paths, descriptions, and run commands. No server. No account. Nothing leaves your machine.

That last part mattered to me. There’s no reason a tool like this needs a cloud component. Everything is local. The name felt right, too: a stockpile is yours. You should know what’s in it.

I built it because I needed it. I use it now. And it turns out the first time you run it and see everything laid out in one place, the feeling is somewhere between satisfaction and mild alarm.

You’ll find things you forgot about. Probably some things you don’t recognise. Maybe a few things your agents installed that you never explicitly asked for.

It’s free and open source. If your machine needs an audit, stockpile is ready when you are. I’d genuinely love to know what you find.

So I built a personal marketplace. A private GitHub repo that acts as my own skill distribution system. I install it on a new machine, pick the skills I want, and everything works the way I expect it to. No setup rituals, no re-explaining how I like things done.

Here’s what that looks like and why I think more people should be doing this.

Same session, different day

Some skills are universal. I want my commit format everywhere. Others only matter in context, like how my Obsidian vault is structured or where session logs go. And I keep moving between machines, so anything stored locally is one laptop swap away from gone. The universal stuff needs to be portable. The project-specific stuff needs to stay out of the way when it’s not relevant.

Claude Code has memory and CLAUDE.md files that help with some of this. But there’s a gap between “remembering facts” and “knowing how to do something your way.” Memory stores that you prefer conventional commits. A skill actually enforces the format, stages the right files, and asks you to confirm (or not) before committing. One is a note on a whiteboard. The other is a workflow.

That distinction matters. The more workflows you encode, the less prompting you do. And the less prompting you do, the more time you spend on the actual work.

Your repo is the marketplace

The setup is almost comically simple. Anthropic added plugin and marketplace support to Claude Code, and all it takes is a GitHub repo with a marketplace.json file and a folder per plugin. Each plugin contains a SKILL.md markdown file with instructions that Claude loads when the skill triggers. That’s the whole thing.

Here’s what the structure looks like:

your-marketplace/
├── .claude-plugin/marketplace.json
└── skills/
    ├── your-skill-one/
    │   ├── .claude-plugin/plugin.json
    │   └── skills/your-skill-one/
    │       └── SKILL.md
    └── your-skill-two/
        └── ...

You register it as a marketplace in Claude Code, install whichever plugins you want, and they show up as slash commands. On a new machine, you add the marketplace and install your skills. Done.

The skills themselves are just instructions. There’s no SDK, no special syntax. You write what you want Claude to do in markdown, and it does it. If you can write a good prompt, you can write a skill.

What I built in a weekend

I’m not going to walk you through how to build each one. But I want to give you a sense of the kinds of workflows you can turn into skills, because the range is wider than you’d expect.

Vault setup. I use Obsidian as a personal knowledge base. This skill scaffolds the entire vault structure on a new machine. Directories, templates, config files, and the CLAUDE.md that tells Claude how to navigate the vault. I run it once per machine and never think about it again.

Session saving. At the end of every coding session, Claude automatically saves what happened to my Obsidian vault. Plans updated, decisions made, lessons learned, files changed. It appends to the project’s notes, writes a dated session log, and does it without me asking. I added an instruction to my global CLAUDE.md that tells Claude to invoke this skill at the session end. It just happens now.

New project. When I start a new project, I say “new vault project,” and Claude creates a folder from a template. plan.md for goals and status, notes.md for decisions and learnings, a sessions directory for logs. Consistent structure across every project without me remembering what goes where.

Conventional commits. I wanted Claude to use a specific commit format: type(scope): message. Not a linter, not a git hook. Just Claude, knowing how I commit and doing it right every time. The skill checks the diff, proposes a message in the right format, and waits for me to confirm. Forty lines of markdown replaced a tool I would have had to install, configure, and maintain.

Blog post research. I decided to write more this year, and this skill has made it easier to stick to. It lets me bounce topic ideas off something, searches for what’s trending in my area, suggests angles I might not have considered, and pulls together an outline I can react to. When a post is ready, it even publishes a draft straight to my WordPress site. Saves me an hour of tab-hopping before I’ve even started writing.

Those are just a few from my marketplace. All markdown. All in one repo. But they cover enough ground to show what’s possible.

The compound effect

The interesting thing isn’t any single skill. It’s what happens when they stack.

Claude saves my session, which means next time it can read what happened last time. It uses my commit format, which means I never review a commit message, wondering what format to use. It knows my vault structure, which means every project starts the same way and every session ends with a clean log.

Each skill removes one more thing I used to do manually. And because they’re all in the same marketplace repo, I can install the full set on any machine in about two minutes.

I’ve been thinking of it like this: most people configure their AI tools. Preferences, settings, maybe a CLAUDE.md file. That’s fine. But building skills is a different thing entirely. You’re teaching the AI how you work, not just what you like. The more you encode, the less friction there is between having an idea and executing it.

Maybe you should, too

I’m not saying everyone needs five custom skills and an Obsidian vault. But if you use an AI coding assistant daily and you keep repeating yourself, you already have the raw material for a skill. That commit format you keep correcting? That’s a skill. How do you structure new projects? Skill. The thing you do at the end of every session that you keep forgetting? Definitely a skill.

The whole point of working with AI is that it’s programmable. Not in the traditional sense. You don’t write functions and import libraries. You write instructions in plain language, and the AI follows them. If you’re going to use these tools every day, you might as well build the workflows that make them actually yours.

This past week, I got handed a project that required backend work. Not because I have backend experience – I don’t, really – but because “AI can handle the parts you don’t know.” And honestly, that’s not entirely wrong. Claude Code got me through it. I wrote what I could, leaned on it for what I couldn’t, and when the dust settled, the code was in decent shape. I ran my own review. Frontend looked solid. A few tweaks. Tests passed. Manual walkthrough, nothing glaring.

I pushed the branch, opened the PR, and handed it to Cursor for a second pass. A couple of issues surfaced. Fixed them. Then CodeRabbitAI got its turn. A couple more. Fixed those too. Three layers of review, every issue resolved. I tagged my human colleagues, feeling pretty good about the whole thing.

That’s where the confidence ended.

The Comment That Made Me Feel Two Things at Once

My colleague, a full-stack engineer with real backend experience, left a comment on the PR. They knew going in that I didn’t have much backend context, so they didn’t just tell me what was wrong. Instead, they asked me to try something: open the app in two windows, change profiles in one, make updates in the other, try to update and save, and see what happens.

I did it. The profiles fell out of sync.

It was immediately obvious, once I saw it, that it was the kind of thing where you go “oh, of course” the second it breaks. But I never would have thought to test that scenario on my own. I hadn’t spent years debugging backend state. I didn’t have the mental model for what could go wrong when a user has two sessions running simultaneously and starts mixing state between them. That’s hard-won intuition, built from experience I just don’t have yet. No AI tool flagged it either. Not Claude Code, not Cursor, not CodeRabbitAI. The bug just sat there, quiet, untouched by every layer of “smart” review I’d thrown at it.

What I appreciated most was how my colleague handled it. They didn’t write the fix in the comment. They didn’t tell me the answer. They trusted me to find it once I could see it. That’s a specific kind of mentorship, the kind that respects your ability to learn while acknowledging the gap. I was humbled and genuinely grateful at the same time, which is a weird combination but also kind of the best possible outcome of a code review.

The Myth of the Foolproof Stack

I’m not anti-AI. I use it every day, and I’m not going to pretend otherwise. But I want to be honest about what that PR showed me, because I don’t think the experience is unique to me.

We’ve been sold a version of AI-assisted development where layering more tools means fewer things fall through the cracks. More coverage, fewer blind spots, better outcomes. And when you’re in the middle of it, running your code through three different review passes, watching issues get flagged and resolved, it genuinely feels airtight. The pitch is clean. The reality, as it turns out, is messier.

Here’s the part that got me: CodeRabbit, one of the tools I used on that very PR, called 2025 “the year the internet broke.” Change failure rates up 30%. Incidents per pull request up 23.5%. Their own data, about the exact category of tool I was using, to feel safe. A separate 2026 Sonar survey found that teams using AI coding tools are 46% more likely to experience production incidents than those that don’t. That’s not a marginal difference.

Amazon’s internal AI agent, Kiro, autonomously decided the fix for a minor issue was to delete and rebuild a production environment. Thirteen-hour outage in an AWS. Amazon called it “user error.” Sure, ok. Forrester now predicts that 50% of companies that attributed headcount reductions to AI will quietly rehire for those same roles by 2027. Google’s own numbers show 20% of their 2025 AI engineering hires were former employees they’d previously let go.

That’s not optimization. That’s a very expensive loop.

The Short Stick

I understand AI is getting better. The models are improving, the tooling is maturing, and some of these failure modes will happen less as that continues. I genuinely believe that. I’m not writing this as someone who thinks we should go back to writing everything by hand.

But we’re living in the meantime. And in the meantime, companies are cutting engineers based on anticipated future capabilities, not demonstrated current ones. They’re shipping AI-reviewed code into production, watching things break, and then quietly hiring people back with no acknowledgment that the original bet didn’t pay off. The people who got laid off aren’t getting apologies or reinstatement. They’re getting contractor gigs at lower pay if they’re lucky. The idea that humans are optional is already starting to crack under its own evidence, but the cost of that lesson is being absorbed by the people who can least afford it.

The most valuable thing in that PR wasn’t a tool. It was a colleague who understood what I didn’t know, cared enough to teach me instead of just writing the fix themselves, and trusted me to get there once I could see the problem. That’s not something I can prompt my way to. No model is going to replicate that specific kind of knowledge transfer, built from real experience, offered with actual generosity.

AI caught some bugs on that PR. A human caught the one that mattered.

I’m familiar but relatively newish to these tools, so take this for what it is. I’m not anti-AI. I use it every day. But I’ve been watching something happen across the industry that I think is worth talking about: It feels like AI is making our UI decisions for us, and we’re just going along with it. Maybe call me old school, but I think products should have their own soul when it comes to UI and UX. Otherwise, what actually sets us apart?

These days, someone fires up a vibe coding tool and builds a prototype. Could be a manager who’s excited about AI, a designer who started dabbling in code, a dev who wants to move fast. It comes back looking polished. React, Tailwind, shadcn, the whole default stack. It feels fast. It looks professional. And everyone accepts it. The UI direction, the component approach, the framework, the styling, all of it decided by whatever the AI defaulted to that day. By a language model optimizing for the most common output.

From what I can tell, this is happening more and more. And I don’t blame anyone for being excited. These tools can be fun to use. Designers can build something real without waiting on engineering. Decision-makers can see a working prototype in hours instead of weeks. That feels like progress, and in some ways, maybe it is. But there’s a difference between using AI as a tool and letting AI make the decisions. Right now, a lot of people are doing the second thing and calling it the first.

Your product now looks like everyone else’s

When you let AI decide your UI, everything converges. You can spot a shadcn app from across the room. The spacing, the rounded everything, the muted grays, the specific way the buttons and inputs feel. It’s the default aesthetic. Every vibe coding tool out there generates the same stack, so every prototype comes back looking like a cousin of the last one. That’s what happens when a model decides.

And there’s a feedback loop making it worse. AI generates shadcn code. More shadcn code ends up in training data. AI gets even better at generating shadcn code. Round and round. Your product’s look is being decided by what a language model saw the most during training, not by your brand team or your designers. Not by anyone who’s talked to your users. Super inspiring stuff.

If your product looks identical to your competitor’s product, what exactly is your differentiator? UI and UX used to be a competitive advantage. The way your app felt was part of why people chose it. When every SaaS dashboard looks like it came from the same AI prompt, that advantage disappears. Your product becomes a commodity before you even ship it.

shadcn released theming presets to address this. But swapping a color palette isn’t brand identity. It’s a skin. Your UI is part of your brand, and your UX is how people experience it. If your application looks and feels like every other AI-generated output, you’ve handed both to a default setting. Honestly, from a design standpoint, it feels lazy. We used to obsess over the details that made a product feel like ours. Now we’re accepting whatever the AI spits out because it looks clean enough. And it’s hard to even raise the concern because the AI made it look so good out of the box that questioning it feels like you’re the one slowing things down.

Choosing what’s right vs. what’s common

This is the part that gets lost. People see a polished AI-generated UI and assume the tool made a good decision. It didn’t decide at all. It predicted the most likely output based on its training data. shadcn and Tailwind are everywhere in that training data, so that’s what comes out. It’s not a recommendation. It’s a statistical echo.

But people are treating it like a recommendation. A manager vibe-codes a dashboard and thinks, “this is the direction.” A designer builds a prototype and assumes the stack is solid because the output looks professional. Nobody questions whether React is the right framework, whether Tailwind is the right styling approach, or whether shadcn is the right component strategy for their product and users. The AI picked it. It looks good. Ship it.

That’s not a design system either

On top of letting AI make UI decisions, people are also calling the output a design system. It’s not.

AI and shadcn are giving you components. It doesn’t give you governance, contribution models, versioning strategy, token architecture, or cross-team documentation. It doesn’t give you a shared language between design and engineering. What it gives you is a folder full of React files you copied into your repo.

A design system is an organizational tool. The hard part is never “make a button look nice.” The hard part is making sure multiple teams use the same button the same way, that it evolves without breaking things, and that someone owns the decision about what “primary” means across your entire product suite. shadcn doesn’t try to solve that. It’s not designed to. And that’s fine for what it is. But calling it a design system? That’s like calling a pile of lumber a house.

215 lines of React for a radio button

I get why shadcn exists. Building accessible UI primitives from scratch is hard. Getting focus management, keyboard navigation, and screen reader support right takes real expertise. That’s the problem shadcn and Radix are trying to solve, and it’s a legitimate one. But the solution has costs that nobody’s weighing because the AI never brings them up.

Paul Hebert recently tore down the shadcn radio button component. 215 lines of React. Seven imported files. 30 Tailwind classes. All to recreate something HTML has done natively for 30 years.

Instead of using <input type="radio">, shadcn renders a <button> with an SVG circle inside it, then uses ARIA attributes to tell screen readers it’s actually a radio button. Read that again. It’s a button pretending to be a radio button and relying on ARIA to cover for the fact that it didn’t just use the native element. The browser already solved this. Decades ago. But the AI doesn’t know that, and nobody asked.

Zoom out, and the abstraction stack is wild. Tailwind abstracts CSS. shadcn abstracts Radix. Radix abstracts the DOM. React abstracts the DOM. Four layers between your user and a checkbox. The AI chose every single one of those layers for you. It didn’t ask whether your team needs that complexity or whether a simpler approach would work. At enterprise scale, every one of those layers is a maintenance surface and a possible debugging headache. This is complexity cosplaying as simplicity.

There’s another cost nobody seems to talk about. Teams using Tailwind for long enough start forgetting actual CSS. The muscle memory goes away. When something breaks outside the utility class catalog, nobody knows how to fix it. You’ve traded foundational knowledge for convenience, and that trade gets expensive when things go sideways. The AI forgot to mention that part when it generated the code.

You’re locked in now

shadcn is React. Community ports exist for Vue and Svelte, but they’re unofficial, maintained by different people, with different APIs and different release timelines. If your enterprise has teams on Vue, Angular, Svelte, Rails, or plain JS, you’re now maintaining parallel component implementations or forcing everyone onto React whether they chose it or not.

Here’s what nobody notices: the AI chose React. Not your team. The prototype worked, it looked great, and it naturally became the starting point for real production code. Nobody went back to reconsider the foundation. Why would they? It worked in the demo.

Enterprise environments are messy. Legacy apps, acquired products on different stacks, internal tools built by teams who picked their own framework years ago. A design system needs to serve all of them. shadcn can’t.

What happens when React isn’t the dominant framework anymore? It will happen. jQuery was untouchable once. So was Bootstrap. If your UI is coupled to React’s ecosystem and release cycle, you’ve made a bet on one framework’s future. That bet has an expiration date.

The maintenance and governance

When you use shadcn, you copy source code into your repo. You now own every component. Bug fixes, accessibility patches, and breaking changes upstream are all your problem now. There’s no upgrade path. When shadcn updates, you manually diff and merge. Across how many apps? How many teams?

Tailwind without strict governance turns into class soup fast. Every team invents its own patterns. One team uses px-4 py-2 button padding, another uses p-3, a third wraps it in a custom class. Multiply that across hundreds of components and a dozen teams. Good luck with consistency.

Without shared tokens, “our blue” is three different hex values in three different repos. Without versioning, a component change in one app silently breaks patterns in another. Without contribution models, nobody knows who owns what or where the source of truth lives. That’s the work that goes into building a real system. None of it comes in the box with shadcn.

Nobody budgeted for any of this, by the way. Because nobody planned to adopt shadcn as the foundation. An AI picked it, a prototype got everyone excited, and now multiple teams are building on a decision that was never actually made.

So who’s actually deciding what our products look like?

That’s the question I keep coming back to. Vibe coding makes it easy for anyone to build something that looks production-ready, and that’s exciting. But “looks production-ready” and “is the right UI for your product” are not the same thing. Right now, AI is paving over that gap with polished output that feels like a decision was made when it wasn’t.

AI is great at generating code. It is not great at understanding your product, your users, or how your org works. It optimizes for “most common,” not “most appropriate.” And it will never tell you “yo, this might not be the right approach for what you’re building.” It just gives you shadcn and moves on.

Your UI, your UX, and your design system are business decisions. They touch brand, velocity, how teams work together, and how much technical debt gets carried for years. AI didn’t think about any of that when it decided what your product should look like.

I’m curious what other folks are seeing. Are we just accepting whatever UI the AI gives us now? Should vibe-coded prototypes quietly become our production UI? I might be wrong about some of this. I’d love to hear if others are seeing this and how they are navigating it.

This week, Jack Dorsey’s Block laid off more than 4,000 people. Nearly half the company is gone. The stock jumped 24%. Dorsey told the remaining employees that most companies would reach the same conclusion within a year and make similar structural changes. Before that, Amazon cut 16,000 corporate roles. Chegg gutted 45% of its staff. HP announced plans to cut up to 6,000 positions. Every single one of these moves was framed as an “AI efficiency” play. Significantly smaller teams. Leaner operations. The future.

I’ve been building for the web for a long time. Long enough to have seen multiple cycles of “this technology will change everything.” And some of them did. But I’ve never seen one where the pitch is this blunt: we are removing people and replacing them with software, and we think you should be excited about it. As someone who’s in the codebase every day, who has worked alongside people doing real, solid work only to watch them get let go, this one hits different. And if you’re a web worker right now, I know you’re feeling it too.

Refactoring the Workforce

The language around these cuts is telling. “Significantly smaller teams.” “Restructuring for AI.” It’s the vocabulary of refactoring, applied to people. And it reveals something ugly about how the people making these decisions think about the folks doing the work: we’re not assets to lead, mentor, or invest in. We’re bottlenecks to be optimized away at the first opportunity. Honestly, it’s gross.

But here’s what that framing misses entirely: the people and their teams are the platforms. The companies, codebases, and products are just the artifacts. The real platform, the thing that makes a product actually work, is the people who understand it. They hold the context, and these days, context is everything. They carry the intent. They know why a decision was made, not just what the decision was. Strip them out, and you don’t have a leaner company. You have a company, product, or codebase with no one left who understands it.

When you move the people who help build your product away from the foundational work, that’s not optimization. That’s a platform failure. You’re not reducing friction. You’re removing the people who understood where the friction came from in the first place.

This is the dependency trap. Someone looked at an org chart the way an engineer looks at a bloated package.json file and decided to rip things out. But people aren’t packages. You can’t just swap in an AI module and expect the same output, no matter how good the LLMs are getting.

Frictionless Fantasy

There’s this fantasy going around right now: the frictionless company. Small teams, AI-augmented, shipping at scale with minimal overhead. It sounds clean on a slide deck. In practice, it ignores everything that actually makes a product work.

Institutional knowledge. The connective tissue of company culture. The engineer who remembers why that weird edge case exists, or why the team decided against a particular API pattern three years ago. The person who knows that a feature looks simple but took six iterations to get right. The colleague who mentored you when you were new and didn’t know what you didn’t know. You can’t run npm install for that knowledge. You can’t prompt your way into it. It lives in the people who showed up every day and did the work, and when they are replaced with a fancy autocomplete, it’s gone.

When you treat people as interchangeable npm packages, you lose the thing that made them valuable: they were the platform. They weren’t just writing code or building a product. They were the reason any of it made a damn bit of sense. They carried context that no onboarding doc or AI summary can replicate. You wouldn’t rip a critical package out of production without understanding what depends on it. But that’s exactly what’s happening in this new AI era. And stripping them out in the name of efficiency creates a different kind of debt. Call it human debt. It compounds the same way technical debt does, quietly and then all at once, except nobody’s tracking it on a Linear board.

Intent vs. Output

AI is really damn good at generating output. Code, copy, designs. I use it every day, and I’m not going to pretend otherwise. But output without intent is just loud noise.

AI doesn’t fight for accessibility or correct implementation. It doesn’t push back on a PM about a dark pattern. It doesn’t sit in a meeting and say “this is going to hurt our users” when everyone else is nodding along. It does what it’s told. That’s useful, but it’s not stewardship.

Stewardship is the people who see a feature request and think about the user on the other end of it. The folks who build with empathy baked in, not because a linter told them to, but because they’ve been shipping long enough to understand what’s at stake. A product’s soul doesn’t live in the code. It lives within the people who care enough to fight for it. That intent is the human dependency that holds everything together. It’s the package you can’t find on any open source registry or have a robot generate from a poorly written prompt. And it’s the first thing that disappears when you “refactor” a team down to a skeleton crew.

The Communication Vacuum

What makes all of this worse is how it’s communicated. Or rather, how it isn’t.

There was a time when being a leader and leadership meant advocating for the people doing the work. Now it feels like leadership means only auditing them. Reviewing the roster the way you’d review a package-lock.json. What can we flag? What can we drop? What’s the minimum viable team we can get away with? Somewhere along the way, leading people turned into looking down and deciding who’s worth keeping.

4,000 people lose their jobs, and the stock jumps 24%. Record profits in the same quarter you eliminate half your workforce. And the message to those still at their desks? “We’re moving faster now.” No acknowledgment of what was lost. You just forced to disagree and commit. Oh yeah, and btw, you need to hurry up.

The anxiety this is creating in our industry goes beyond job security. It’s the slow realization that the people making these decisions don’t see us as people. They see us as a third-party dependency to be evaluated and potentially removed. That changes how you show up every day. It changes whether you fight for the thing that needs fighting for, or keep your head down because you don’t want to be the next module that gets uninstalled. And honestly? That is corrosive to us all. It eats at the exact qualities that made you good at your job in the first place.

Human Dependency

I’m not anti-AI. I think these tools are powerful, and I use them to do better work. But there’s a real difference between using AI to help people improve or perform better and using AI as a justification to remove them entirely. It’s a scapegoat and helps those at the top dodge any real accountability.

The human dependency isn’t a bug. It’s a feature and the entire point. We build products for people, and it takes people to know what that means. The judgment to get it right and the empathy to care whether we do: that comes from being human. From the ones in the trenches. The ones who are actually the entire platform.

So the next time someone frames a layoff as “AI efficiency,” ask yourself what’s actually being optimized away. Because it’s probably not friction. It’s most likely the people who actually gave a damn.

If you’re reading this and feeling the weight of it, just know you’re not alone. A lot of us are sitting with this same knot in our stomachs, watching the industry we love and we’ve helped build move in a direction that doesn’t seem to love us back. It leaves a hole that no robot will be able to fill, and that’s a damn shame.

Some of that is true. AI can help generate docs. It can lint tokens. It can draft release notes. I use AI tooling in my own design system work, and it’s useful for certain tasks. But the article’s argument falls apart because it misunderstands what design system teams actually do.

The 70% number is made up

Let’s start with the headline claim. 70% of design system work is replaceable by AI. Where does that number come from? The article never says. There’s no methodology, no survey, no data. It’s a confident assertion dressed up as a finding. That’s not analysis. That’s vibes.

And it matters because numbers like that end up in executive slide decks. They get used to justify headcount decisions. When you throw around “70%” with no backing, you’re not starting a conversation; you’re handing leadership a reason to cut your team.

The whole middle is missing

The article describes two modes of design system work: production (automatable) and governance (not automatable). That’s a clean framework, but it leaves out where most of the actual work happens.

Support. Maintenance. The daily human work of keeping a system alive and useful.

Answering questions in Slack. Pairing with a product engineer who’s trying to use your component in a context you didn’t anticipate. Triaging a bug that only surfaces in one team’s specific tech-stack setup. Writing a migration guide that accounts for six different integration patterns across your org. Helping a designer understand why the system works a certain way so they can make better decisions in their product.

This is humans supporting humans. It’s the thing that actually drives adoption, and it doesn’t show up in the article at all. You can’t automate a relationship. You can’t deploy a governance framework and expect people to trust your system. Trust is built through responsiveness. When someone files an issue and gets a thoughtful reply the same day, that’s what earns buy-in. No contribution policy document does that.

Fast and wrong is expensive

The article mentions that AI-generated output “was not perfect, but it was fast.” That sentence is doing a lot of heavy lifting. Fast and wrong is expensive. Someone still needs to review every AI-generated component API and token structure, and that someone needs deep expertise to know what “right” looks like.

You’re not eliminating the expert. You’re just changing what they do with their hands. The review work that remains requires the same knowledge, maybe more, because now you’re also debugging AI’s confident mistakes alongside your own.

The feedback loop doesn’t automate

Design systems are living things. You ship a component, teams adopt it, they use it in ways you didn’t expect, they file bugs, they request variants, you learn from that and iterate. That feedback loop is the engine of a healthy system.

AI doesn’t have relationships with your consumers. It doesn’t know that one team keeps misusing your modal because their product has a weird user flow. It doesn’t pick up on the pattern that three different teams have asked for the same thing in three different ways. That’s institutional knowledge built through support work, through being present, through paying attention to how people actually use what you’ve built.

Governance without execution is just meetings

The article elevates governance as the strategic, non-automatable layer. Governance matters, I’m not arguing that it doesn’t. But governance without strong execution underneath it is just Confluence pages and meeting invites. You earn the right to govern through the quality and reliability of what you ship. The components have to work. The documentation has to be accurate. The releases have to not break things. That foundation isn’t maintenance you automate away. It’s the thing that makes governance credible.

The real risk

The article says the true risk is that “some design systems never evolved beyond being structured UI libraries.” I’d argue the bigger risk is articles like this giving leadership permission to gut the teams that make systems work. If a VP reads “AI will replace 70% of this function” and takes it at face value, the people who get cut aren’t the governance strategists. It’s the engineers and designers who do the daily work of building, supporting, and maintaining the system.

Design systems aren’t factories, and they aren’t governance frameworks. They’re a service. The value lives in the ongoing, responsive, human relationship between the system team and the people who depend on it. AI is a useful tool in that work. It’s not a replacement for the people doing it.

The problem AI has with your design system

If you’ve used any AI coding tool to generate UI, you’ve seen this. You ask for a card component, and it gives you something that looks right but uses none of your tokens, references components that don’t exist in your library, and ignores every pattern your team spent months establishing. The output is plausible. It’s also wrong in ways that are tedious to untangle.

Your design system has opinions. It has a token taxonomy, component APIs, composition patterns, and a11y requirements. AI doesn’t know any of that. It’s working from general training data, not your system. So it gives you generic Bootstrap-flavored markup and leaves you to clean it up.

That cleanup time adds up fast, especially across a team.

Skills and rules: the 80/20 play

MCP servers for design systems are getting well-deserved attention right now and rightfully so. It’s actually where I spent time early on building and setting up to help provide context for the design system I work on. MCP is powerful, and it lets AI tools query your system’s components, tokens, and docs through a structured protocol. But it requires infrastructure. You need to build and run a server.

Claude skills and Cursor rules are the simpler path. A skill is a markdown file with instructions, reference material, and optional scripts. A Cursor rule is very similar, a text file that gives the AI context about your project’s conventions. No server, no API. Just documents that describe how your system works, loaded into context when relevant.

I’ve started investigating and building a couple of these for my own work, and the payoff has been immediate. Instead of fixing AI output that ignores my component library, the AI starts from the right place. It knows which components exist and which tokens to use by either guiding it to the proper files or providing an explanation right inside the file itself. I am still in early trials myself, and it’s not perfect, but the gap between what it generates and what I’d actually ship has gotten a lot smaller.

Types of skills your DS team could build

Out of the gate, I have been trying to come up with and define a few skills that I think could be useful.

A component usage skill is probably the highest-value starting point. Which component to reach for in common scenarios, correct props, slot patterns, and do/don’t examples from your docs. This alone changes the quality of what AI generates against your system.

A token reference seems like the natural companion. Your full taxonomy with guidance on when to use semantic vs. primitive tokens. If your system supports theming or multiple brands, this is where you encode that logic, so AI stops guessing.

An accessibility skill bakes your a11y standards into generation. ARIA patterns, keyboard navigation, focus management, contrast expectations. Catch it at the source instead of flagging it in review.

If you’ve got a legacy system and a current one (I’m dealing with this right now), a migration skill that knows both APIs and can map between them saves real time. A documentation skill keeps contributions consistent without a style guide that nobody reads. A code patterns skill captures your team’s file structure and naming conventions, the tribal knowledge that usually lives in someone’s head.

Project skills vs. personal skills

Not every skill needs to live in the repo. This is something I’ve been thinking about as I work on more of these.

Some skills belong at the project level, committed to the repo where the whole team benefits. Component usage, token reference, and a11y rules. These are the source-of-truth skills that keep everyone generating consistent, on-system code. When a new developer joins the team and starts using AI from day one, the AI already knows how your team works.

Other skills are just for you. Maybe you’ve got one for how you scaffold new components, or one that matches your PR description format, or shortcuts for tasks you repeat often, like version bump PRs. These can live in your user-level config and make you faster without imposing your preferences on anyone else.

The split matters. Project skills enforce consistency. Personal skills are about your own speed. Mixing them up creates friction, and nobody wants to inherit someone else’s personal workflow baked into the repo.

Why this matters now

Developers are already using AI to write code against your design system. That’s happening whether you’ve prepared for it or not. The question is whether the AI knows your system or is guessing.

I wrote recently about the AI productivity paradox, how AI often increases workload instead of decreasing it because you spend so much time reviewing and fixing output. Skills and rules attack that problem at the source. Give AI the right context upfront, and there’s less to fix on the other end.

We spent years meeting designers in Figma with component libraries. We met developers in their repos with npm packages. Now we need to meet them inside their AI tools. Skills and rules are how you do that without a big infrastructure investment.

What are you building?

I’m still early in this. I’ve got a few skills running that have already changed how I work, but I know there’s a lot more to figure out. Have you built Claude skills or Cursor rules for your design system? Found an approach that works well?

I’d love to hear what people are doing. If you’ve got something working, tell me about it.

I read that and immediately thought: what happens if I try this?

What Cassidy did

Her experiment was simple. Ask LLMs questions that should surface her work, see if they mention her, and if they don’t, ask them what she could do about it. The AI came back with practical stuff: create an llms.txt file, add structured data, keep messaging consistent across platforms. She implemented the suggestions over a few weeks and started showing up in LLM responses.

What stuck with me was less the technical recommendations and more the realization that people are using AI to discover people and tools now. Not just Google. If an LLM doesn’t know you exist, a lot of people won’t find you either.

So I tried it

I asked a few LLMs about me. About my work. Design systems people to follow, UX developers worth knowing, folks writing about the intersection of design and engineering. The results were humbling. Mostly blank. A couple got my name right but didn’t have much to say beyond that.

So I did what Cassidy did. I asked the AI: what should I do to show up more? What would make you recommend me?

The answer that kept coming back, across every model I tried: write more. Publish more. Put your thinking out in the open. The models learn from what’s publicly available, and if you’re not publishing, you’re invisible to them.

There’s something kind of absurd about an AI telling you to create more content so it can learn who you are. Like a robot tapping you on the shoulder and saying, “hey, I’d recommend you to people, but I don’t have enough to go on. Help me out here.”

So here we go

I’m taking the advice. Not entirely because an AI told me to. I’ve been meaning to write more for a while now. I’ve got opinions about design systems and AI tooling and the weird space between design and engineering that I’ve lived in for years. I just haven’t been putting them out there consistently.

So here I am, writing. The robots demanded it, and honestly, they’re not wrong.

Let’s see if they notice.