In Madrid we have a type of neighborhood called PAU. These are the big planned districts built on the edge of the city in the 2000s: Sanchinarro, Las Tablas, Valdebebas… pick your favorite “bedroom community”. On the map, the urban planner was a genius: six-lane avenues, perfect grids, every square meter calculated. A triumph of geometry. But at street level, especially in the first years, it was a different story: huge distances, wide avenues where the wind froze you, and very little life on the street.
Today many of these neighborhoods are full of life, but thanks to the people who live there and have been transforming them, not to the plan. They followed every technical rule, yes. But they forgot one small detail: designing for people to actually live there.
As an architect, I saw this mistake many times. Now, as a product designer, I’m starting to see it in software.
Recently I joined Raúl Marín (opens in a new tab)’s community at Shift+R (opens in a new tab), and there he showed us this great talk (opens in a new tab) by Katie Dill (Head of Design at Stripe). She compares today’s AI boom with the building boom after World War II: people were in such a hurry to build that they put up cheap, identical buildings with no soul. Today we are building the PAUs of software, screens full of what Katie calls “Zombie UI”. Things that work, with their rounded corners and soft shadows, but are as dead as a floppy disk.
Ryo Lu (from the Cursor team) explains this very well in his recent article Convergence to the mean (opens in a new tab): when everyone looks at everyone else to decide what to make, we stop making anything of our own. We copy what works and call it “best practices”. AI removes all the friction from this loop. But, as Ryo says, having access to every perspective isn’t the same as having one. If we ask AI to choose for us without bringing any intention of our own, we get something plausible and easy to approve. We ship it, measure it, copy it, and start again. The result is what he calls “a tidal wave of mid.”
An example from my daily work
At PIX4Dcloud, users upload hundreds of drone photos to create maps and 3D models. Our team is always looking for ways to improve this experience, and many of our ideas come from listening to our users: where they get stuck, what makes them lose time, what they wish the product could do for them. And our leadership clearly supports innovation to solve these real problems for our customers, also taking into account the possibilities that AI can offer us from now on. Why not?
That’s why I often ask myself: what makes an agent useful instead of a zombie? Imagine an agent that helps users process their flights.
The zombie version says: “Your images were uploaded successfully! How else can I help you?” Fast, correct and completely useless. This is what Katie calls “the microwave burrito dilemma”: we love going from hungry to having something hot on the plate in 90 seconds so much that we don’t care if it tastes like cardboard.
The version with someone behind the wheel notices that the photos in one area of the flight don’t have enough overlap, and warns you before you waste time and processing credits on a model full of holes.
The difference is not on the screen. It’s in everything behind it. That’s why we designers need to stop being “screen assemblers” and start acting like architects. The infrastructure has to change.
1. From the punishing prompt to context
A static system prompt (“you are a helpful assistant, don’t hallucinate, be polite”) is like the building rules of a PAU: strict rules so nothing bad happens, but they don’t let anything good happen either. (And spoiler: writing “don’t hallucinate” in a prompt doesn’t help much.)
The problem isn’t the prompt. The problem is that the agent doesn’t know what situation the user is in. Are they in a hurry? Did they just get an error? Is it their first time using the product? This information reaches the agent through context: memory, the state of the app, the result of what it just did. People are starting to call this context engineering, and this is where you bring your intention. You decide what the agent should pay attention to at each moment.
2. Tools and plumbing
Giving an agent autonomy without tools is like building a skyscraper without pipes. If it can’t call an API, read data from the backend or start a process, all it will do is chat and apologize like a broken robot.
Developers install the pipes. But deciding where they go is design work:
- Which actions the agent can do on its own.
- When it needs to ask the user for confirmation.
- What can be undone and what can’t.
- How it shows what it did.
In a building nobody sees the pipes, but everybody notices when they fail.
3. AI-ready design systems (or why Gutenberg was a genius)
A generic design system is like a catalogue of prefab parts: you can only build the same block again and again.
Katie tells an amazing story: when Gutenberg invented the printing press, he didn’t make just 52 letters. He made around 290 different characters, with ligatures and different widths, so the machine could justify the text and the page would look handwritten by a monk. As Katie says, yesterday’s design systems scaled consistency; today’s need to scale intention.
We need AI-ready design systems: components the machine can understand (JSON schemas, semantic tokens) and usage guidelines it can read, not only nice documentation for humans. Because generative UI is not about the agent inventing new components, but about combining the existing ones well. If your parts are generic, the agent will build cloned PAUs. If they have character, it will build something that really feels like your brand.
4. Guardrails: bouncer and building inspector
Before, we filtered bad ideas in product meetings. Today, AI gives you 20 ideas in one afternoon, so a big part of the filter comes after.
That’s why guardrails need to work at two moments. Before, like a nightclub bouncer: the design system only lets the agent use approved components. And after, like a building inspector: automatic validators that check if what the agent built follows the rules before the user sees it.
Fewer factories, more workshops
Ryo Lu says it well: if we can make almost anything, deciding what deserves to exist becomes more important, not less. Speed gives us more chances to use our judgment, but it doesn’t remove the responsibility.
Our users won’t applaud because an agent builds them a dashboard in two seconds. They will stay for the small details (a smart interaction, solving a problem before it happens, the right tone of voice) that show someone cared about them.
Ryo doesn’t want a world where we all become more efficient distributors of the same ideas. I don’t want to fill the internet with digital PAUs either. I prefer to use these tools to get my hands dirty, bring my own point of view, and make sure that in software, even when a machine draws it, you can feel there’s a human behind the wheel.