AI architecture · Reuse in the agent era

Generative Design Patterns: A Sentence That Generates a Family of Systems

When implementation is abundant, the scarce, transmissible asset is not the reference repository. It is a promptable kernel — short enough for a human to carry, precise enough for an AI to regenerate — that reliably produces a family of locally fitted systems. That is the AI-era successor to the Gang of Four pattern.

Scott Farrell · LeverageAI · Full design essay companion to the Generative Design Patterns ebook

Watch a single public note travel. Within days it is a YouTube tutorial, an Obsidian vault layout, a Claude Code rulebook, a personal “second brain,” a research corpus, a team memory experiment. Implementations disagree about folders, frontmatter, lint passes, and whether the human should stay in the ingest loop. What they share is not a repository. They share a sentence-scale idea about how AI and knowledge should relate.

That cascade is the phenomenon this article is about. Not the celebrity of the messenger. Not the invention of wikis. The fact that one compressed formulation is now enough for thousands of people to generate their own software.

An AI-era design pattern is a sentence that generates a family of systems.

What Karpathy actually supplied

Andrej Karpathy’s public “LLM Wiki” note is an idea file: copy-paste it into a coding agent and collaborate on the specifics.¹ It contrasts everyday RAG — re-discovering fragments on every question — with a different architecture: the model incrementally builds and maintains a persistent, interlinked markdown wiki between the human and the raw sources. Knowledge is compiled once and kept current, not re-derived on every query.¹

The note is deliberately abstract. Three layers: immutable raw sources; an LLM-owned wiki; a schema document (CLAUDE.md / AGENTS.md) that makes the agent a disciplined maintainer. Three operations: ingest, query, lint. Explicitly: the document’s job is to communicate the pattern; the LLM figures out the rest.¹

Agent-maintained memory, knowledge graphs, personal wikis, and compounding notes all predate that formulation. What the public cascade shows is something different: popularisation root, not inventor. The Cascade Ledger discipline exists precisely so we can talk about propagation without mythologising private intent.² Karpathy’s load-bearing contribution, for our purposes, is observable compression:

Turn your big messy world into a wiki your AI maintains.

Small enough to repeat to a coding agent. Rich enough to generate a family: second brain, corporate memory, coding-agent wiki, news radar, customer intelligence, research corpus. Same invariant — different local worlds.

The new pattern bar

Gang of Four design patterns gave software engineers a shared vocabulary for organising object-oriented code — named solutions to recurring structural problems, catalogued for reuse by humans reading class diagrams and sample code.³

That catalogue still matters. It is not what is scarce now.

When a competent coding agent can expand a clear intent into a working system, the scarce unit of reuse is no longer “the reference implementation you fork.” It is the promptable invariant you show the agent so it builds the version that fits your work. Industry voices already treat code as ephemeral and design intent as the durable asset;⁴ generative patterns push that further into a mintable, transmissible form at sentence scale.

The bar for a powerful pattern is now:

Short enough for a human to carry; precise enough for an AI to regenerate.

Too long and it stops travelling — it becomes a local implementation document. Too vague and it fails the family test: agents produce incoherent demos that do not share an invariant. The Karpathy note sits in the generative zone: abstract on purpose, operational enough (layers, ops, who writes what) that agents converge on related systems rather than random note apps.

This is the public cousin of private kernel work. Worldview compression and nuke-and-regenerate are about your recipe compounding for you.⁵ North Star prompting is about orienting a model in a session without over-specifying method.⁶ Generative Design Patterns are about the seed others will carry — the shared asset of an ecosystem shifting from reference implementations to promptable seeds.

Why the omissions are the feature

Dissect the kernel. What does the public note specify?

• A problem contrast (RAG re-derives; wiki compounds).
• A three-layer split (raw / wiki / schema).
• A maintainer role for the LLM and a curator role for the human.
• Three verbs: ingest, query, lint.
• Examples of contexts (personal, research, business) without mandating one product.

What does it omit?

• Exact directory trees as law (only sketches).
• A fixed tech stack (any agent + any markdown browser).
• Domain schemas for your company or your hobbies.
• UI chrome, auth, multi-tenant policy, eval harnesses.
• A “complete” application.

Those omissions are what make the pattern generative. Every filled-in detail would be a local opinion that travels badly. The schema file is the hinge: you and the agent co-evolve conventions for your domain. The pattern says what kind of system should exist; the local world supplies the missing specification.

Karpathy kernel (carried)
        │
        ▼
   Agent expands ──► your folders, entities, CLAUDE.md, tools
        │
        ▼
   Contact with reality ──► “I don’t use it that way”
        │
        ▼
   Cheap modification ──► fitted system (one of many in the family)

That is tight intent, loose method applied to whole architectures — not only to a chat prompt.⁶

The democratisation mechanic

Wes Roth publicly documented building a “second brain” as an AI-maintained wiki with Claude Code — ingestion, markdown maintenance, Obsidian as the browsing surface.⁷ Companion guides spell out the same pattern family in folder form: Raw, Inbox, Wiki, CLAUDE.md; ingest that ripples across entity and concept pages; query that reads the index first and answers with citations.⁸

What the public material shows he did is enough for the argument: a non-programmer creator took a compressed kernel, gave a coding agent access to a real workspace, and produced a custom system fitted to personal use — then showed others how.

What he understood mid-build is not something we can read from a video title. My outside-in reading from watching these builds is that creators often start without a full computer-science model of wikis, graphs, or agent memory — and they do not need one. Prefer the general form: a non-programmer creator needs (1) a reasonable North Star, (2) boundaries and access to the real environment, (3) judgment about what is annoying in daily use. The agent supplies implementation knowledge. Reality supplies the missing specification. “I don’t use it that way” is design evidence, not a bug report.

You do not need a complete specification. You need a sufficiently clear North Star, rapid contact with reality, and the discipline to move each lesson out of the patched code and back into the design.

The inverted reuse hierarchy

When regeneration is cheap, the value order of reusable assets flips. What used to be the prize — a complete application — becomes the most locally opinionated and easiest layer to throw away.

Most valuable (carry & share)
  1. North Star / design kernel
  2. Domain distinctions (what must not be conflated)
  3. Thin reference architecture
  4. Schemas & eval cases
  5. Bounded libraries
  6. Complete application code
Least valuable (regenerate locally)

People increasingly do not download the reference implementation. They show the idea to their agent and say: build the version of this that fits my work. That is Economies of Specificity at ecosystem scale — bespoke systems without industrial standardisation of the application layer itself.⁹

The healthy ecosystem response is not “one true app.” It is standardise below the application: protocols, components, eval cases, interchange formats. Let the application layer go Cambrian — mass-custom software for missions that never justified a product manager.

Adjacent advice — whether to fork an existing repo or regenerate from the kernel — is a real decision, but it is a different article (the open-source shortcut trap). Here the doctrine is simpler: know where value lives. The seed travels. The codebase does not have to.

The pattern card

A Generative Design Pattern is reusable when you can write this card and another practitioner can hand it to an agent without you in the room.

Why agent-maintained wikis beat chat-native RAG for agent workloads is developed elsewhere.¹⁰¹¹ The card is not that product argument. It is the transmissible seed that lets the family keep branching.

The full product design of the signal-case queue is a sibling piece.¹² Here it appears as a second minted pattern: same card format, different problem shape — proof that the format is not a one-off label for Karpathy’s tweet.

Counterexample: slogans that do not generate families

Not every popular one-liner is a generative pattern.

“Build a second brain.” As motivation, fine. As a kernel, it fails. It names a desire, not an expandable invariant. Who maintains what? What compounds? What is immutable? Agents given only the slogan produce random note apps, GTD clones, and chat wrappers that do not share a family structure.

The Karpathy compression succeeds where the slogan fails because it adds the maintainer split, the compounding wiki, and the schema-bound operations — still short enough to carry.

“Make it agentic” / “just use multi-agent” has the same disease: a fashion label without a problem shape or a failure grammar. You get a spray of architectures that cannot be compared or transmitted as one pattern.

The test: if two competent agents, given only your sentence, produce systems that share a recognisable invariant and differ mainly in local fit, you have a generative pattern. If they produce unrelated products that only share a buzzword, you have a slogan.

How to mint one

1. Name the recurring problem shape — not your favourite tech, the pain that returns across contexts.
2. Write the North Star in one or two sentences — what kind of system should exist; who does the grunt work; what compounds.
3. List at least three generated variants — if you cannot, you may have an app idea, not a pattern.
4. List failure shapes — how implementations go wrong while still “following” the words.
5. Run the carry test — can a colleague paste the card into an agent and get a family member without a call with you?
6. Run the omit test — delete every detail that is local opinion; if the card dies, it was never compressed enough to travel.

The ecosystem shift is already visible: one influential formulation yields many interpretations and a thicket of locally generated implementations. Measure that propagation with a cascade ledger, not with vibes.² Build the applications as bespoke. Standardise the layer underneath. And when you have an idea that matters, ask the only reuse question that still scales:

Is this a sentence someone else can carry — and an AI can expand into a family?