Diese Werkstattnotiz fragt, was ein LLM-Wiki in einer realen Codebasis tatsächlich verändert. Die Gegenproben im Projekt Lutions liefern keinen Effizienzbeweis. Sie zeigen aber, dass der wiki-first-Einstieg Suchwege, Quellen und Antwortgrenzen bei mehrschichtigen Aufgaben sichtbarer machen kann.
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.
Mein Projekt “Lutions” begann als selbstgebautes Ticketsystem aus Frust über Lizenzkosten und Cloud-Zwang. Inzwischen ist daraus ein praktisches Experimentierfeld für Agentic AI, Entwicklungsprozesse, LLM-Wikis und die Zusammenarbeit zwischen Mensch und KI-Agent geworden.
Täglich nutzen wir KI, doch was passiert wirklich in der “Black Box”? In diesem Auftakt unserer neuen Blog-Serie dekonstruieren wir die Architektur moderner LLMs nach dem EVA-Prinzip. Wir analysieren anhand zweier konkreter Szenarien, warum ein Sprachmodell bei “Hauptstadt” nicht immer an “Berlin” denkt und wie es eine Parkbank vom Finanzinstitut unterscheidet. Wir unternehmen eine wissenschaftliche Reise von der abstrakten Theorie zur interaktiven Simulation mit dem LLM Explorer.
Die softwareseitige Transformation eines KI-generierten Prototyps in ein strukturiertes Release erfolgt durch die Integration von KI-Werkzeugen in klassische Entwicklungsumgebungen wie GitHub. Am Beispiel einer Web-Applikation wird der Einsatz von Codex für die Code-Analyse, die automatisierte Erstellung von Pull Requests sowie die Pflege technischer Dokumentationen (README, CHANGELOG) aufgezeigt. Während die KI Effizienzgewinne bei der Umsetzung fachlicher Logik und UX-Verbesserungen bietet, bleiben die abschließende Qualitätssicherung, das Kontext-Management und strategische Architekturentscheidungen in menschlicher Verantwortung. Der Fokus liegt auf der Etablierung dauerhaft tragfähiger, professioneller Workflows für die KI-gestützte Softwareentwicklung.
Basierend auf einer Literaturrecherche wird untersucht, wie sich in längeren Interaktionen mit großen Sprachmodellen Bedeutungsverschiebungen, Strukturbrüche, thematische Abdrift und Kontextverlust manifestieren.
Der Artikel beschreibt wiederkehrende Probleme bei der Arbeit mit LLMs: Begriffe und Strukturen verschieben sich im Dialog („Drift“), frühere Aussagen verlieren an Bedeutung und lange Chats werden zunehmend instabil. Zudem fehlt den Modellen eine verlässliche Persistenz – sowohl innerhalb eines Chats als auch zwischen Sitzungen.
Ich habe mich schon länger gefragt, ob künstliche Intelligenz wirklich eine substanzielle Hilfe beim Programmieren sein kann. Als jemand, der schon oft erlebt hat, wie hoch die Hürden für den Einstieg sein können – komplexe Syntax, unbekannte Frameworks und endlose Fehlersuchen – wollte ich das selbst auf die Probe stellen. Deshalb habe ich es einfach