From IT. Not from theory.
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.
Ein reflektierender Rückblick auf das erste Jahr reflectIT: Welche Themen haben 2025 geprägt, welche Fragestellungen haben sich herauskristallisiert – und was sagt das über IT, Organisation, Regulierung und den Einsatz von KI aus?
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.
Mit dem Digital Omnibus will die EU-Kommission ihr digitales Regelwerk vereinfachen und besser aufeinander abstimmen. Der Beitrag ordnet ein, welche Ziele damit verfolgt werden, wo Chancen und Risiken liegen und was der aktuelle Zeitplan bedeutet. Im Fokus stehen die Auswirkungen auf IT-Governance, Architektur und Compliance – jenseits juristischer Detailfragen, aber mit Blick auf die praktische Umsetzung in IT-Organisationen.