Look at what actually changed how developers work this year and you won't find a new IDE or framework. You'll find a GitHub gist from Andrej Karpathy and a repo of 23 prompt files from Garry Tan. No binaries, no SaaS, no vector database — just markdown that tells an agent how to behave. That's not a coincidence. It's the shape of the new abstraction layer.

Karpathy's LLM Wiki: knowledge that compounds

In April Karpathy published his personal knowledge-base pattern, and it's almost aggressively simple. Three layers: raw/ for immutable sources (articles, PDFs, transcripts), wiki/ for interlinked pages the LLM writes and maintains, and a CLAUDE.md that defines schema and conventions. Three operations: ingest new sources, query with citations, lint for contradictions and stale pages.

The line that stuck with me: "You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it." That's the inversion. Classic RAG re-derives understanding from raw documents on every query and throws it away afterwards. The LLM wiki keeps it: every ingest updates entity pages, cross-references and an index, so the knowledge base gets better the more you feed it — a researcher who keeps notes instead of one with amnesia. The tooling is deliberately boring: Claude Code as maintainer, Obsidian as viewer, git for history. Everything is a file. Everything diffs.

gstack: a startup team in 23 markdown files

Garry Tan's gstack uses the same material for a different problem. It packages his Claude Code setup as 23 opinionated skills that role-play a whole startup: a CEO who challenges your scope in /plan-ceo-review, an engineering manager auditing architecture, a designer, a QA lead driving a real browser, a security officer running OWASP and STRIDE checks, a release engineer who ships. Tan reports roughly 10,000 lines of code and 100 pull requests a week over a 50-day stretch, and the repo collected tens of thousands of stars within weeks.

His framing is the honest one: "The point isn't who typed it, it's what shipped." You can argue about lines-of-code metrics, but the structural claim holds — opinionated prompts, not custom tooling, are becoming the abstraction layer for AI-assisted development. A skill file is a job description that executes.

Prose is the new config

Side by side, the pattern is obvious. Karpathy encodes what a team knows in markdown; Tan encodes how a team works. Both bet on the same properties: plain text is model-agnostic, versionable, reviewable in a pull request and readable by the intern and the agent alike. The moat isn't the format — it's the curation. A wiki is only as good as its lint discipline, and a skill library only as good as the opinions baked into it.

I use both patterns daily: in my own projects — including this website, which an agent helps maintain from a folder of markdown notes — and in my current enterprise work, where a shared knowledge system turned out to matter more than any single tool. One lesson from there: my first idea was a repository template every team would copy. Many users had never opened an IDE, so we moved to a shared, accessible system people can feed without touching git. The format was right; the access path wasn't.

What I tell clients

The takeaway isn't "install gstack." It's that your team's tribal knowledge and working agreements are about to become executable assets — or liabilities, if they only live in people's heads and slide decks nobody opens. Start embarrassingly small: one CLAUDE.md per repo, three skills for your most repetitive review rituals, one shared wiki folder with an ingest routine — and make sure people who don't live in an IDE can contribute. Then let it compound. The teams I see winning with agents aren't the ones with the biggest budgets; they're the ones whose knowledge and processes were already written down.

Schau dir an, was dieses Jahr wirklich verändert hat, wie Entwickler arbeiten — du findest keine neue IDE und kein neues Framework. Du findest einen GitHub-Gist von Andrej Karpathy und ein Repo mit 23 Prompt-Dateien von Garry Tan. Keine Binaries, kein SaaS, keine Vektordatenbank — nur Markdown, das einem Agenten sagt, wie er sich verhalten soll. Das ist kein Zufall. Das ist die Form der neuen Abstraktionsschicht.

Karpathys LLM-Wiki: Wissen mit Zinseszins

Im April hat Karpathy sein persönliches Wissensdatenbank-Muster veröffentlicht, und es ist fast schon provokant einfach. Drei Ebenen: raw/ für unveränderliche Quellen (Artikel, PDFs, Transkripte), wiki/ für verlinkte Seiten, die das LLM schreibt und pflegt, und eine CLAUDE.md, die Schema und Konventionen festlegt. Drei Operationen: neue Quellen aufnehmen, mit Quellenangaben abfragen, auf Widersprüche und veraltete Seiten prüfen.

Der Satz, der hängen geblieben ist: „You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it.“ Das ist die Umkehrung. Klassisches RAG leitet das Verständnis bei jeder Abfrage neu aus Rohdokumenten ab und wirft es danach weg. Das LLM-Wiki behält es: Jede Aufnahme aktualisiert Entitätsseiten, Querverweise und einen Index, sodass die Wissensbasis besser wird, je mehr du hineingibst — eine Rechercheurin, die sich Notizen macht, statt einer mit Gedächtnisverlust. Das Tooling ist bewusst langweilig: Claude Code als Pfleger, Obsidian als Viewer, git für die Historie. Alles ist eine Datei. Alles lässt sich diffen.

gstack: ein Startup-Team in 23 Markdown-Dateien

Garry Tans gstack nutzt dasselbe Material für ein anderes Problem. Es verpackt sein Claude-Code-Setup als 23 meinungsstarke Skills, die ein ganzes Startup spielen: einen CEO, der in /plan-ceo-review deinen Scope hinterfragt, eine Engineering-Managerin, die die Architektur prüft, einen Designer, eine QA-Leitung, die einen echten Browser steuert, einen Security-Verantwortlichen mit OWASP- und STRIDE-Checks und einen Release-Engineer, der ausliefert. Tan berichtet von rund 10.000 Zeilen Code und 100 Pull Requests pro Woche über 50 Tage, und das Repo sammelte innerhalb weniger Wochen Zehntausende Sterne.

Seine Einordnung ist die ehrliche: „The point isn't who typed it, it's what shipped.“ Über Lines-of-Code-Metriken kann man streiten, aber die strukturelle Aussage hält — meinungsstarke Prompts, nicht eigenes Tooling, werden zur Abstraktionsschicht für KI-gestützte Entwicklung. Eine Skill-Datei ist eine Stellenbeschreibung, die sich ausführt.

Prosa ist die neue Konfiguration

Nebeneinander ist das Muster offensichtlich. Karpathy kodiert was ein Team weiß in Markdown; Tan kodiert wie ein Team arbeitet. Beide setzen auf dieselben Eigenschaften: Klartext ist modellunabhängig, versionierbar, im Pull Request prüfbar und für Praktikantin und Agent gleichermaßen lesbar. Der Burggraben ist nicht das Format — sondern die Kuratierung. Ein Wiki ist nur so gut wie seine Prüfdisziplin, eine Skill-Bibliothek nur so gut wie die Haltung, die in ihr steckt.

Ich nutze beide Muster täglich: in eigenen Projekten — auch für diese Website, die ein Agent aus einem Ordner voller Markdown-Notizen mitpflegt — und in meiner aktuellen Enterprise-Arbeit, wo ein gemeinsames Wissenssystem wichtiger war als jedes einzelne Tool. Eine Lehre von dort: Meine erste Idee war ein Repository-Template, das jedes Team kopiert. Viele Nutzer hatten aber noch nie eine IDE geöffnet, also sind wir auf ein gemeinsames, zugängliches System umgeschwenkt, das man ohne git befüllen kann. Das Format war richtig; der Zugangsweg nicht.

Was ich Kunden sage

Die Lehre ist nicht „Installiert gstack“. Sondern dass das Stammeswissen und die Arbeitsvereinbarungen eures Teams gerade zu ausführbaren Assets werden — oder zu Altlasten, wenn sie nur in Köpfen und in Foliensätzen leben, die niemand öffnet. Fangt peinlich klein an: eine CLAUDE.md pro Repo, drei Skills für eure häufigsten Review-Rituale, ein gemeinsamer Wiki-Ordner mit einer Aufnahme-Routine — und sorgt dafür, dass auch Leute beitragen können, die nicht in einer IDE leben. Dann lasst es wachsen. Die Teams, die ich mit Agenten gewinnen sehe, sind nicht die mit dem größten Budget, sondern die, deren Wissen und Prozesse schon aufgeschrieben waren.