AI, Data & Automation

Vom LLM-Wiki zum code-nahen Knowledge Layer

By | | AI, Automation, GenAI, Governance, LLM
LLM Wiki

Dieser Artikel ist der zweite Schritt nach dem Grundlagenartikel zum LLM-Wiki. Dort ging es um das Pattern selbst: eine persistente, verlinkte und überprüfbare Wissensschicht zwischen Rohquellen und späteren Fragen. Hier geht es um die Anschlussidee: Wie könnte man ein solches LLM-Wiki agentenbasiert in der Softwareentwicklung einsetzen, welche Erwartungen wären realistisch, und woran könnte man später erkennen, ob der Ansatz wirklich hilft?

Ein Entwickler steht vor einem API-Parameter, der merkwürdig defensiv wirkt. Im Code sieht man, wie er verarbeitet wird. In einem Test sieht man einen Grenzfall. In einem alten Ticket steht, dass an genau dieser Stelle einmal Daten verloren gingen. In einem Review wurde eine einfachere Lösung verworfen. In einer Release Note steht, seit wann das Verhalten gilt.

Keine dieser Quellen erklärt den Zusammenhang allein. Erst zusammen beantworten sie die eigentliche Frage: Darf ich diesen Parameter ändern, oder hole ich damit einen alten Fehler zurück?

Genau an dieser Stelle wird das LLM-Wiki-Pattern für Softwareentwicklung interessant. Karpathy beschreibt es als menschenlesbare Markdown-Wissensbasis, die von einem LLM mitgepflegt wird. Googles Open Knowledge Format zeigt zusätzlich, wie solche Wissensbestände portabler und agentenlesbarer werden können (Karpathy, 2026; McVeety und Hormati, 2026; GoogleCloudPlatform, 2026).

Die naheliegende Anschlussfrage lautet: Was passiert, wenn diese Rohquellen nicht Artikel, Notizen und Gesprächsprotokolle sind, sondern Code, Tests, Tickets, Reviews, Releases, Konfiguration und Betriebswissen?

Meine These: Softwareentwicklung braucht eine code-nahe Wissensschicht, weil Kontext sonst zur permanenten Nebenarbeit wird. Ein Knowledge Layer ersetzt keinen Sourcecode. Er macht nachvollziehbarer, welche Quellen man prüfen muss, warum ein Systemteil so gebaut wurde und wie belastbar dieses Verständnis gerade ist.

Dieser Artikel ist deshalb bewusst noch kein How-to. Es geht um die Übertragung: vom allgemeinen LLM-Wiki-Prinzip zu einer erklärenden Schicht über lebende Software.

1. Softwarewissen liegt nicht nur im Repository

Auf den ersten Blick scheint Softwarewissen im Repository zu liegen. Dort ist der Sourcecode. Dort liegen Tests, Konfiguration, Migrationsskripte, Build-Logik, Schnittstellen, Komponenten und vielleicht auch Architekturentscheidungen. Wenn man wissen will, was ein System tatsächlich tut, führt am Code kein Weg vorbei. Aber jeder, der länger an Software arbeitet, weiß auch: Das Wissen eines Projekts liegt nicht nur im Code.

Ein Ticket erklärt vielleicht, warum eine Funktion überhaupt gebaut wurde. Ein Review enthält die Abwägung, warum eine Lösung akzeptiert oder verworfen wurde. Ein Testfall zeigt, welches Verhalten ausdrücklich abgesichert werden soll. Eine Konfigurationsdatei verrät, welche Annahmen für bestimmte Umgebungen gelten. Ein Release-Eintrag zeigt, ab wann eine Änderung ausgeliefert wurde. Ein Supportfall dokumentiert, wie ein Nutzer ein Verhalten tatsächlich erlebt. Eine Fehlermeldung zeigt, wo eine Annahme in der Praxis gebrochen ist.

All das ist Entwicklungswissen. Es ist nur selten sauber an einem einzigen Ort. Softwareprojekte erzeugen fortlaufend Spuren: Codeänderungen, Tests, Tickets, Kommentare, Review-Diskussionen, Entscheidungen, Release Notes, Fehleranalysen, Betriebsnotizen, Workarounds und spätere Korrekturen. Diese Spuren sind nicht wertlos, nur weil sie verstreut sind. Oft liegt gerade in ihrer Verbindung der eigentliche Kontext.

2. Suche findet Treffer, aber nicht automatisch Bedeutung

Man kann Code durchsuchen. Man kann Tickets durchsuchen. Man kann Dokumentation durchsuchen. Man kann Pull Requests, Testnamen, Fehlermeldungen und Release Notes durchsuchen.

Das hilft. Aber es löst nicht das ganze Problem.

Code zeigt, wie etwas umgesetzt ist. Er sagt nicht immer, warum es genau so umgesetzt wurde. Tickets zeigen Absicht, Verlauf und Diskussion. Aber sie sind nicht automatisch die aktuelle Realität. Tests zeigen erwartetes Verhalten. Aber sie erklären nicht immer, welche Produktannahme dahintersteht. Klassische Dokumentation kann hervorragend sein. Aber sie driftet leicht vom System weg, wenn sie nicht eng genug mit laufender Entwicklung verbunden bleibt.

Das Problem ist also nicht, dass Quellen fehlen. Das Problem ist, dass jede Quelle nur einen Ausschnitt liefert.

Die eigentliche Arbeit besteht häufig darin, diese Ausschnitte wieder zusammenzubringen. Genau diese Arbeit wiederholt sich ständig: in Reviews, beim Onboarding, beim Debugging, vor Refactorings, in Supportanalysen und bei jeder Agentenaufgabe, die mehr als eine isolierte Codezeile betrifft.

Ein KI-Assistent macht im Grunde dasselbe. Er sucht, liest, kombiniert und schließt. Ohne kuratierte Orientierung bewegt auch er sich jedes Mal neu durch Fragmente. Dann wird Kontext selbst zur Entwicklungsaufgabe.

3. Was aus dem Grundlagenartikel folgt

Der Grundlagenartikel beschreibt drei entscheidende Eigenschaften des LLM-Wiki-Patterns (Hermanns, 2026a).

  1. Rohquellen bleiben erhalten. Ein Wiki ersetzt sie nicht, sondern verweist auf sie.
  2. Die synthetisierte Wissensschicht ist menschenlesbar, versionierbar und prüfbar. Sie soll nicht nur Antworten liefern, sondern Quellen, Unsicherheit und Widersprüche sichtbar machen.
  3. Governance gehört zum Pattern. Regeln für Quellenführung, Status, Linting und menschliche Prüfung sind keine spätere Ergänzung, sondern Teil des Nutzens.

Übertragen auf Softwareentwicklung heißt das: Ein code-naher Knowledge Layer darf nicht behaupten, selbst die Wahrheit über das System zu sein. Er muss zeigen, aus welchen Primärquellen ein Verständnis abgeleitet wurde und wo die eigentliche Prüfung stattfinden muss.

Das ist der Punkt, an dem der Begriff “Wiki” leicht in die Irre führt. Es geht nicht um ein weiteres Handbuch. Es geht um eine vermittelnde Schicht zwischen technischer Realität, verstreuten Entwicklungsquellen und späteren Fragen.

4. Anschluss an bestehende Bewegungen

Diese Idee entsteht nicht im luftleeren Raum. In der Softwarearchitektur gibt es seit langem Architectural Knowledge Management. Keim und Kaplan beschreiben Architekturwissen als verteilt über heterogene Artefakte wie Anforderungen, Diagramme, Code und Dokumentation; daraus entstehen Zugriffsprobleme, Inkonsistenzen und Architekturdrift (Keim und Kaplan, 2026). Hyun und Hurtado betrachten die Traceability zwischen Architekturentscheidungen und Softwareartefakten und zeigen, dass relevante Informationen auch in Code-Repositories, Pull Requests, Task-Systemen und technischen Dokumenten stecken (Hyun und Hurtado, 2023).

Architecture Decision Records greifen einen Ausschnitt dieses Problems auf. Nygard beschreibt ADRs als kurze Dokumente, die eine Architekturentscheidung, ihren Kontext und ihre Konsequenzen festhalten (Nygard, 2011). Ein code-naher Knowledge Layer würde ADRs also nicht ersetzen. Er würde sie stärker mit Code, Tests, Tickets, Reviews und Betriebserfahrung verbinden.

Auch Docs-as-Code und Living Documentation zeigen in dieselbe Richtung. Adzic beschreibt Living Documentation als Dokumentation, die durch Beispiele, Spezifikation und Tests mit dem System verbunden bleibt, statt separat zu altern (Adzic, 2020). Der Knowledge Layer erweitert diesen Gedanken: Nicht jede Wissensseite ist ein Handbuchtext, aber jede belastbare Aussage sollte überprüfbare Quellen, Status und Anschlussstellen zur technischen Realität haben.

Codebase Maps und Code Knowledge Graphs ergänzen die Struktur-Seite. Sie modellieren Dateien, Symbole, Imports, Calls, Routen, Tests, Domänen und Beziehungen in einem Repository (Developers Digest, 2026). Für diese Quelle gilt eine Einschränkung: Sie ist hier als branchennaher Impuls nützlich, aber kein etablierter Standardbeleg. Die stärkere Aussage bleibt deshalb vorsichtig: Ein Software-Wiki sollte nicht nur aus Fließtext bestehen. Strukturierte Beziehungen können helfen, Impact, Abhängigkeiten und Prüfpfade greifbarer zu machen.

Damit wird der Knowledge Layer nicht zum Konkurrenzmodell zu Suche, RAG oder Knowledge Graphs. Er liegt eher dazwischen. Suche findet Material. Graphen modellieren Beziehungen. Tests und statische Analyse prüfen bestimmte Eigenschaften. Das Wiki erklärt, warum diese Dinge zusammengehören, woher diese Erklärung kommt und wie sicher sie ist.

Für KI-Assistenten gehört das in den größeren Bereich des Context Engineering. Anthropic beschreibt Context Engineering als bewusste Kuratierung des Informationszustands eines Agenten, nicht nur als Prompt-Formulierung (Anthropic, 2025). Fowler warnt zugleich vor der Illusion, solche Kontextkonfigurationen könnten Agentenverhalten deterministisch kontrollieren; sie verbessern Wahrscheinlichkeiten, ersetzen aber keine Prüfung (Fowler, 2026). Genau deshalb ist ein Knowledge Layer kein Kontrollinstrument. Er ist ein Orientierungs- und Prüfpfad.

5. Sourcecode bleibt die primäre Wahrheit

Ein code-naher Knowledge Layer darf den Sourcecode nicht ersetzen wollen. Code, Tests, Konfiguration, Datenmodell, Laufzeitverhalten und Releases bleiben die primäre Realität des Systems. Wenn Wiki und Code widersprechen, ist das nicht automatisch neues Wissen, sondern zuerst ein Drift-Signal.

Das Wiki hat eine andere Rolle. Es ist eine kuratierte, erklärende Schicht über der technischen Realität. Es sagt nicht: “So ist das System, weil es hier steht.” Es sagt eher: “So verstehen wir diesen Teil des Systems aktuell, und diese Quellen stützen dieses Verständnis.”

Dadurch macht es Wissen nicht automatisch wahr, aber überprüfbarer. Es zeigt, welche Aussagen aus welchen Quellen abgeleitet wurden, wo Unsicherheiten liegen und an welchen Stellen die eigentliche Prüfung stattfinden muss.

6. Ein Denkmodell: Reality, Knowledge Sources, Knowledge Layer

Für die Übertragung des LLM-Wiki-Prinzips auf Softwareentwicklung hilft ein einfaches Modell aus vier Rollen.

  • Reality ist das, was tatsächlich gilt: Sourcecode, Tests, Konfiguration, Datenmodell, Migrationsstand, Laufzeitverhalten und ausgelieferte Releases.
  • Knowledge Sources sind die Quellen, aus denen Verständnis entsteht: Tickets, Reviews, Architekturentscheidungen, Supportfälle, Fehlermeldungen, Betriebsnotizen, Dokumentation, Diskussionen und Analyseergebnisse.
  • Knowledge Layer ist die kuratierte Schicht, die Reality und Knowledge Sources in verständliche Zusammenhänge bringt. Sie beschreibt Module, Entscheidungen, Abhängigkeiten, Grenzen, offene Fragen, bekannte Risiken und relevante Primärquellen.
  • Knowledge Consumers sind die späteren Nutzer dieser Schicht: Entwickler, Architekten, Tester, Support, Administratoren, Product Owner und KI-Assistenten.

Dieses Modell verschiebt den Blick. Das Wiki ist nicht einfach ein weiterer Dokumentationsordner. Es vermittelt zwischen technischer Realität, verstreuten Wissensquellen und den Menschen oder Agenten, die mit dem System arbeiten müssen.

Damit wird auch klar, warum der erste Fokus nicht auf Endanwenderhilfe liegt.

Die folgende Darstellung fasst dieses Denkmodell zusammen: Der Knowledge Layer liegt nicht über der Realität als neue Wahrheit, sondern vermittelt zwischen technischer Realität, verstreuten Wissensquellen und den späteren Konsumenten dieses Wissens.

Die Anatomie des Knowledge Layers: Reality, Knowledge Sources, Knowledge Layer und Knowledge Consumers
Die Anatomie des Knowledge Layers: Reality, Knowledge Sources, Knowledge Layer und Knowledge Consumers

7. Zunächst keine Endanwenderhilfe

Ein LLM-Wiki für Softwareentwicklung wäre in dieser frühen Form kein Handbuch für Endanwender. Es erklärt nicht primär, wie man eine Funktion in der Oberfläche bedient, und es ersetzt keine Produkthilfe.

Der erste Schritt liegt näher am Entwicklungsprozess. Ein code-naher Knowledge Layer soll zunächst den Menschen helfen, die das System bauen, prüfen, betreiben, erklären oder weiterentwickeln: Entwicklern, Architekten, Testern, Support, Administratoren, Product Ownern und später auch KI-Assistenten.

Dass hierfür inzwischen eigene agentenlesbare Repository-Kontexte entstehen, zeigt AGENTS.md als Beispiel: Es beschreibt einen vorhersehbaren Ort für projektspezifische Hinweise, Setup- und Arbeitsregeln für Coding Agents (AGENTS.md, 2026). Mehr sollte man aus dieser Quelle nicht ableiten. Sie zeigt ein Format für Agentenkontext, nicht die vollständige Lösung für Softwarewissen.

8. Welche Fragen ein solcher Layer beantworten müsste

Noch bevor man über Umsetzung spricht, lässt sich die Zielrichtung an Fragen erkennen.

Ein code-naher Knowledge Layer müsste später zum Beispiel beantworten können:

  • Welche Module sind für einen bestimmten fachlichen Ablauf verantwortlich?
  • Welche Tests sichern diesen Ablauf ab?
  • Welche Tickets oder Entscheidungen erklären, warum er so gebaut wurde?
  • Welche Konfiguration beeinflusst das Verhalten?
  • Welche bekannten Einschränkungen oder Risiken gibt es?
  • Welche Fehlermeldungen, Supportfälle oder Betriebsnotizen hängen damit zusammen?
  • Welche Teile des Systems sind besonders änderungssensibel?
  • Welche Begriffe werden im Projekt auf eine spezifische Weise verwendet?
  • Welche Informationen sind gesichert, welche sind abgeleitet, welche sind möglicherweise veraltet?
  • Welche Quellen sollte ein Entwickler lesen, bevor er an diesem Bereich arbeitet?

Das sind keine reinen Suchfragen. Sie verlangen Verbindung.

Eine normale Suche kann Treffer liefern. Ein Knowledge Layer soll Zusammenhänge herstellen: zwischen Code und Entscheidung, zwischen Test und fachlicher Regel, zwischen Fehlermeldung und bekanntem Betriebswissen, zwischen Review-Kommentar und späterer Architekturgrenze.

Gerade für KI-Assistenten ist dieser Unterschied entscheidend. Ein Agent braucht nicht möglichst viel Kontext. Er braucht den richtigen Kontext: aktuell genug, quellenklar genug und passend zur Aufgabe.

9. Chancen

Die Chancen liegen nicht darin, dass plötzlich alles dokumentiert wäre. Sie liegen darin, dass Orientierung leichter wird.

Neue Entwickler könnten schneller verstehen, welche Teile eines Systems zusammengehören. Reviews könnten gezielter prüfen, ob eine Änderung zur bestehenden Architektur, zu früheren Entscheidungen und zu abgesicherten Erwartungen passt. Support und Administration könnten besser nachvollziehen, warum sich ein System in bestimmten Situationen so verhält. Product Owner könnten fachliche Auswirkungen besser einordnen. KI-Assistenten könnten mit präziserem Kontext arbeiten, statt große Teile des Repositories immer wieder neu zu interpretieren.

Ein guter Knowledge Layer könnte außerdem Wissensdrift früher sichtbar machen. Wenn eine Wiki-Seite sagt, dass ein Modul eine bestimmte Verantwortung hat, der Code aber inzwischen etwas anderes zeigt, entsteht ein prüfbarer Widerspruch. Wenn eine alte Entscheidung nicht mehr zur aktuellen Umsetzung passt, wird sie nicht stillschweigend vergessen, sondern als überholt oder klärungsbedürftig sichtbar.

Der Nutzen wäre also nicht “mehr Dokumentation”. Es geht um bessere Kontextqualität: schneller zur richtigen Quelle, klarer zwischen Fakt und Ableitung unterscheiden, weniger wiederholte Rekonstruktion und frühere Drift-Signale.

10. Woran man merken könnte, ob es funktioniert

Der Grundlagenartikel hat an dieser Stelle eine wichtige Lücke sichtbar gemacht: Karpathy, OKF und die angrenzende RAG-Literatur liefern keine einfache ROI-Formel für LLM-Wikis. Sie liefern aber Bewertungsachsen. Ein LLM-Wiki muss Antworten relevanter, quellenklarer und belastbarer machen. Es muss bei komplexeren Fragen helfen, mehrere Quellen zu verbinden. Und es muss im Arbeitsprozess erkennbar machen, ob Wissen auffindbar, aktuell und nützlich bleibt (Hermanns, 2026a; Ming et al., 2026; Es et al., 2023).

Für Softwareentwicklung würde ich daraus kein großes Messprogramm machen. Ich würde klein anfangen.

Zuerst bräuchte man eine Baseline: zehn bis fünfzehn typische Fragen, die in einem Projekt wirklich wiederkehren. Nicht abstrakte Prüfungsfragen, sondern Arbeitsfragen. Warum darf ein Benutzer diese Aktion nicht ausführen? Welche Tests sichern diesen Workflow? Welche Entscheidung erklärt diese Architekturgrenze? Welche Konfiguration beeinflusst dieses Verhalten? Welche Quellen sollte ein Agent lesen, bevor er an diesem Modul arbeitet?

Nach zwei bis vier Wochen hätte man damit noch keinen Nutzennachweis. Aber man hätte ein erstes Bild: Welche Fragen sind wichtig? Welche Quellen braucht man? Wo fehlt eine Wiki-Seite? Wo existiert Wissen, ist aber schlecht auffindbar? Wo entstehen Halluzinations- oder Drift-Risiken?

Nach sechs bis acht Wochen könnte man erste Signale prüfen. Werden die gleichen Fragen häufiger mit klarer Quelle beantwortet? Brauchen Entwickler oder Agenten weniger Suchschritte, bis sie bei den maßgeblichen Quellen landen? Werden Unsicherheiten früher benannt? Entstehen weniger Folgefragen, weil Antwortkern, Grenzen und Prüfpfad bereits sichtbar sind?

Nach etwa drei Monaten wäre eine erste vorsichtige Bewertung möglich. Nicht im Sinn eines betriebswirtschaftlich sauberen ROI, sondern als arbeitspraktischer Befund: Gibt es weniger Rework wegen übersehener Quellen? Sind Reviews besser vorbereitet? Werden Supportdiagnosen konsistenter? Finden neue Entwickler schneller in sensible Systembereiche hinein? Und erkennt der Agent früher, wann er nicht genug weiß?

Tokenverbrauch wäre dabei eine naheliegende, aber gefährliche Metrik. Die Hypothese lautet: Wenn ein Knowledge Layer gute Einstiegsseiten, Querverweise und Quellenpfade bereitstellt, muss ein Agent weniger breit suchen und weniger Kontext wiederholt rekonstruieren. Der Tokenverbrauch pro belastbarer Antwort könnte also sinken. Beweisen lässt sich das aber nur mit vergleichbaren Aufgaben. Absolute Tokenzahlen sind wenig aussagekräftig, weil sie von Modell, Tooling, Sessionlänge, Promptstrategie und Prüfpflichten abhängen.

Sinnvoller wäre deshalb eine qualitätsbezogene Effizienzfrage: Wie viele Tokens, Turns und Suchschritte braucht eine Antwort, die quellenklar, relevant und fachlich belastbar ist?

Ein kleiner Versuch könnte dieselben Fragen in zwei Varianten vergleichen: einmal ohne gezielten Wiki-Einstieg, einmal mit Wiki-Einstieg. Gemessen würden nicht nur Tokens, sondern auch Suchschritte, Quellenklarheit, Antwortqualität, Rückfragen und späterer Rework. Wenn die Wiki-Variante bei gleicher oder besserer Qualität weniger Aufwand braucht, wäre das ein echtes Effizienzsignal. Wenn sie ähnlich viele oder sogar mehr Tokens braucht, aber deutlich weniger Fehler, bessere Quellenbindung und weniger Nacharbeit erzeugt, wäre das ebenfalls ein Nutzen. Weniger Tokens bei schlechteren Antworten wären dagegen kein Erfolg.

Das ist der Punkt, an dem der code-nahe Knowledge Layer überprüfbar wird. Er darf nicht nur behaupten, Orientierung zu verbessern. Er muss zeigen, dass typische Fragen nach einiger Zeit besser beantwortet werden: mit klareren Quellen, weniger Rekonstruktion, früheren Drift-Signalen und einem vertretbaren Aufwand pro belastbarer Antwort.

11. Grenzen

Gerade weil die Idee stark ist, braucht sie klare Grenzen. Ein Wiki ersetzt keinen Code, keine Tests, keine Reviews und keine fachliche Prüfung. Bei Widersprüchen führen die primären Quellen.

Ein Wiki macht Wissen nicht automatisch wahr. Es kann sogar gefährlich werden, wenn generierte Zusammenfassungen autoritativer wirken als die Quellen, aus denen sie abgeleitet wurden. Deshalb muss ein code-naher Knowledge Layer immer mit Herkunft, Status, Unsicherheit und Aktualität umgehen.

Eine zweite Grenze betrifft Berechtigungen und Informationsräume. Wenn ein Wiki Wissen aus Tickets, Reviews, Supportfällen, Betriebsnotizen und Code zusammenführt, kann es Zusammenhänge sichtbar machen, die in den Ursprungssystemen bewusst getrennt waren. Gerade für spätere Assistants ist das heikel. Ein Knowledge Layer braucht deshalb nicht nur Quellenangaben, sondern klare Regeln, welche Informationen überhaupt zusammengeführt, gespeichert und an welche Konsumenten weitergegeben werden dürfen.

Eine dritte Grenze ist die Illusion von Kontrolle. Kontextdateien, Wikis und Agentenregeln können die Arbeit eines KI-Assistenten verbessern, aber sie garantieren kein Verhalten. Ein Agent kann relevante Hinweise übersehen, falsch gewichten oder zu selbstbewusst aus einer veralteten Seite schließen. Deshalb muss der Layer nicht nur Antworten ermöglichen, sondern auch Prüfpfade: Welche Primärquellen wurden herangezogen? Welche Annahmen sind abgeleitet? Welche Aussagen sind unsicher?

Auch Vollständigkeit ist kein realistisches Ziel. Ein Softwareprojekt ändert sich zu schnell, als dass jede kleine Bewegung sofort in eine perfekte Wissensstruktur überführt werden könnte. Entscheidend ist, relevante Zusammenhänge so zu pflegen, dass sie später überprüfbar und nutzbar bleiben.

Das Wiki ist also keine Wahrheitsmaschine, sondern ein Prüf- und Orientierungsinstrument.

12. Warum die konkrete Umsetzung erst im dritten Artikel kommt

Dieser zweite Artikel bleibt bewusst auf der Ebene der Übertragung. Er beschreibt noch nicht im Detail, welche Dateien ein solches Wiki haben sollte, wie ein Ingest-Prozess aussehen könnte, welche Metadaten sinnvoll wären, wie man Query-Smokes konkret formuliert oder wie ein Coding Agent diese Schicht praktisch nutzen sollte.

Vorher ist die Brücke wichtiger. Wenn das LLM-Wiki im Grundlagenartikel eine persistente Wissensschicht für verstreutes menschliches und KI-nutzbares Wissen war, dann ist der code-nahe Knowledge Layer die entsprechende Schicht für Softwareentwicklung: erklärend, überprüfbar und nah genug an den Primärquellen, um Drift sichtbar zu machen.

Nicht als Ersatz für Code, klassische Dokumentation oder Endanwenderhilfe. Sondern als Schicht, die verhindert, dass Menschen und Agenten bei jeder anspruchsvolleren Frage wieder bei null anfangen.

Der nächste Artikel müsste deshalb eine andere Frage beantworten: Wie probiert man das konkret, klein und überprüfbar aus?

Quellenverzeichnis

Interne Primärquelle

LLM-Wiki und offene Wissensformate

Software Engineering und Kontext

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top