Twenty-Six Years Later, the Inmates Still Run the Asylum — They Just Got Better at Hiding It

Through a friend, I ended up with a personally signed copy of The Inmates Are Running the Asylum — the book that, more than any other, shaped how I think about software. Alan Cooper is the father of Visual Basic, among other things, and genuinely one of my idols.

Cooper had written on the title page:

I hope you enjoy this 26-year-old book. Its main message is that good user experience is not a design problem but is rather a power struggle.

I first read this book while taking Pragmatic Marketing courses, years into my career in product management. It’s the book that taught me the difference between building what developers find interesting and what actually solves real market problems.

Not long after, I put that lesson to a real test. At a software company I worked for, the organisation had a problem nobody wanted to name directly: it didn’t understand why user experience mattered, or why it should come first. Development there was resolutely inside-out. New features got invented by gathering the cleverest developers in a room and waiting until they produced something brilliant — not by doing market research or understanding the actual problems customers had. Design came last, as a coat of paint. The backend got built, and then somebody was assigned to make it look pretty.

As product managers, we wanted to change that, and arguing it in meetings wasn’t working. So we bought fifteen copies of Cooper’s book, handed one to every manager and lead developer in the building, and made it mandatory reading.

What came out of it was a new pipeline. Before, it had all been dev decisions, in order: engineers decided what to build, how it should work, and what it should look like. After, it became three distinct jobs. Product management identified and quantified the real user and market problems, and decided which ones were worth solving first. User experience worked out how those problems actually got solved for the people who had them. Only then did development figure out how to make the technology do that. The company went on to become first in its class on user experience — not because anyone got more talented overnight, but because nobody was allowed to quietly skip straight to the third stage anymore.

So when a signed copy arrived with Cooper’s note calling it a “power struggle,” the question it provoked wasn’t academic. I’d already spent real effort making sure that struggle came out a particular way, once. With Claude, Codex, Claude Design, Lovable, v0 and vibe coding now in the picture, I wanted to know: has the problem I fought to fix finally solved itself?

The apparent answer

One of Cooper’s central observations was that the people building software are fundamentally different from the people using it. He has a name for the test that reveals it: the Jetway Test. Everyone boarding a flight passes a point where they could, in theory, turn left into the cockpit or right into the cabin. Turning left means mastering every instrument and taking on responsibility for getting the aircraft down yourself. Turning right means giving up that authority entirely, in exchange for a seat, a drink, and the certainty of arriving without understanding anything more complicated than the reading light.

I am, unmistakably, a turn-left person. So are most developers. Cooper’s point was never that this makes us bad at our jobs. It’s that we keep building cockpits for people who only ever wanted the cabin. Developers tolerate complexity, abstraction and configuration at a level ordinary users never will, and when we design according to our own mental models — which inside-out development practically guarantees — the people who have to use the result suffer for it.

Generative AI looks like it dissolves that problem at the root. Increasingly, the person with the problem can build the software themselves. No developer’s mental model gets in the way, because there’s no separate developer. So what happens to a book about the power struggle between developers and users, once everyone can become both?

The apparent answer is that the problem disappears.

I don’t think it does.

Pretty is not usable. Usable is not useful.

Old developer-built software used to look developer-built — grey forms, raw database terminology, a dozen checkboxes with no explanation. That ugliness was accidentally honest: it told you, at a glance, that nobody had thought hard about the person using it.

Claude Design can take the exact same conceptual model and give it excellent typography, beautiful cards, rounded corners, tasteful animation — genuinely attractive, in minutes, fluent in every visual convention 2026 software has.

The 2026 version of the asylum has rounded corners, excellent typography and tasteful animations.

But visual design isn’t interaction design. And even excellent interaction design doesn’t guarantee you’re solving the right problem.

This is the same move I watched happen at that software company, just compressed. Back then, the backend got built first and a designer got handed the job of making it presentable afterwards — a process that took a sprint or two, visible enough that someone occasionally stopped and asked whether the underlying model was right in the first place. Today the “make it presentable” step takes about ninety seconds, and it’s good enough that almost nobody stops to ask that question at all.

Say an accountant tells you: “I need a screen where I upload two Excel files, see them side by side, highlight the differences, and press a button to reconcile them.” Claude could build an excellent version of exactly that. But maybe the best solution has no reconciliation screen at all — maybe the system reconciles transactions continuously in the background and only surfaces the three cases that are actually ambiguous.

The accountant understands her problem better than any developer does. That’s never been in question. But understanding a problem intimately doesn’t mean you can imagine its best possible solution. People describe solutions in terms of the workflows and software they already know, because that’s the only vocabulary they have to describe it in.

The bottleneck has moved

Generative AI is extremely good at implementing the solution you ask for. That’s not the same as understanding which problem is worth solving, or how a workflow should fundamentally change. And that gap matters more now than it used to, for an uncomfortable reason: AI has made solution construction dramatically cheaper. It hasn’t made problem understanding correspondingly cheaper. If anything, cheap implementation makes the old problem worse.

Twenty years ago, building the wrong piece of software was expensive. Requirements, design, development, testing and deployment all created friction, and some of that friction forced an organisation to stop and ask why it was building something at all. Today: “Claude, build me an invoice reconciliation dashboard” — and shortly afterward, there’s a working application.

That’s genuinely incredible. It’s also how you build the wrong thing faster than at any point in the history of software. The bottleneck has moved from can we build this? to should we build this, and what should it actually do? — which makes product thinking and a real understanding of users more important, not less.

It’s worth being precise about what actually got cheap. AI has collapsed the third stage of the pipeline I helped install years ago — the dev stage — down to almost nothing. It has done nothing at all to the first two. Identifying which problem is genuinely worth solving is exactly as hard as it was in 1999. Working out how that problem should be solved for the people who have it is exactly as hard. The only thing that’s changed is how tempting it now is to skip straight to a working prototype and treat the first two stages as settled by implication.

A power struggle, redistributed

Cooper’s handwritten line keeps coming back to me: good user experience is a power struggle, not a design problem. AI doesn’t end that struggle. It changes who holds power in it.

In 1999, programmers held enormous power because they controlled implementation — they were the only ones who could make anything real. Today that power is being redistributed. Designers can implement. Product managers can prototype. Executives can build their own tools. Domain experts and ordinary users can vibe-code an application for exactly the problem in front of them.

But distributing implementation power is not the same thing as distributing product insight. Those are two different kinds of power, and only one of them has gotten dramatically cheaper.

There’s a sharper version of this worth sitting with. Imagine vibe-coding something purely for yourself — developer and user are finally the same person, so Cooper’s objection should simply disappear. For a while, it does. But after thirty hours inside your own data model, your own terminology, your own configuration choices and your own quirks, things that would need explaining to anyone else now feel completely obvious to you. Then you hand it to somebody.

You’ve become an expert in your own implementation. You’re an inmate again. You just built the asylum yourself this time.

Inmates amplified

Ask a generative model for “an admin interface for managing users, roles and permissions” and you’ll get tables, filters, dialogs, nicely designed role badges — genuinely good work. But the actual problem might be something much smaller: Anna should be able to approve invoices while Peter is on holiday. Users, then Roles, then Permissions, then Resources, then CRUD screens (create, read, update, delete) is often just the implementation model leaking straight through the interface. Making that model beautiful doesn’t make it correct.

Generative models have also learned the conventions of existing software extremely well. Ask for a CRM, and you get something that looks like a CRM. Ask for project management software, and you get cards, statuses, assignees, dashboards. Impressive — and it quietly reinforces the assumption that software has to look like software does. Some of the best product thinking I’ve seen starts from refusing that assumption and asking the harder question: why does this need to look like software in the first place?

None of that is the model being lazy. It’s the model being an inmate. Cooper’s developers were trapped inside their own technical mental models, reaching for whatever felt obvious to them rather than what the market actually needed. An agent is trapped the same way, just at a different scale — it has absorbed the shape of every CRM, every admin panel and every dashboard anyone has ever shipped, and it reaches for that shape by default, the same way a roomful of clever developers reaches for whatever excites them. It didn’t build the asylum. It inherited every asylum ever built, all at once, and by default it has no reason to step outside that and ask whether this particular problem needs building at all.

What I’d actually take from this

Don’t expect the agent to ask the question for you. It can execute brilliantly inside the conventions it was trained on, but asking whether this problem needs software shaped like that at all isn’t something it’s positioned to do. That’s still a job for someone who has done the work of actually understanding the people who have the problem.

Treat a fast build as a hypothesis, not an answer. The speed that makes AI valuable is the same speed that lets you skip the step where someone asks whether you’re solving the right problem. Put that step back in deliberately, because nothing else will force it anymore.

Watch for amplified inmates. A beautiful CRUD screen is still a CRUD screen. Before admiring the typography, ask what conceptual model is actually driving the interface, and whether a user would ever describe their problem that way.

Fifteen copies of a book didn’t fix my old company’s UX problem by themselves. What fixed it was splitting one job into three, so that nobody could quietly fold “identify the problem” and “design how it’s solved” into “build the thing” ever again. That was never really about headcount — it never strictly required three separate job titles. It required the three questions to stay genuinely distinct, each one taken seriously by whoever or whatever is doing it. The agents building for us now are extremely good at the third one. By default, they have little to offer on the first two. A problem isn’t solved until it’s solved for the people who have it. AI hasn’t removed the need for that discipline. It’s just made it much easier to skip straight past it.

If you haven’t read it: The Inmates Are Running the Asylum holds up better than most 26-year-old tech books have any right to.