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.
Abstract
Diese Werkstattnotiz rekonstruiert, wie sich der dokumentierte Such-, Verifikations- und Begründungspfad eines KI-gestützten Entwicklungsagenten bei verpflichtendem Einstieg über den Lutions Knowledge Layer vom direkten Repository-Einstieg unterscheidet. Verglichen wurden repo-first-Läufe, die direkt im Repository starten, und wiki-first-Läufe, die zunächst wiki/README.md, wiki/knowledge-layer-closure-index.md und passende Wiki-Seiten lesen, bevor sie Primärquellen prüfen.
Die Untersuchung ist keine kontrollierte Wirkungsstudie, kein Benchmark und kein allgemeiner Effizienznachweis. Rekonstruierbar sind neun einzigartige fachliche Aufgaben, neun nach dem vorgesehenen JSONL-Wrapper-Verfahren protokollierte Vergleichspaare, weitere frühere qualitative oder schwächer instrumentierte Vergleichspaare sowie 305 Trace-Events als reine Telemetriegröße. Die vorhandenen Daten stützen vor allem Aussagen über strukturelle Explizitheit, Quellenführung, Grenzmarkierung und Nachvollziehbarkeit des dokumentierten Prüfpfads. Sie stützen keine Aussage darüber, dass wiki-first regelmäßig schneller, kostengünstiger oder fachlich richtiger ist.
Die vorsichtige Hauptaussage lautet: In den dokumentierten Lutions-Läufen unterschied sich bei mehrschichtigen Aufgaben die Log- und Antwortstruktur, in der fachliche Ebenen, Quellenpfade und Antwortgrenzen explizit wurden. Ob diese veränderte Prüfkette regelmäßig zu richtigeren, vollständigeren, schnelleren oder kostengünstigeren Ergebnissen führt, lässt sich aus der vorhandenen Datenbasis nicht ableiten.
Ausgangspunkt und Untersuchungsgegenstand
Andrej Karpathy popularisierte 2026 die Idee eines LLM-Wikis: persistente, strukturierte und menschenlesbare Wissensseiten, die LLM-Agenten wiederverwenden können, statt Wissen nur in Chatverläufen, Prompts oder Retrieval-Chunks zu halten (Karpathy, 2026). Die neuere Diskussion um agentenorientiertes Retrieval betont ähnlich, dass Agenten nicht nur einzelne Dokumente abrufen, sondern Such-, Lese- und Begründungspfade aufbauen müssen (Ming et al., 2026).
Lutions untersucht jedoch nicht das Karpathy-Konzept in Reinform. Der Lutions Knowledge Layer übernimmt die Grundidee persistenter Markdown-Seiten, erweitert sie aber softwareentwicklungsspezifisch: Jede zentrale Wiki-Seite nennt source_of_truth, doc_sources, Status, Freshness-Risiko und Grenzen. Der Knowledge Layer ist damit keine autonome Wahrheitsquelle, sondern eine domänenspezifische Operationalisierung: Er soll Agenten und Menschen zu Code, Tests, Routen, Policies, Konfigurationen, Skripten und Prozessdokumenten führen.
Die Forschungsfrage lautet deshalb:
Wie unterscheidet sich der dokumentierte Such-, Verifikations- und Begründungspfad eines Entwicklungsagenten bei verpflichtendem Einstieg über einen code-nahen Knowledge Layer vom direkten Repository-Einstieg?
Daraus folgen fünf Teilfragen, die mit der vorhandenen Datenbasis unterschiedlich gut beantwortbar sind:
- Werden relevante fachliche Ebenen an vorgelagerter Stelle innerhalb der generierten Log- oder Antwortstruktur explizit? Diese Frage lässt sich in den instrumentierten Traces qualitativ adressieren.
- Werden maßgebliche Primärquellen an vorgelagerter Stelle innerhalb der generierten Log- oder Antwortstruktur genannt? Diese Frage lässt sich teilweise adressieren; Vollständigkeit wurde nicht gegen einen vorab definierten Goldstandard gemessen.
- Werden Grenzen und Datenabhängigkeiten an vorgelagerter Stelle innerhalb der generierten Log- oder Antwortstruktur benannt? Diese Frage lässt sich qualitativ anhand von
limits,taxonomy_checkpointund finalen Quellenlisten adressieren. - Welche Fragen der fachlichen Antwortqualität bleiben offen? Diese Frage wird nur als Grenze der Untersuchung behandelt, weil keine unabhängige, verblindete Bewertung der Endantworten anhand vorab festgelegter Kriterien erfolgte.
- Ist ein möglicher Nutzen spezifisch für den Lutions Knowledge Layer oder allgemein für kuratierte Übersichtsdokumentation? Diese Frage bleibt offen, weil kein dritter Vergleichsarm mit klassischer Dokumentation oder einfachem README durchgeführt wurde.
Die Untersuchung beantwortet damit vor allem Traceability- und Explizitheitsfragen. Fachliche Ergebnisqualität bleibt als Anschlussfrage sichtbar.
Zielkonstrukt
Die Untersuchung bewertet nicht abstrakt, ob ein Wiki “besser” ist. Das Zielkonstrukt ist strukturelle Explizitheit des Prüfpfads:
Strukturelle Explizitheit des Prüfpfads bezeichnet, in welchem Umfang Trace-Artefakte und finale Antworten erkennen lassen, welche fachlichen Ebenen, Quellenfamilien, Verifikationspunkte und Antwortgrenzen ein Agent im Lauf explizit gemacht hat und wie diese Elemente für eine spätere Rekonstruktion angeordnet sind.
Dieses Konstrukt beschreibt Nachvollziehbarkeit und Prozess-Explizitheit, nicht fachliche Richtigkeit. Es hat drei getrennte Dimensionen.
| Dimension | Worum es geht | Was nicht automatisch folgt |
|---|---|---|
| Quellenpfad | Explizite Quellenangaben, Source-of-Truth-Pfad, gelesene Wiki- und Primärquellen, finale Quellenlisten. | Eine sichtbare Quelle beweist noch nicht, dass die Antwort fachlich richtig ist. |
| Prüfpfad-Explizitheit | Position und Funktion von taxonomy_checkpoint, verification_step, limits, verworfenen Treffern und Antwortstruktur. | Mehr Trace-Events bedeuten nicht mehr Evidenz oder geringeren Aufwand. |
| Grenz- und Scope-Markierung | Dokumentierte Grenzen, Datenabhängigkeiten, Staleness-Risiken, unzulässige Einzelfallschlüsse und weitere Prüfschritte. | Gute Nachvollziehbarkeit ersetzt keine unabhängige Ergebnisbewertung. |
Die vorliegenden Traces beobachten dieses Zielkonstrukt nur ausschnittweise. Direkt rekonstruierbar sind vor allem Quellenführung, die Struktur des dokumentierten Prüfpfads, Grenzmarkierung und strukturelle Nachvollziehbarkeit. Fachliche Richtigkeit und Vollständigkeit der Endantworten wurden nicht unabhängig anhand eines vorab definierten Goldstandards gemessen. Wenn der Artikel von einem Nutzen spricht, ist daher ein Nutzen für Traceability und Prüfpfad-Explizitheit gemeint, nicht eine gemessene Verbesserung der Antwortqualität.
Methode
Untersuchungsart
Der Beitrag ist eine methodisch reflektierte Werkstattnotiz. Er rekonstruiert interne Entwicklungsagentenläufe in einer realen Softwarebasis und prüft, welche Beobachtungen daraus tragfähig sind. Er ist keine prärregistrierte Studie, keine randomisierte Evaluation, keine verblindete Antwortbewertung und kein RAG-Benchmark.
Analyseeinheiten
Die wichtigste Korrektur gegenüber einer zu schnellen Lesart lautet: Die 305 Events sind keine Stichprobe. Sie sind Telemetrie über protokollierte Such-, Lese- und Auswertungsschritte.
| Einheit | Rekonstruierter Umfang | Einordnung |
|---|---|---|
| Einzigartige fachliche Aufgaben | 9 | Release-Schnitt, Attachment-Quarantäne, Ticketliste, Parent-Completion-Guard, Import/Export, Public Portal, Workflow-Statuswechsel, Public Attachment Exposure, Import Workflow Mapping. |
| Nach dem JSONL-Wrapper-Verfahren protokollierte Läufe | 18 | 9 repo-first, 9 wiki-first. |
| Nach dem JSONL-Wrapper-Verfahren protokollierte Vergleichspaare | 9 | Je ein repo-first- und ein wiki-first-Lauf pro Aufgabe. |
| Frühere qualitative oder schwächer instrumentierte Vergleichspaare | 4 | Release, Attachment, Ticketliste, Parent-Completion-Guard vor den späteren Wrapper-Re-Runs. |
| Dokumentierte Vergleichspaare über alle Stufen | 13 | Nicht unabhängig, weil vier Aufgaben später erneut liefen. |
| Trace-Events | 305 | Reine Telemetriegröße, keine Fallzahl und kein Qualitätsmaß. |
Die 18 JSONL-Läufe verteilen sich auf 137 repo-first-Events und 168 wiki-first-Events. Nach Eventtypen sind 118 read_file, 58 read_wiki, 22 search, 22 verification_step, 18 taxonomy_checkpoint, 18 limits, 18 start, 18 end, 10 final_sources und 3 discarded_hits dokumentiert. Diese Verteilung dokumentiert vor allem, dass die wiki-first-Traces zusätzliche Wiki-Reads enthalten und dennoch Primärquellen lesen.
Vergleichsbedingungen
Verglichen wurden zwei Bedingungen.
| Bedingung | Einstieg | Prüfpflicht |
|---|---|---|
| Repo-first | Direkter Start im Repository, meist über rg-Suche und anschließende Datei-Reads. | Quellen müssen aus Code, Tests, Dokumentation und Prozessquellen rekonstruiert werden. |
| Wiki-first | Start über wiki/README.md, wiki/knowledge-layer-closure-index.md und passende Wiki-Seiten. | Wiki-Aussagen müssen anschließend gegen Primärquellen geprüft werden. |
Ein Classic-docs-first-Arm fehlt. Nicht geprüft wurde, ob ein einfaches README, eine konventionelle Architekturübersicht oder klassische kuratierte Dokumentation denselben Orientierungsnutzen erzeugt hätte. Damit bleibt offen, ob der beobachtete Effekt spezifisch für den Lutions Knowledge Layer ist oder allgemeiner aus gut gepflegter Übersichtsdokumentation entsteht.
Durchführung und rekonstruierbare Bedingungen
Die späteren Läufe entstanden am 26. und 27. Juli 2026. Die JSONL-Dateien enthalten Zeitstempel, Modus, Eventtyp, gelesene Pfade, Suchbefehle, Auszüge, Exit-Codes, Laufzeiten einzelner Suchbefehle und Hashes gelesener Dateien oder Suchausgaben. Die Trace-Werkzeuge sind scripts/aidev/trace-run-command.ps1, scripts/aidev/trace-read-file.ps1, scripts/aidev/trace-event.ps1 und scripts/aidev/trace-summary.ps1.
Nicht zuverlässig rekonstruierbar sind Modellname, Modellversion, vollständiger Systemprompt, vollständiger Aufgabenprompt, interne Modellzustände, Tokenverbrauch, vollständige Toolcall-Historie und ob jede Laufbedingung in einer vollständig frischen Sitzung begann. Die Reihenfolge war nicht randomisiert. In den JSONL-Zeitstempeln ist überwiegend repo-first vor wiki-first sichtbar; dadurch sind Carry-over- oder Lerneffekte nicht auszuschließen. Die Trace-Artefakte wurden später gemeinsam in Git festgehalten; der exakte Commit-Hash des Laufzeitstands ist nicht in den Traces selbst gespeichert.
Kontaminationsrisiken
Die Läufe dürfen nicht als unabhängige Replikationen gelesen werden. Mögliche Kontaminationen sind:
- Der zweite Lauf eines Vergleichspaars konnte implizit von Vorwissen aus dem ersten profitieren.
- Frühere qualitative Läufe beeinflussten die spätere Auswahl und Instrumentierung.
- Wiki und Repository lagen im selben Arbeitsbaum; repo-first schloss Wiki-Dateien in den protokollierten Suchbefehlen teilweise aus, aber eine absolute Trennung der Wissensumgebung ist nicht nachgewiesen.
- Der Knowledge Layer wurde im Projektverlauf gepflegt; ob Ergebnisse früherer repo-first-Läufe in späteren Wiki-Stand eingeflossen sind, lässt sich aus den Artefakten nicht vollständig ausschließen.
- Die Endantworten wurden nicht anonymisiert und nicht unabhängig blind bewertet.
Operationalisierung
Mit den vorhandenen Traces lassen sich die Begriffe nur vorsichtig operationalisieren.
Vorgelagerte Position in der generierten Log- oder Antwortstruktur bedeutet in dieser Auswertung: Eine fachliche Ebene, Quelle oder Grenze erscheint weiter oben beziehungsweise vor anderen relevanten Elementen in der dokumentierten Ereignisfolge, Trace-Summary oder finalen Antwort als im Vergleichspfad, etwa in read_wiki, taxonomy_checkpoint, limits, verification_step oder final_sources. Das ist eine strukturelle und narrative Eigenschaft des Artefakts. Sie misst keine Sekunden, Tokens, Suchkosten, kognitive Modellschritte oder tatsächliche Arbeitsgeschwindigkeit.
Suchrauschen wird nicht quantitativ ausgewertet. Die Traces enthalten nur drei explizite discarded_hits-Events; das reicht nicht für einen belastbaren Vergleich. Suchrauschen bleibt daher eine qualitative Beobachtung, wenn breite Suchausgaben, viele verwandte Trefferfamilien oder ausdrücklich verworfene Quellen sichtbar sind.
Grenzerkennung umfasst vier Dinge: das Benennen fehlender Runtime- oder Datenbankdaten, das Vermeiden unzulässiger Einzelfallentscheidungen, das Markieren von Staleness-Risiken und das Offenlegen zusätzlicher notwendiger Prüfschritte.
Bewertungsverfahren
Die Auswertung ist qualitativ und fallbezogen. Bewertet wurde nicht eine abstrakte Punktzahl und nicht die fachliche Güte der Endantwort, sondern ob die finalen Antworten und Traces die maßgeblichen Ebenen, Primärquellen, Gegenbedingungen und Grenzen explizit rekonstruierbar machen. Für eine stärkere Studie zur Antwortqualität wäre vor jedem Lauf eine Goldstandard-Checkliste nötig; in der vorliegenden Untersuchung wurden diese Checklisten nachträglich aus Trace-Summaries, Evidence Appendix und Source-of-Truth-Dateien rekonstruiert. Das ist transparent, aber schwächer als eine vorab festgelegte Bewertung.
Ergebnis- und Bewertungsmatrix
| Fall | Direkte Beobachtung | Unterschied zwischen Pfaden | Interpretation für die Antwortstruktur | Einschränkung |
|---|---|---|---|---|
| Release-Schnitt-Pflichten | Beide Pfade fanden AGENTS.md, Release-Prozess, Release-Steward-Logik und Skriptquellen. | Im wiki-first-Trace wurde die Governance-Kette weiter oben in der rekonstruierten Log-Struktur gerahmt; repo-first rekonstruierte sie aus breiter Suche. | Gleicher Endbefund; Unterschied vor allem in der Struktur des dokumentierten Prüfpfads und der Nachvollziehbarkeit. | Kein Nachweis für schnellere oder richtigere Antwort. |
| Quarantäne-Attachment-Freigabe | Beide Pfade fanden UI, Controller, Policy, Token-Scope und Tests. | Im wiki-first-Trace wurden UI-Sichtbarkeit, Backend-Autorisierung, Token-Scope und Public-Grenze weiter oben in der Trace-Summary getrennt dokumentiert. | Die dokumentierte Prüfkette macht diese Ebenen explizit unterscheidbar. | Ob dadurch weniger falsche Endantworten entstehen, wurde nicht unabhängig bewertet. |
| Ticketliste, Suche, Filter und Sichtbarkeit | Beide Pfade identifizierten Frontend, Serveradapter, Query, Filter, Saved Filters, Sortierung und Pagination. | Im wiki-first-Trace wurde die Sichtbarkeitstaxonomie aus Projektkontext, Suche, Filter, Query-Ausdruck, Sortierung und Pagination weiter oben in der Antwortstruktur bereitgestellt. | Die dokumentierte Antwortstruktur enthält eine vorgelagerte mehrstufige Sichtbarkeitsordnung. | Kein Classic-docs-Vergleich; keine unabhängige Qualitätsbewertung. |
| Parent-Completion-Guard | Repo-first fand über hierarchy_parent_open_children sehr direkt die Kernquellen. | Im wiki-first-Trace erschienen Fehlercode-, Statuswechsel- und Supporteinordnung weiter oben in der dokumentierten Prüfkette, aber nicht der Kernquellenfund. | Der Fall dokumentiert einen klaren repo-first-Vorteil beim Quellenfund über präzisen Fehlercode. | Begrenzender Gegenfall zur Prozesshypothese. |
| Import/Export | Beide Pfade fanden Session-Grenzen, Controller, Paketvalidierung, Downloadrechte und Datenschutzgrenzen. | Im wiki-first-Trace wurde weiter oben in der Log-Struktur markiert, dass issues:read für bestimmte Import-/Export-Routen wegen Session-Kontext nicht genügt. | Die API-/Session-/Permission-Grenze steht im wiki-first-Pfad strukturell im Vordergrund. | Wiki-Seiten mit Staleness-Risiko bleiben prüfpflichtig. |
| Public Portal | Beide Pfade fanden Settings, is_public, public_slug, öffentliche Routen und UI. | Im wiki-first-Trace wurden interne Sichtbarkeit, öffentliche Lesbarkeit, Submission, Approval, Attachments und Nicht-Ziele weiter oben getrennt dokumentiert. | Die Prüfkette ist strukturell inspizierbarer, weil die Sichtbarkeitsebenen explizit getrennt sind. | Keine empirische Bewertung menschlicher Reviewer; konkrete Freigabe bleibt Policy- und Datenfrage. |
| Workflow-Statuswechsel | Beide Pfade endeten als Diagnosematrix statt Einzelfallentscheidung. | Im wiki-first-Trace erschienen Workflow-Konfiguration, Guards, API-Fehlerpfade und Datenabhängigkeit weiter oben in der dokumentierten Prüfkette. | Kein nachweisbarer Unterschied in finaler Eindeutigkeit; beide bleiben datenabhängig. | Runtime-/DB-Zustand fehlt. |
| Public Attachment Exposure | Beide Pfade fanden relevante Quellen; repo-first musste viele Public-/Attachment-Treffer sortieren. | Im wiki-first-Trace wurden Projekt, Issue, Attachment, Quarantäne, Approval und Security Settings weiter oben in der Log-/Antwortstruktur als getrennte Prüfschichten sichtbar. | Die dokumentierte Antwortstruktur enthält mehr explizit getrennte Prüfschichten. | Ob dadurch Fehlannahmen vermieden werden, bleibt Hypothese; Einzelfallursache ohne konkrete Flags und Status offen. |
| Import Workflow Mapping | Beide Pfade rekonstruierten Importvalidierung, Importausführung, Projektmapping und Workflow-Konflikte. | Im wiki-first-Trace wurden Import/Export- und Workflow-Fragefamilien strukturell vorgelagert kombiniert. | Die Ursachenmatrix trennt Paketvalidierung, Ausführung, Zielprojekt und spätere Workflow-Konflikte explizit. | Keine automatische Einzelfallentscheidung; konkretes Paket, Zielprojekt und Workflow-Daten fehlen. |
Die Matrix zeigt ein differenziertes Bild. Beobachtbar ist vor allem, dass die wiki-first-Traces in mehreren Fällen Berechtigung, Session, Public Exposure, Workflow, Import, Approval oder Quarantäne weiter oben in der generierten Log- oder Antwortstruktur als getrennte Ebenen auswiesen. In den repo-first-Traces blieb der Quellenfund direkt, sobald ein präziser Fehlercode, Routenname oder Symbolanker vorhanden war.
Einordnung zur Literatur
Die RAG-Evaluationsliteratur ist für diese Untersuchung nur begrenzt anschlussfähig. RAGAS und neuere Surveys betonen Dimensionen wie Faithfulness, Context Relevance, Antwortgenauigkeit und Kontextqualität (Es et al., 2023; Yu et al., 2024; Gan et al., 2025). Die Lutions-Daten wenden diese Metriken nicht an. Der Bezug bleibt deshalb konzeptionell: Auch hier geht es um die Frage, ob eine Antwort aus überprüfbaren, relevanten Quellen entsteht.
Methodisch näher liegt das Paradigma der Agent Trajectories. Chain-of-Thought-Prompting machte Zwischenbegründungen als explizite Textsequenzen sichtbar, allerdings zunächst vor allem für reasoning-lastige Aufgaben ohne externe Toolumgebung (Wei et al., 2022). ReAct führte anschließend Reasoning- und Acting-Schritte zusammen: Sprachmodelle erzeugen dabei verschränkte Sequenzen aus Begründung, Aktion und Beobachtung, sodass sich ein Aufgabenpfad nicht nur über die Endantwort, sondern über seine Zwischenstationen beschreiben lässt (Yao et al., 2023). Für die Lutions-Werkstattnotiz ist daran nicht die Leistungsbehauptung dieser Verfahren entscheidend, sondern die methodische Idee, Agentenläufe als Trajektorien aus Such-, Lese-, Prüf- und Begrenzungsschritten zu betrachten.
Die Lutions-Traces sind dennoch schwächer als eine vollständige Agent-Trajectory-Evaluation. Sie enthalten gelesene Dateien, Suchbefehle, Wiki-Reads, einzelne Verifikations- und Grenzmarker sowie finale Quellenlisten, aber keine vollständige Chain-of-Thought, keine vollständig rekonstruierte Toolcall-Historie und keine verblindete Bewertung der Trajektorienqualität. Der Artikel ordnet sich deshalb nicht als CoT- oder ReAct-Evaluation ein, sondern als praxisnahe Traceability-Rekonstruktion: Sichtbar wird, welche Quellen- und Prüfschichten in den Artefakten explizit auftauchen und wie sie im erzeugten Log- und Antwortmaterial angeordnet sind.
Ergänzend liegen Arbeiten zu Program Comprehension, Information Foraging und Traceability nahe. Ko et al. zeigen, dass Entwickler bei Wartungsaufgaben Informationen suchen, in Beziehung setzen und sammeln müssen, um unbekannten Code zu verstehen (Ko et al., 2006). Fleming et al. übertragen Information Foraging auf Debugging-, Refactoring- und Wiederverwendungsaufgaben und betonen, dass Werkzeuge Informationsspuren und Suchkosten verändern (Fleming et al., 2013). Traceability-Forschung beschreibt, dass Nachvollziehbarkeit in Softwareprojekten wichtig, aber oft schwer dauerhaft zu erhalten ist (Cleland-Huang et al., 2014). Für Lutions heißt das: Der Knowledge Layer ist weniger als “Retrieval-Verbesserung” interessant, sondern als verlinkte Orientierungs- und Provenienzschicht zwischen Aufgabe, Wiki, Code, Tests und Antwort.
Auch Literatur zu agiler Dokumentation erinnert daran, dass Dokumentation selektiv, aktuell und für reale Arbeitsfragen nützlich sein muss, statt als vollständiger Parallelbestand zum Code zu wachsen (Islam et al., 2023). Das passt zur Lutions-Ausprägung: Das Wiki soll nicht mehr Dokumentation um ihrer selbst willen erzeugen, sondern Suchpfade, Grenzen und Source-of-Truth-Verweise sichtbar machen.
Geltungsbereich, Validitätsgrenzen und offene Prüfungen
Der Geltungsbereich ist eng. Alle Fälle stammen aus einem Repository, einer Prozesskultur, einem Agentensetup und einem spezifischen Knowledge-Layer-Design. Externe Leser können die Argumentation nachvollziehen, sofern Artikel, Datenanhang und anonymisierte Trace-Summaries zugänglich sind. Vollständig replizierbar ist die Untersuchung damit nicht, weil interne Tickets, Rohkontexte, konkrete Agentensitzungen und Runtime-Zustände nicht vollständig öffentlich oder rekonstruierbar sind.
Die wichtigsten Grenzen sind:
- keine Randomisierung, keine Verblindung und keine unabhängige Replikation;
- kein Classic-docs-first-Vergleichsarm;
- keine gesicherte Modell- oder Promptkonfiguration;
- keine vollständige Toolcall-Telemetrie und keine vollständige Agent-Trajectory-Aufzeichnung im Sinne von ReAct- oder Chain-of-Thought-Evaluationen;
- keine Token-, Kosten- oder Laufzeitbewertung;
- nur qualitative Operationalisierung von vorgelagerten Positionen innerhalb der generierten Log- oder Antwortstruktur;
- kein zuverlässiges quantitatives Maß für Suchrauschen;
- keine konkreten Runtime-/DB-Snapshots für datenabhängige Fälle;
- mögliche Carry-over-Effekte zwischen Läufen;
- Tautologie-Risiko, weil Taxonomie, Quellenführung und Grenzmarkierung genau die Konstruktionsmerkmale des Wikis sind.
Eine kleine methodisch sauberere Folgestufe wäre mit vertretbarem Aufwand möglich, wenn sie vorab festgelegt wird. Sie sollte einen eingefrorenen Repository- und Wiki-Stand verwenden, je Lauf eine frische Sitzung starten, die Reihenfolge balancieren, Prompts dokumentieren und drei Bedingungen vergleichen: repo-first, classic-docs-first und wiki-first. Eine sinnvolle Aufgabenliste wären sechs Fälle: ein präziser Fehlercode, eine subsystemübergreifende Diagnose, eine Berechtigungsfrage, eine Prozessfrage, eine datenabhängige Frage und ein schwach dokumentierter Wiki-Bereich.
Vor jedem Lauf müsste eine kurze Goldstandard-Checkliste stehen: obligatorische Ebenen, maßgebliche Primärquellen, Gegenbedingungen, unzulässige Verkürzungen, Datenabhängigkeiten und zulässige Schlussfolgerung. Danach könnten Endantworten zunächst ohne sichtbare Pfadzuordnung bewertet werden. Auch dann wären keine Signifikanztests angemessen; zulässig wären nur deskriptive Angaben, etwa wie oft obligatorische Ebenen, Primärquellen und korrekte Grenzen genannt wurden.
Schlussfolgerung
Ein code-naher Knowledge Layer verbessert nicht automatisch die Antwort. In den vorhandenen Lutions-Gegenproben unterscheidet sich vor allem die dokumentierte Prüfkette.
Bei lokalen Codefragen mit starkem Suchanker bleibt repo-first im beobachteten Quellenfund sehr direkt. Der Parent-Completion-Guard ist dafür das beste Gegenbeispiel: Ein präziser Fehlercode führte im repo-first-Trace direkt zu den relevanten Quellen. Der wiki-first-Trace dokumentierte dort eher Diagnose- und Supporteinordnung als einen Dateifund an vorgelagerter Stelle der Log-Struktur.
Bei mehrschichtigen Fragen unterscheiden sich die protokollierten Pfade deutlicher. In Public Portal, Import/Export, Public Attachment Exposure und Import Workflow Mapping enthalten die wiki-first-Traces fachliche Ebenen und Grenzen weiter oben in der generierten Log- oder Antwortstruktur. Das ist kein Beweis für höhere Richtigkeit. Beobachtbar ist nur, dass die protokollierten Pfade zusätzliche Prüfschichten und Grenzen strukturell vorgelagert ausweisen und dadurch eine explizitere Prüfkette hinterlassen.
Aus der Werkstattnotiz ergeben sich zwei getrennte Hypothesen:
H1: Der Knowledge-Layer-Arm unterscheidet sich bei mehrschichtigen Aufgaben im dokumentierten Such- und Prüfpfad. Fachliche Ebenen, Quellenfamilien und Antwortgrenzen werden im Trace strukturell vorgelagert oder expliziter sichtbar.
H2: Diese veränderte Prüfkette führt häufiger zu quellengetreuen, vollständig begrenzten und fachlich richtigen Endantworten.
Die vorliegende Werkstattnotiz stützt nur H1 vorläufig und qualitativ. Die rekonstruierten Traces zeigen Unterschiede in den dokumentierten Prüfpfaden, können aber nicht zeigen, ob derselbe Agent unter identischen Bedingungen ohne Knowledge Layer dieselbe Struktur ebenfalls erzeugt hätte. H2 bleibt Anschlussfrage, weil Ergebnisqualität nicht unabhängig, verblindet und anhand eines vorab definierten Goldstandards bewertet wurde. H1 wäre in einer Folgestufe weiter gestützt, wenn wiki-first oder ein Knowledge-Layer-Arm bei mehrschichtigen Aufgaben häufiger obligatorische Ebenen, relevante Primärquellen und Antwortgrenzen explizit dokumentiert als repo-first und classic-docs-first. H2 wäre erst gestützt, wenn diese veränderte Prüfkette zugleich häufiger quellengetreue und korrekt begrenzte Endantworten erzeugt, ohne mehr unbelegte oder falsche Aussagen zu produzieren. Beide Hypothesen wären nicht entschieden, wenn alle drei Arme ähnliche Pfade und Antworten liefern. H1 wäre vorläufig widerlegt, wenn wiki-first bei komplexeren Fällen keine strukturell vorgelagerte Grenzmarkierung oder Quellenführung in der generierten Log- oder Antwortstruktur zeigt. Wenn ein einfacher README-Arm denselben Prozessnutzen erzeugt, läge der Wert nicht im Lutions-Wiki-Konzept selbst, sondern allgemeiner in kuratierter Übersichtsdokumentation.
Quellenverzeichnis
Primärartikel dieser Reihe
- Hermanns, Christoph (2026a). Das LLM-Wiki: Persistentes Wissen für Menschen und KI-Agenten.
- Hermanns, Christoph (2026b). Vom LLM-Wiki zum code-nahen Knowledge Layer.
- Hermanns, Christoph (2026c). Vom LLM-Wiki zum operativen Knowledge Layer.
Externe Referenzen
- Karpathy, Andrej (2026). LLM Wiki.
https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f - Ming et al. (2026). Retrieval as Reasoning: Self-Evolving Agent-Native Retrieval via LLM-Wiki. arXiv.
https://arxiv.org/abs/2605.25480 - Wei, Jason; Wang, Xuezhi; Schuurmans, Dale; Bosma, Maarten; Ichter, Brian; Xia, Fei; Chi, Ed; Le, Quoc; Zhou, Denny (2022). Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS.
https://arxiv.org/abs/2201.11903 - Yao, Shunyu; Zhao, Jeffrey; Yu, Dian; Du, Nan; Shafran, Izhak; Narasimhan, Karthik; Cao, Yuan (2023). ReAct: Synergizing Reasoning and Acting in Language Models. ICLR.
https://arxiv.org/abs/2210.03629 - Es et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv.
https://arxiv.org/abs/2309.15217 - Yu et al. (2024). Evaluation of Retrieval-Augmented Generation: A Survey. arXiv.
https://arxiv.org/abs/2405.07437 - Gan et al. (2025). Retrieval Augmented Generation Evaluation in the Era of Large Language Models: A Comprehensive Survey. arXiv.
https://arxiv.org/abs/2504.14891 - Ko, Andrew J.; Myers, Brad A.; Coblenz, Michael J.; Aung, Htet Htet (2006). An Exploratory Study of How Developers Seek, Relate, and Collect Relevant Information during Software Maintenance Tasks. IEEE Transactions on Software Engineering.
https://faculty.washington.edu/ajko/papers/Ko2006SeekRelateCollect.pdf - Fleming, Scott D.; Scaffidi, Chris; Piorkowski, David; Burnett, Margaret; Bellamy, Rachel; Lawrance, Joseph (2013). An Information Foraging Theory Perspective on Tools for Debugging, Refactoring, and Reuse Tasks. ACM Transactions on Software Engineering and Methodology.
https://doi.org/10.1145/2430545.2430551 - Cleland-Huang, Jane; Gotel, Orlena C. Z.; Huffman Hayes, Jane; Mäder, Patrick; Zisman, Andrea (2014). Software Traceability: Trends and Future Directions. Future of Software Engineering.
https://doi.org/10.1145/2593882.2593891 - Islam, Md Athikul; Hasan, Rizbanul; Eisty, Nasir U. (2023). Documentation Practices in Agile Software Development: A Systematic Literature Review. arXiv.
https://arxiv.org/abs/2304.07482
Interne Lutions-Auswertungsquellen
- Lutions (2026a). AIDEV-178: Beobachtungskriterien für Zwei-Pfade-Vergleiche mit und ohne LLM-Wiki.
AIDEV-178 - Lutions (2026b). AIDEV-185: Gegenprobe LLM-Wiki vs. Repo-first auswerten.
AIDEV-185 - Lutions (2026c). AIDEV-186/AIDEV-187: Zwei-Pfade-Durchlauf zu Release-Schnitt-Pflichten.
AIDEV-186;AIDEV-187 - Lutions (2026d). AIDEV-188/AIDEV-189: Zwei-Pfade-Durchlauf zu Quarantäne-Attachment-Freigabe.
AIDEV-188;AIDEV-189 - Lutions (2026e). AIDEV-190 bis AIDEV-195: Vorläufe zu Ticketliste und Parent-Completion-Guard.
AIDEV-190;AIDEV-191;AIDEV-192;AIDEV-193;AIDEV-194;AIDEV-195 - Lutions (2026f). AIDEV-198/AIDEV-199 bis AIDEV-206: Instrumentierter Re-Run der vier LLM-Wiki-Gegenproben.
AIDEV-198;AIDEV-199;AIDEV-200;AIDEV-201;AIDEV-202;AIDEV-203;AIDEV-204;AIDEV-205;AIDEV-206;docs/aidev/traces/LLM-Wiki/AIDEV-198-instrumented-rerun-comparison.md - Lutions (2026g). AIDEV-208/AIDEV-209 bis AIDEV-214: Komplexere LLM-Wiki-Gegenproben.
AIDEV-208;AIDEV-209;AIDEV-210;AIDEV-211;AIDEV-212;AIDEV-213;AIDEV-214;docs/aidev/traces/LLM-Wiki/AIDEV-208-complex-cases-comparison.md - Lutions (2026h). AIDEV-215/AIDEV-216 bis AIDEV-219: Sehr komplexe LLM-Wiki-Gegenproben.
AIDEV-215;AIDEV-216;AIDEV-217;AIDEV-218;AIDEV-219;docs/aidev/traces/LLM-Wiki/AIDEV-215-deep-complex-cases-comparison.md - Lutions (2026i). Trace-Werkzeuge für instrumentierte Agentenpfade.
scripts/aidev/trace-run-command.ps1;scripts/aidev/trace-read-file.ps1;scripts/aidev/trace-event.ps1;scripts/aidev/trace-summary.ps1 - Lutions (2026j). Datenanhang: LLM-Wiki-Gegenproben in Lutions.
docs/aidev/traces/LLM-Wiki/llm-wiki-evidence-appendix.md - Lutions (2026k). Lutions Knowledge Layer Root und Closure Index.
wiki/README.md;wiki/knowledge-layer-closure-index.md