Diese Werkstattnotiz rekonstruiert Lutions-Gegenproben zwischen repo-first und wiki-first. Sie misst keine Antwortqualität, sondern strukturelle Explizitheit: In mehrschichtigen Aufgaben wurden Quellenpfade, Prüfschichten und Grenzen im Knowledge-Layer-Arm anders und sichtbarer angeordnet.
Der dritte Artikel der LLM-Wiki-Reihe zeigt, wie aus dem Pattern eine operative Wissensschicht wurde. Am Praxisprojekt Lutions wird nachvollziehbar, wie Wiki-first Intake, Knowledge Operations, Freshness-Prüfung und Release-Governance zusammenspielen, ohne das Wiki zur vermeintlichen Wahrheitsmaschine zu machen.
Softwarewissen liegt selten nur im Code. Der Artikel entwickelt aus dem LLM-Wiki-Pattern die Idee eines code-nahen Knowledge Layers, der Code, Tests, Tickets, Reviews und Releases so verbindet, dass Menschen und KI-Agenten gezielter prüfen und entscheiden können.
Traditionelles KI-Wissensmanagement scheitert oft an seiner eigenen Komplexität: Teure Vektordatenbanken, fehleranfällige RAG-Pipelines und Wissensbanken, die unter ihrer eigenen Last zusammenbrechen, sind für viele Entwickler Alltag. Mit seinem viralen „LLM-Wiki“-Ansatz hat Andrej Karpathy einen Gegenentwurf vorgestellt, der auf radikale Einfachheit setzt: Ein persistentes, selbstwachsendes KI-Second-Brain aus reinem Markdown, organisiert in drei klaren Schichten. Doch wie funktioniert das Prinzip aus raw/, wiki/ und normativer Steuerung technisch im Detail? Wo liegen die operativen Stärken eines textbasierten Graphen – und warum sollte eine KI niemals das vollständige Knüpfen unseres Wissensnetzes übernehmen? Eine fundierte Analyse eines technologischen Paradigmenwechsels.