A practical LLM wiki pattern for vibe-coded apps: a codebase-integrated memory layer that helps AI builders reduce context drift, keep docs aligned with code, and generate compressed knowledge views for builders, admins, support, reviewers, and QA.

kiosk-llm-wiki.md

KIOSK LLM Wiki

A practical LLM wiki pattern for vibe-coded apps, AI-built products, and high-trust software systems.

Inspired by Andrej Karpathy's original LLM Wiki.

This is a simpler, gist-native version of the KIOSK idea. It is designed to be copy-pasted into an AI coding agent like Lovable, Cursor, Claude Code, Codex, or similar. The goal is to communicate the concept clearly enough that the agent can build a primitive but useful version directly in your repo.

The original LLM wiki idea is about giving LLMs a persistent knowledge layer instead of making them rediscover everything through RAG every time. KIOSK keeps that idea, but adapts it for codebases, documentation-heavy products, AI-assisted development, and high-compliance software.

The core idea

Most AI coding assistants still work like this:

• search the repo
• read a bunch of files
• answer or make changes
• forget most of the useful structure by the next long session

This works, but it breaks down as projects grow.

In long chat sessions, context drifts. In AI-built apps, docs and code drift. In vibe-coded products, a lot of important logic exists only as half-remembered patterns spread across chats, code, README files, and generated screens.

The idea behind an LLM wiki is simple:

Instead of forcing the AI to rediscover the codebase from raw files every time, give it a maintained intermediate layer: a small wiki inside the repo that summarizes the product, links the important parts together, and keeps a running memory of what the system actually is.

That wiki becomes:

• a long-term memory layer for the agent
• a context-drift reduction layer for long chats
• a reusable knowledge base for future sessions
• a compressed operational map of the codebase

So instead of pure "search and guess," the AI gets:

• short-term memory from the current task and chat
• long-term memory from the maintained wiki
• verification from the actual codebase underneath

That is the pattern.

Where KIOSK differs

Karpathy's original idea is broad. It works for personal knowledge, research, reading notes, team memory, and lots of other cases.

KIOSK is narrower and more practical for software builders.

It is an LLM wiki dedicated to code, documentation, and AI-assisted product development, especially in systems where trust, compliance, operations, and product clarity matter.

In KIOSK, the wiki is not just there so the AI remembers things better.

It is there to help manage the interaction between:

• the codebase
• the docs
• the AI builder
• the generated features
• the operational flows
• the help content
• the admin guidance
• the review and QA understanding

This matters a lot for vibe coders and low-code builders.

When AI is writing a large share of the code, the hard part stops being just "generate the feature." The hard part becomes:

• keeping the product model coherent
• keeping docs aligned with code
• keeping architecture understandable
• keeping help text and admin guidance current
• giving reviewers and QA a compressed picture of what changed

KIOSK is the layer that helps with that.

The simple KIOSK model

There are three practical layers.

1. The codebase and source docs

This is the real source of truth.

Your code, tests, migrations, configs, and important docs are what actually define the system.

The wiki should read from them, summarize them, and point back to them. It should never outrank them.

If the wiki says one thing and the code says another, the code wins.

2. The wiki

This is a folder inside the repo, usually llm-wiki/.

It contains:

• simple markdown pages
• an index
• a log
• a small claims file
• maybe a simple events or proposals file

This is the maintained knowledge layer.

It is not meant to replace the code. It is meant to make the codebase understandable and reusable by both humans and AI agents.

3. The rules

This is the instruction file for the agent, usually llm-wiki/AGENTS.md.

It tells the AI:

• how to update the wiki
• what the source of truth is
• what to do when unsure
• which pages to maintain
• how to mark uncertainty
• how to log changes

Without this file, the agent is just improvising. With it, the agent behaves like a wiki maintainer.

Why vibe coders should care

If you are building with Lovable, Cursor, Claude Code, or similar tools, this problem shows up quickly:

• you can build fast
• the repo gets big fast
• the architecture becomes fuzzy
• the same questions keep getting re-asked
• the AI starts missing prior context
• the docs lag behind reality

At that point, pure RAG is not enough.

You do not just need better search. You need a maintained, compressed map of the codebase that the AI can reuse over time.

That is what the wiki gives you.

And in the KIOSK version, that wiki is not just engineering notes. It can produce useful knowledge views for different people:

• builders
• operators
• administrators
• customer support
• reviewers
• QA testers

The same underlying wiki can power:

• internal architecture notes
• feature summaries
• admin help
• customer-facing help drafts
• reviewer notes
• QA regression checklists

Minimum viable implementation

If you want an AI builder to add a primitive but functional version of this to your repo, keep it simple.

Start with this folder structure:

llm-wiki/
  AGENTS.md
  index.md
  log.md
  claims/
    claims.json
  pages/
    overview.md
    features.md
    architecture.md
    admin-guide.md
    help-center.md
    qa-notes.md
  proposals/
    README.md
    changes.json
  raw/
    README.md

This is enough to build a useful first version.

You do not need a database. You do not need embeddings. You do not need a search engine. You do not need a full compliance engine on day one.

Just use markdown and a few JSON files inside git.

What each file should do

index.md

The table of contents for the wiki.

Each page should be listed with:

• page name
• one-line summary
• who it is for
• last updated date

The AI should read this first before exploring the rest of the wiki.

log.md

An append-only activity log.

It should record things like:

• source ingested
• page updated
• feature changed
• contradiction found
• help content refreshed
• QA notes updated

This gives both humans and AI a timeline of how the wiki evolved.

claims/claims.json

A simple structured memory file.

A primitive version can store entries like:

• id
• page
• claim
• status
• evidence
• last_checked

Statuses can start simple:

• verified
• documented
• needs_review
• stale

This gives the AI something more structured than raw markdown, without forcing a full governance system immediately.

pages/*.md

These are the human-readable knowledge projections.

A good primitive set is:

• overview.md: what the product is
• features.md: key feature map
• architecture.md: major technical flows
• admin-guide.md: what operators/admins need to know
• help-center.md: compressed customer-facing help
• qa-notes.md: things QA and reviewers should verify

AGENTS.md

This is the most important control file.

It should tell the AI:

• code and config beat wiki text
• when code and docs disagree, mark needs_review
• update index.md and log.md every time the wiki changes
• keep pages short, compressed, and link-rich
• prefer updating existing pages over creating duplicates
• create customer/admin/QA views from the same underlying understanding
• never silently present uncertain things as verified facts

How the workflow should work

Ingest

When a major source changes, the AI should:

• read the changed code and docs
• update relevant wiki pages
• update claims.json
• update index.md
• append a log.md entry

Examples:

• a new feature
• an auth flow change
• a billing change
• a new admin screen
• a changed data model
• a new compliance-related requirement

Query

When asked a question, the AI should:

1. read the wiki first
2. use the wiki to orient itself
3. verify important answers against code or docs
4. optionally write the answer back into the wiki if it is durable

This is what turns the wiki into reusable memory instead of disposable chat output.

Drift check

Periodically, the AI should look for drift:

• code changed but docs did not
• help text is stale
• QA notes are outdated
• admin guidance no longer matches the product
• architecture summary is missing a recent feature

Then it updates the wiki accordingly.

Lint

The AI should also periodically health-check the wiki:

• stale pages
• duplicate pages
• orphan pages
• broken links
• claims with weak evidence
• pages that need review
• missing customer/admin/QA views for important features

Keep the source-of-truth order clear

This is the most important KIOSK rule.

The wiki is useful because it is derived. It becomes dangerous if people start treating it like the thing that defines the system.

The source-of-truth order should be:

1. code, tests, migrations, configs, and critical source docs
2. the maintained wiki
3. chat output

That means the integrated codebase is the deepest operational truth underneath the documented sources the wiki references.

The wiki helps humans and AI understand the repo. It does not replace the repo.

What makes the KIOSK version practical

The main KIOSK insight is that the wiki should not only help the AI remember the codebase.

It should also help the AI maintain usable compressed knowledge projections for multiple audiences.

For example, the same feature understanding can feed:

• an internal engineering summary
• a customer-facing help article
• an admin operation note
• a code review summary
• a QA checklist

That is why this pattern is so useful in AI-built products.

The AI is already touching lots of code. The wiki gives it a place to compress and stabilize what it learned, then turn that knowledge into reusable documentation instead of forcing everyone to rediscover everything through code search.

What not to do first

Do not start by building a giant platform.

For a primitive version:

• do not add a database first
• do not add embeddings first
• do not add heavy automation first
• do not try to make it fully autonomous first
• do not let it silently rewrite reality

Start with:

• files
• markdown
• a claims file
• an index
• a log
• a few key pages
• a clear AGENTS.md

That is enough to make the pattern real.

A good prompt to give your AI builder

If you want a tool like Lovable or Cursor to scaffold this, you can give it something like:

Add a primitive llm-wiki/ system to this repo.

The goal is to create a maintained wiki that helps AI agents and humans understand the codebase over long sessions, reduces context drift, and keeps compressed product knowledge aligned with the code.

Requirements:

• The codebase is the canonical source of truth.
• The wiki is derived and must never outrank the code.
• Create llm-wiki/AGENTS.md, index.md, log.md, claims/claims.json, and seed pages for overview, features, architecture, admin guide, help center, and QA notes.
• Add simple rules for how the AI should update the wiki after code or docs changes.
• Add a lightweight logging and claims format.
• Keep the implementation file-based and git-friendly.
• Make the pages useful for builders, admins, customer help, code reviewers, and QA.
• If the system is uncertain, it should mark content as needing review instead of presenting it as verified.

That is enough for a capable AI builder to scaffold a useful first version.

Why this works

The painful part of building and maintaining a codebase is not only writing the code.

It is keeping the understanding of the codebase current:

• what the system does
• how it is organized
• which features exist
• what changed
• what is still trustworthy
• what users, admins, reviewers, and QA need to know

Humans are bad at maintaining that layer consistently. AI agents are surprisingly good at it.

So the KIOSK version of the LLM wiki uses the AI for what it is best at:

• summarizing
• cross-referencing
• compressing
• updating many files at once
• turning scattered repo knowledge into reusable structure

The human still decides what matters. The codebase still defines reality. But the wiki becomes the maintained memory layer that keeps both humans and agents from getting lost.

Note

This is a simpler, buildable version of the KIOSK idea.

The full KIOSK implementation goes much further with governed claims, proposals, structured events, contradiction handling, freshness checks, and auditability.

But you do not need all of that to start.

If the original LLM wiki pattern is "give the AI a maintained knowledge layer instead of pure RAG," the KIOSK version is "give the AI a maintained, codebase-integrated knowledge layer that helps build, document, review, and operate complex software systems without losing the code as the final source of truth."

Same idea. More practical for software builders. Much more useful for vibe-coded products.

Thanks for sharing :) looking forward to test it out!