The design organisation as a codebase?

Main point: Putting all our design work in one shared repository gave the design team what engineering has always had: a source of truth to read. With AI on top, it makes the whole team's work more coherent.

What a design monorepo is

One repository holding every designer's apps, components and patterns, with full history. It works as shared memory. Our shared component library grew out of it: designers propose patterns from their apps, and the good ones get promoted. (Context: [Unplanned Studio: An agentic design engineering platform for a world where everyone can code.])

What AI can do with it

An AI on one file has local context. An AI on the whole repo has organisational context: what everyone has built, what was tried and abandoned, and what's being reinvented right now. That's more coherent group work, not just faster individual work. (See [A first-principles approach to design in the age of AI] and [What happens when an AI can see every designer's PR?])

Problems it solves

• Fragmentation: the same table or filter bar solved five ways, now visible side by side
• Forgotten precedent: past decisions become findable
• Reinventing shared components: flagged when they're being built, not at review (Related: [Why "throw-away code" is the wrong frame for agentic design prototyping])
• Drift between apps: caught before it compounds

Knowing what your team is doing

With GitHub Issues and Projects next to the code ([GitHub Issues for Design Teams]), anyone can get a briefing on what's merged, in review, planned or blocked ([The morning briefing for a shared codebase]) instead of "ask Sarah".

The limit

The repo captures decisions, not always the reasoning, or whether a call was right. Judgment stays with people. The codebase just makes sure it's informed.