Design System and Tuscan Pantry: How to Build Well When Building Is Easy

Last year, building software was hard. You needed engineers, designers, weeks of work, and a budget. This year, you can describe what you want to an AI and have a working app before lunch. Next year, AI agents will build entire products — designing screens, writing code, connecting services — while you sleep.

This is genuinely exciting. It also creates a problem that most people haven’t thought about yet.

When building was hard, quality was a side effect of effort. You spent so long on every screen that consistency happened naturally — the same person agonized over every detail. Now that building is fast — and about to become fully autonomous — quality has to be intentional. And the tool for making it intentional has a name.

It’s called a design system.

But first, let’s go to Tuscany

Walk into any kitchen in rural Tuscany, and you’ll find roughly the same things: extra virgin olive oil, pecorino cheese, dried pasta, San Marzano tomatoes, cannellini beans, rosemary, garlic, and good bread.

That’s the pantry. It’s modest. Maybe fifteen ingredients.

And yet, from this pantry, Tuscan cooks produce hundreds of dishes — ribollita, pici cacio e pepe, pappa al pomodoro, bistecca alla fiorentina. Each dish is distinct. Each cook has their own hand. But every plate is unmistakably Tuscan.

How? Not because the recipes are identical. Because the ingredients are shared. The olive oil shows up everywhere — in the soup, on the bread, finishing the steak. The pecorino recurs. The rosemary recurs. Each dish is different, but there’s a thread running through all of them, a family resemblance that comes from the pantry itself.

Now here’s the thing that makes Tuscany special: the constraint isn’t a limitation. It’s the source of the identity. Tuscan cuisine doesn’t taste coherent despite having a small pantry. It tastes coherent because of it.

A design system is a pantry for building software

Instead of olive oil and pecorino, your ingredients are things like colors, fonts, spacing values, and corner radiuses. Designers call these tokens — the raw ingredients that show up everywhere.

Instead of recipes like ribollita and cacio e pepe, you have components — buttons, input fields, navigation bars, cards, dropdown menus. Each component is assembled from tokens, just like each Tuscan dish is assembled from the pantry. Your primary button uses your brand blue (a color token), your standard font (a typography token), and your default padding (a spacing token). It looks the same everywhere it appears.

And instead of the Tuscan meal structure — antipasto, primo, secondo, dolce — you have patterns: how components come together on a page. A login screen. A settings panel. A checkout flow. These are your meal sequences, your ways of composing individual dishes into a coherent experience.

Tokens. Components. Patterns. That’s it. That’s a design system.

Why it matters: the collaboration problem

The moment a second person touches your product — you need a shared language: design system. This has always been true. But the collaboration requirement has become more critical.

Your most prolific collaborator now is an AI. Ask it to build you a screen and it will produce something beautiful. Ask it to build the next screen and it will produce something equally beautiful and completely inconsistent with the first. Different blues. Different spacing. Different button styles. AI doesn’t remember what it built yesterday. Unless you explicitly hand it a design system, every screen is a blank slate.

And it’s moving beyond single screens. Agentic design — where AI doesn’t just help you build but builds autonomously, generating entire flows, whole features, sometimes full applications — is already here. The speed is extraordinary. The coherence, without guardrails, is zero.

A design system is the guardrail. It turns “make me a settings page” from a creative gamble into a predictable composition. The AI pulls from your tokens, your components, your patterns. What comes out looks like your product, not a random beautiful thing.

The old collaboration problem was getting humans to agree. The new one is giving machines a constraint to work within. Same solution: a shared pantry.

Why it matters: the trust problem

You open an app. You tap a button and it’s rounded with a shadow. You navigate to the next screen and the buttons are flat and square. The font shifts. The spacing feels off. Nothing is broken, but something feels wrong. You don’t think “inconsistent design tokens.” You just trust the product a little less.

Consistency is how software earns trust the same way a restaurant does: not through any single dish, but through the feeling that someone is in control of the experience. When every plate has the same care and intention — you relax. You trust the chef. You come back.

A design system makes consistency automatic. Every new screen inherits the identity. The user moves from home to settings to checkout and it all feels like one place.

Why it matters: the speed problem

Without a design system, every new screen starts from a blank canvas. What shade of blue? How much padding? What font size? Small decisions, but they compound — a hundred per screen, fifty screens in your app, five thousand decisions made from scratch.

With a design system, those decisions are made once. You’re not deciding anymore — you’re composing. Cooking from a stocked pantry, not going to the market for every meal. The fiftieth screen takes a fraction of the time the first one did.

Why it matters: the brand identity problem

For most software products, especially early-stage ones, the interface is the brand. There’s no billboard. No Super Bowl ad. Every screen is a brand impression.

When building was slow, identity emerged naturally — the founder reviewed every screen, the one designer sweated every pixel. Identity was a byproduct of bottleneck. That bottleneck is gone now. Anyone can build, and build fast. Which means identity has to be designed.

The Tuscany lesson

Here’s what Tuscan grandmothers know that most app builders don’t:

Freedom isn’t having every ingredient in the world. Freedom is knowing your fifteen ingredients so well that you can make anything from them. The constraint is what makes you creative. The pantry is what makes you you.

A design system is that commitment. It says: these are our colors, our fonts, our spacing, our components. Not because we can’t use others, but because these are ours. And everything we build from them will be unmistakably ours.

Building is no longer the hard part. Coherence is. A design system is how you solve for coherence.

STEM Corner

Basis in Mathematics & Design System

There’s a precise mathematical concept for what a pantry and a design system both are. It’s called a basis.

In linear algebra, a basis is the smallest set of vectors that can reach every point in a space. On a flat surface, you need exactly two directions — say, east and north — to describe any location. Those two vectors are your basis. You don’t need “northeast” because it’s just a combination of east and north. The basis is minimal (nothing redundant) and spanning (nothing is left out).

A simpler way to think about it: GPS uses only two numbers — latitude and longitude — to pinpoint any location on Earth. Two values, infinite locations. That’s a basis.

A design system is a basis for your product’s visual space. The tokens are your basis vectors. Every screen in your app is a linear combination of those tokens. A well-designed system, like a good basis, has no redundancy (you don’t need two shades of primary blue) and full coverage (you can build any screen your product requires). The mathematical term for this property is elegance. Designers just call it clean.