There's a stark difference between transformation and renovation. Most product teams believe they're doing the first. In reality, most of them are doing the second.

A smarter search bar, a copilot in the sidebar, autocomplete inside the same fixed workflow everyone's been clicking through for years: that's renovation. It ships fast, it demos well, and the product underneath is exactly the same.

Transformation, on the other hand, is architectural. 

It's moving intelligence from the feature layer to the foundation. When this happens, the interface stops being the thing you design and becomes something the system generates. Layouts, workflows, information hierarchy: all adapting based on who's using the product, what they're trying to accomplish, and what the system has learned about how they work.

That's generative software.

We explored this shift in "Design After the Page" (what designers should build when AI generates interfaces) and "What Is an App Now?" (how apps shift from fixed feature sets to containers for domain intelligence).

The logical question that followed was, if you're building generative software from the ground up—if you're truly trying to transform instead of renovate—what principles should guide the work?

Four stand out.

For most of software's history, the product was the interface. The thing you see is the thing you use.

In a generative world, the intelligence underneath creates the value. The interface is how it shows up.

Erase every screen in your product tomorrow. Keep the underlying intelligence. Could it still serve your users through a completely different surface? If the answer is no, your intelligence layer is too thin. You're still designing interfaces when you should be designing intelligence.

The next roadmap conversation should start with a different question: what does the system need to know about this user to serve them without a screen?

Generative interfaces can reshape themselves for every user at every moment. The same capability that makes this powerful makes it dangerous.

Fluidity without familiarity is disorienting. In complex professional software, disorientation kills trust. People revert to workarounds, adoption collapses, and you're done before it even ships.

Think of it like a city. Streets can change, buildings go up, new routes emerge. But move City Hall and rename the main roads every week, and people stop trusting the place. They move to another city to call it home.

Familiarity is infrastructure.

Be consistent in your structure. Allow your software to be fluid with its content. The same navigation anchors, the same spatial logic, the same core patterns. What populates them changes based on who you are and what you need right now.

What in your product could change for every user tomorrow, and what absolutely cannot?

Generative software assembles a unique experience for every user. Without the right foundation, that falls apart fast.

Components without metadata become noise. Design systems that only humans can read become bottlenecks. The intelligence layer tries to build something and has no ingredients to work with. Just pixels it can rearrange.

Think of it like a kitchen: The best chef in the world can't cook without labeled ingredients, clean prep, and a system for what goes with what. Hand them a pile of unlabeled boxes and they'll make something. It just won't be good.

Your components need to be consumable by models, not just by designers in Figma. What they're for, when they're appropriate, what they combine with, what they should never do.

If an AI agent opened your design system right now, could it build something on-brand without a human in the room?

Software has spent decades helping people complete steps: click here, fill this out, follow the workflow.

That was great when the product defined what was possible. But in a generative world, the user defines what's possible. The product needs to keep up.

When systems stay rigid, they suppress creativity rather than amplify it. People stop imagining what's possible because the tools keep telling them what's available. The menu becomes the ceiling.

People are already pushing past it. They're connecting AI tools to professional software and building workflows the product teams never imagined, extending products beyond their shipped capabilities. When software becomes a canvas rather than a corridor, the people using it start building things the people who made it never anticipated.

Design for intent. The goal is expanding what users believe they can do.

Here's how to tell. Ask yourself:

1. How much of your current roadmap is enriching what the system knows versus decorating what the user sees?

2. Can your design system be consumed by a model today, or does it only make sense to humans arranging screens in Figma?

3. What would your product look like if every user saw something assembled specifically for them? How far is that from what you're shipping right now?

The answers will tell you whether you're building for the world that's coming, or optimizing for the one that's on its way out.