Flato.ai Open Sources Project-LLM-Wiki for Vibe Coding and Loop Engineering

AI coding is getting faster. The harder question is whether the project gets smarter after each AI-assisted session.

That is the idea behind Project-LLM-Wiki, the open source repo from the Flato.ai team:

https://github.com/sologovision/Project-LLM-wiki

Project-LLM-Wiki turns Andrej Karpathy's LLM Wiki idea into a practical system for software repositories. Instead of asking every coding agent to rediscover the same architecture, contracts, decisions, and pitfalls, the repo keeps a small AI-readable knowledge layer next to the source code.

For builders using Vibe coding, this matters. AI can generate code quickly, but serious products need memory. They need a way for each loop to improve the next one.

What Project-LLM-Wiki Does

Project-LLM-Wiki adds a lightweight structure to a repository:

• AGENTS.md, CODEX.md, or similar entry files tell agents where to start.
• .harness/ defines read order, workflows, risk gates, and verification rules.
• .project-wiki/ stores durable project knowledge, including architecture, contracts, decisions, and failure modes.
• raw/ keeps messy source material before it becomes trusted project memory.
• A wiki graph script can map relationships between pages and catch broken links.

The key principle is simple: current code is still the source of truth. The wiki is not a replacement for the codebase. It is a reviewed memory layer that helps AI agents find the right context, verify it, and update durable knowledge when something important changes.

Why Flato.ai Built It

Flato.ai works on AI-native design infrastructure, plugin workflows, and developer tooling. Those systems have many moving parts: product claims, API contracts, plugin manifests, release rules, docs, canvas behavior, and agent instructions.

In that kind of environment, prompt-only memory is not enough. A coding agent can be very productive in one session and still waste time in the next session because the repo has forgotten what the last agent learned.

With Project-LLM-Wiki, Flato.ai turned repeated context into repo-local operating memory. In the team's own workflow, it helped improve AI-assisted development efficiency by at least 30%.

That number is useful, but the bigger point is the loop. When an agent finds a stale doc, brittle contract, hidden boundary, or recurring failure mode, that lesson can be recorded in .project-wiki/ so the next agent does not repeat the same mistake.

From Vibe Coding to Loop Engineering

Vibe coding is great when momentum matters. You describe the product direction, let the agent generate, inspect the output, and keep moving.

But as the codebase grows, velocity starts depending on memory hygiene. The agent needs to know:

• Which docs are still true?
• Which API contract should not be broken?
• Which old decision still matters?
• Which pitfall has already cost the team time?
• What should be updated after this change?

This is where Flato.ai's idea of Loop Engineering becomes important. A coding loop should not only produce a patch. It should leave behind useful, verified memory for the next loop.

Project-LLM-Wiki gives that loop a place to live.

Why It Is Different from Normal Documentation

Project-LLM-Wiki is not trying to generate a huge documentation site.

Most generated docs become stale. Stale docs are annoying for humans and dangerous for agents. A confident agent reading outdated documentation can move very fast in the wrong direction.

Project-LLM-Wiki takes a smaller approach:

• Keep pages short.
• Cite the source of important claims.
• Mark historical docs as historical.
• Route agents through a repeatable workflow.
• Update memory only when durable knowledge changes.

In other words, it is not "more docs." It is better project memory.

Who Should Try It

Project-LLM-Wiki is most useful for teams that already use AI coding agents on real repositories:

• product teams using Codex, Claude Code, Cursor, or similar tools;
• open source maintainers who want agent instructions to be reviewable in Git;
• developer-tool teams with public contracts and docs;
• AI-native startups that need faster handoffs between human and agent work;
• teams practicing Vibe coding but starting to feel context drift.

It is probably too much for a throwaway prototype. But for an active product repo, it can be a simple way to make AI-assisted development compound instead of reset every session.

Quick Start

Once the repo is local, the basic flow is:

node scripts/init-project-llm-wiki.mjs /path/to/target-repo
node scripts/verify-project-llm-wiki.mjs /path/to/target-repo
node scripts/wiki-graph.mjs /path/to/target-repo

Start small. Add the harness. Seed one architecture page, one contract page, and one decision page. Then ask your next coding agent to follow the project entry instructions.

The goal is not to create a documentation burden. The goal is to make the repository easier for both humans and agents to remember.

Explore the open source repo here:

https://github.com/sologovision/Project-LLM-wiki

Read the full Flato.ai article here:

https://www.flato.ai/blogs/project-llm-wiki-karpathy-llm-wiki-vibe-coding-loop-engineering