Someone recently told me that ProductShape is essentially the same idea as Andrej Karpathy’s LLM Wiki. Is it? No.

They share a technical intuition, but they solve different problems.

Karpathy published LLM Wiki on April 4, 2026. His proposal consists of:

• Ingesting documents, articles, and other sources.
• Using the LLM to generate and maintain a linked Markdown wiki.
• Querying, extending, and reviewing that wiki.
• Treating the original sources as canonical truth; the wiki is a derived synthesis, maintained primarily by the LLM.

Product Definition as Code (concept born on July 25, 2026) and its first implementation in ProductShape consists of:

• Explicitly defining what a product is.
• Modeling it through typed artifacts: actors, journeys, use cases, rules, requirements, constraints, changes, and slices.
• Making relationships carry normative, validatable semantics.
• Managing changes as overlays before promoting them to the current model.
• Projecting verifiable subsets toward backlog, handoffs, and SDD workflows.
• Keeping the model’s Markdown as canonical truth governed by humans, not as automatic synthesis of sources.

The real overlap is this:

persistent knowledge + Markdown + Git + relationships + agents working over files

That is a common architectural family, not identity of purpose or methodology.

The main differences:

	Karpathy LLM Wiki	ProductShape
	Compiles sources into knowledge	Intentionally models a product
	Emergent, adaptable ontology	Explicit, typed ontology
	Wiki generated by the LLM	Model approved by humans
	Relationships for navigation and synthesis	Relationships as methodology and traceability
	Ingest, query, lint	Define, recover, change, slice, handoff, promote
	Knowledge management	Governance of product definition and evolution
	No delivery contract	Formal connection to backlog, SDD, and verification

The correct formulation would be:

ProductShape applies some principles of structured, agent-friendly knowledge that also appear in LLM Wiki, but turns them into a normative, validatable model oriented to the product definition and delivery cycle.

Saying they are “the same” is like saying an architecture-as-code repository is the same as a technical wiki because both use Markdown, Git, and links.

And to be clear, this is not a criticism of LLM Wiki. A derived, LLM-maintained synthesis of sources is genuinely useful, and the two can coexist in one organization: the wiki compiles what you have learned; the product model states what you mean. Only one of them can be promoted, validated in CI, and handed to a delivery workflow as a contract.

If you want the longer version of that contract: Product Definition as Code, the PDaC specification (v0.1, request for comments), and the manifesto you can sign.