Die ersten drei Beiträge dieser Serie beschrieben eine Bewegung vom Pattern zur Umsetzung. Der Grundlagenbeitrag führte das LLM-Wiki als persistente Wissensschicht zwischen Rohquellen und späteren Fragen ein und schloss damit an Karpathys LLM-Wiki-Pattern an (Karpathy, 2026; Hermanns, 2026a). Der zweite Beitrag übertrug dieses Pattern auf Softwareentwicklung und beschrieb den code-nahen Knowledge Layer als Orientierungsschicht über Code, Tests, Tickets, Reviews und Betriebswissen (Hermanns, 2026b). Der dritte Beitrag zeigte, wie Lutions diese Idee praktisch umgesetzt hat: mit Root-Einstieg, Closure Index, Wiki-Seiten, Quellenführung, Query-Smokes, Refresh-Reports und dokumentierten Pflegeentscheidungen (Hermanns, 2026c).
Dieser vierte Beitrag fragt nun, was davon in ersten Praxistests sichtbar wird. Die Frage ist bewusst kleiner als ein Wirksamkeitsversprechen. Es geht nicht darum, ob der Knowledge Layer Agenten bereits schneller, günstiger oder fachlich besser macht. Es geht zunächst darum, ob sich in dokumentierten Agentenläufen andere Prüfpfade zeigen: Werden Quellen früher sichtbar? Werden fachliche Ebenen klarer getrennt? Werden Grenzen der Antwort besser markiert? Und wo bleibt der wiki-first Einstieg ohne belegbaren Vorteil?
Die zentrale Beobachtung lautet: In den ersten Lutions-Gegenproben verändert der Knowledge Layer vor allem die Sichtbarkeit des Prüfpfads. Bei mehrschichtigen Aufgaben treten Quellenfamilien, fachliche Ebenen und Antwortgrenzen im wiki-first Pfad häufiger früh und explizit hervor. Bei lokalen Codefragen mit präzisem Suchanker bleibt repo-first dagegen sehr direkt. Aus diesen Daten folgt noch kein Nachweis für bessere Endantworten.
Der Artikel beschreibt deshalb zuerst, was geprüft wurde und wie die Gegenproben aufgebaut waren. Danach fasst er die wichtigsten Beobachtungen zusammen, ordnet die Grenzen der Datenbasis ein und leitet daraus ab, welche nächste Prüfstufe nötig wäre.
1. Was geprüft wurde
Die Gegenproben vergleichen zwei Arbeitsweisen in derselben Lutions-Codebasis. Im repo-first Pfad startet der Agent direkt im Repository, typischerweise über Suche und anschließende Datei-Reads. Im wiki-first Pfad startet der Agent im Knowledge Layer: zuerst im Root-Einstieg, dann im Closure Index und anschließend in passenden Wiki-Seiten. Danach muss auch dieser Pfad gegen Primärquellen zurückprüfen.
Ein dritter denkbarer Pfad wäre classic-docs-first. Damit ist ein Einstieg über klassische Dokumentation gemeint: README-Dateien, Architekturüberblicke, Runbooks, Supportnotizen oder andere kuratierte Projekttexte, die nicht nach dem LLM-Wiki-Pattern mit source_of_truth, Freshness-Signalen, Closure Index und Query-Smokes organisiert sind. Dieser Pfad wurde in den ersten Gegenproben nicht ausgeführt, ist aber methodisch wichtig. Nur mit ihm ließe sich später prüfen, ob beobachtete Orientierungsvorteile spezifisch am Lutions Knowledge Layer liegen oder allgemeiner an guter Übersichtsdokumentation.
Damit passt die Untersuchung direkt an den dritten Beitrag an. Dort wurde der Lutions Knowledge Layer als Orientierungsschicht beschrieben, nicht als Wahrheitsschicht. Die Gegenproben fragen nun, ob diese Orientierungsschicht in realen Agentenläufen Spuren hinterlässt.
Untersucht wurden neun fachliche Aufgaben mit jeweils einem repo-first und einem wiki-first Lauf. Sie wurden ausgewählt, weil sie unterschiedliche Fragetypen abdecken: lokale Suchanker, mehrschichtige Diagnosefälle, Security- und Permission-Fragen, Workflow-Logik sowie Release- und Prozessfragen. Konkret ging es um Release-Schnitt, Attachment-Quarantäne, Ticketliste, Parent-Completion-Guard, Import/Export, Public Portal, Workflow-Statuswechsel, Public Attachment Exposure und Import Workflow Mapping. Zusätzlich lagen frühere qualitative Vergleichspaare aus Vorläufen vor.
Die wichtigsten Einheiten waren:
| Einheit | Umfang | Einordnung |
|---|---|---|
| Fachliche Aufgaben | 9 | Unterschiedliche Wartungs-, Diagnose-, Security-, Workflow- und Release-Fragen |
| Instrumentierte Läufe | 18 | Je 9 repo-first und 9 wiki-first Läufe |
| Vergleichspaare | 9 | Pro Aufgabe ein Vergleichspaar |
| Trace-Events | 305 | Telemetrie über sichtbare Such-, Lese- und Prüfereignisse |
| Frühere qualitative Vergleichspaare | 4 | Vorläufe, nicht unabhängig von den späteren Re-Runs |
Die 305 Trace-Events sind keine Stichprobe im statistischen Sinn. Sie sind Telemetrie. Sie zeigen, welche Dateien gelesen wurden, welche Wiki-Seiten im Lauf auftauchten, welche Suchbefehle ausgeführt wurden und welche Prüfschritte oder Grenzen explizit dokumentiert wurden.
2. Wie geprüft wurde
Die Gegenproben waren eine Werkstattnotiz, keine kontrollierte Studie. Das ist wichtig, weil der Befund sonst schnell zu stark gelesen würde. Es gab keine Randomisierung, keine verblindete Bewertung, keinen unabhängigen Goldstandard vor jedem Lauf und keine vollständige Rekonstruktion interner Modellzustände.
Auswertbar war nur, was in den erzeugten Artefakten sichtbar wurde: Suchbefehle, gelesene Dateien, Wiki-Reads, einzelne Trace-Marker, Trace-Summaries und finale Quellenlisten. Ein Trace-Ereignis kann zum Beispiel festhalten, dass eine Wiki-Seite gelesen, eine Policy-Datei geprüft, ein Suchtreffer verworfen oder eine Antwortgrenze markiert wurde. Damit misst die Untersuchung nicht, was das Modell intern gedacht hat. Sie rekonstruiert nur, welche Such-, Lese-, Prüf- und Begrenzungsschritte im Lauf sichtbar wurden.
Das Zielkonstrukt war deshalb strukturelle Explizitheit des Prüfpfads. Gemeint ist: Lassen Trace-Artefakte und finale Antworten erkennen, welche fachlichen Ebenen, Quellen, Prüfschritte und Antwortgrenzen ein Agent sichtbar gemacht hat?
Wenn der Artikel davon spricht, dass etwas “früher sichtbar” wurde, meint das keine gemessene Denk- oder Laufzeit. Gemeint ist: Eine Quelle, Grenze oder fachliche Ebene erscheint im dokumentierten Trace oder in der finalen Antwort weiter vorne, klarer getrennt oder als eigener Prüfschritt.
Drei Dimensionen waren dafür besonders wichtig:
| Dimension | Beobachtbare Frage | Grenze |
|---|---|---|
| Quellenpfad | Welche Wiki-Seiten, Primärquellen und finalen Quellenlisten werden sichtbar? | Eine sichtbare Quelle beweist noch keine fachlich richtige Antwort. |
| Prüfpfad | Werden fachliche Ebenen, Prüfschritte und verworfene Treffer nachvollziehbar? | Mehr Trace-Events bedeuten nicht automatisch mehr Qualität. |
| Grenzen und Scope | Werden Datenabhängigkeiten, Staleness-Risiken und notwendige Folgeprüfungen benannt? | Gute Grenzmarkierung ersetzt keine unabhängige Bewertung der Endantwort. |
Die späteren Läufe entstanden am 26. und 27. Juli 2026. Die Trace-Werkzeuge protokollierten unter anderem Dateilesevorgänge, Wiki-Reads, Suchbefehle, einzelne Verifikationsschritte und finale Quellenlisten. Nicht zuverlässig rekonstruierbar blieben Modellversion, vollständiger Aufgabenprompt, Tokenverbrauch, vollständige Toolcall-Historie und vollständige Frische der Sitzung.
Die wichtigste methodische Grenze lautet daher: Die Gegenproben können zeigen, wie sichtbar ein Prüfpfad wurde. Sie können nicht belegen, dass eine Antwort dadurch regelmäßig richtiger, vollständiger, schneller oder günstiger wurde.
3. Was die Gegenproben zeigen
Das Ergebnis ist gemischt und gerade deshalb nützlich. Der wiki-first Einstieg half nicht in jedem Fall. Er war vor allem dort sichtbar, wo eine Aufgabe mehrere fachliche Ebenen verband: Berechtigungen, Session-Kontext, Public Exposure, Workflow-Konfiguration, Importlogik, Approval-Status oder Quarantäne.
Bei solchen mehrschichtigen Fragen markierten die wiki-first Läufe häufiger früh, welche Ebenen getrennt betrachtet werden müssen. Das zeigte sich zum Beispiel bei Public Portal, Import/Export, Public Attachment Exposure und Import Workflow Mapping. Dort wurden Projekt, Issue, Attachment, Freigabe, Quarantäne, Session-Kontext, Workflow und Security Settings in den dokumentierten Pfaden stärker auseinandergezogen.
Das bedeutet nicht, dass der Agent automatisch besser antwortete. Beobachtbar war zunächst nur eine andere Ordnung des Prüfpfads: Der Lauf zeigte früher, welche Fragen nicht aus einer einzigen Datei beantwortet werden können und welche Primärquellen oder Runtime-Daten zusätzlich nötig wären.
Bei lokalen Codefragen mit starkem Suchanker sah es anders aus. Der Parent-Completion-Guard ist der wichtigste Gegenfall. Dort führte ein präziser Fehlercode im repo-first Lauf sehr direkt zu den relevanten Quellen. Der wiki-first Pfad brachte zusätzliche Diagnose- und Supporteinordnung, aber keinen klar früheren Kernquellenfund.
Die Ergebnislage lässt sich deshalb knapp zusammenfassen:
| Fallgruppe | Beobachtung | Einordnung |
|---|---|---|
| Mehrschichtige Diagnosefragen | Wiki-first trennte fachliche Ebenen und Grenzen sichtbarer. | Hinweis auf besseren Prüfpfad, kein Qualitätsbeweis. |
| Fragen mit präzisem Fehlercode oder Symbolanker | Repo-first fand Kernquellen sehr direkt. | Wiki-first kann hier Zusatzkontext liefern, ist aber nicht zwingend schneller oder direkter. |
| Datenabhängige Fälle | Beide Pfade blieben auf Runtime-, Projekt- oder Statusdaten angewiesen. | Der Knowledge Layer kann Grenzen markieren, aber keine fehlenden Daten ersetzen. |
| Release- und Prozessfragen | Wiki-first rahmte Governance- und Prozessketten früher. | Nützlich für Nachvollziehbarkeit, aber nicht automatisch für Ergebnisqualität. |
Abbildung 1 fasst diesen Befund zusammen: repo-first bleibt stark bei präzisen Suchankern, wiki-first macht bei mehrschichtigen Aufgaben Prüfpfade sichtbarer, und die entscheidenden Qualitätsfragen bleiben offen.
Aus Sicht des Lutions-Betriebs ist das ein ernüchternder, aber brauchbarer Befund. Der Knowledge Layer ist kein magischer Beschleuniger. Er wirkt eher wie eine strukturierte Orientierungsschicht, die bestimmte Prüffragen früher sichtbar macht.
4. Was daraus noch nicht folgt
Die Gegenproben stützen keine starke Wirksamkeitsbehauptung. Es wäre zu viel gesagt, dass wiki-first bereits bessere Endantworten erzeugt. Dafür fehlen mehrere Dinge: vorab definierte Goldstandard-Checklisten, unabhängige Antwortbewertungen, balancierte Reihenfolge, vollständig frische Sitzungen, dokumentierte Modell- und Promptkonfigurationen und ein Vergleichsarm mit klassischer Dokumentation.
Gerade der fehlende classic-docs-first Arm ist wichtig. Die Gegenproben zeigen nicht, ob der Effekt spezifisch aus dem Lutions Knowledge Layer entsteht oder allgemeiner aus gut gepflegter Übersichtsdokumentation. Ein einfaches README, eine Architekturübersicht oder eine klassische Supportmatrix könnten bei manchen Aufgaben ähnlich orientierend wirken.
Auch das Suchrauschen wurde nur qualitativ sichtbar. Einige Läufe dokumentierten verworfene Trefferfamilien, etwa bei generischen Begriffen wie public, workflow oder export. Daraus lässt sich aber kein belastbares Maß ableiten, wie viel Sortieraufwand tatsächlich entstand.
Eine weitere Grenze betrifft Carry-over-Effekte. Die Läufe waren nicht vollständig unabhängig. Wenn ein repo-first Lauf vor einem wiki-first Lauf stattfand, konnte der zweite Lauf implizit von bereits aufgebautem Kontext profitieren. Umgekehrt konnte auch der gepflegte Knowledge Layer selbst Spuren früherer Arbeit enthalten. Für eine Werkstattnotiz ist das akzeptabel, für eine Wirkungsstudie nicht.
Die vorsichtige Interpretation lautet daher: Die vorliegenden Daten zeigen, dass der wiki-first Pfad in mehreren komplexeren Fällen einen sichtbareren Prüfpfad erzeugte. Sie zeigen nicht, dass dieser Pfad regelmäßig bessere Antworten produziert.
5. Einordnung gegenüber verwandten Bewertungsansätzen
Die RAG-Evaluationsliteratur hilft nur teilweise. RAGAS und neuere Surveys betrachten Größen wie Faithfulness, Context Relevance, Antwortgenauigkeit und Kontextqualität (Es et al., 2023; Yu et al., 2024; Gan et al., 2025). Die neuere Diskussion um agentenorientiertes Retrieval betont zusätzlich, dass Agenten Such-, Lese- und Begründungspfade aufbauen müssen, statt nur einzelne Dokumente abzurufen (Ming et al., 2026). Die Lutions-Gegenproben messen diese Größen nicht direkt. Sie bleiben näher an der Frage, ob eine Antwort aus sichtbaren, prüfbaren und relevanten Quellen entsteht.
Methodisch näher liegt der Blick auf Agentenläufe als Trajektorien. Chain-of-Thought-Prompting machte Zwischenschritte als Textsequenzen sichtbar (Wei et al., 2022). ReAct verband später Begründung, Aktion und Beobachtung in einem Aufgabenpfad (Yao et al., 2023). Die Lutions-Traces sind schwächer als eine vollständige Trajectory-Evaluation, weil sie keine vollständige Chain-of-Thought und keine vollständige Toolcall-Historie enthalten. Sie zeigen aber, welche Quellen-, Such- und Prüfspuren in den Artefakten auftauchten.
Aus Softwareentwicklungssicht schließen Program Comprehension, Information Foraging und Traceability an. Entwickler suchen bei Wartungsaufgaben nicht nur Dateien. Sie sammeln Hinweise, setzen Informationen in Beziehung und bauen daraus ein Verständnis unbekannter Codebereiche auf (Ko et al., 2006). Werkzeuge verändern dabei Informationsspuren und Suchkosten (Fleming et al., 2013). Traceability-Forschung zeigt zugleich, dass Nachvollziehbarkeit in Softwareprojekten wichtig, aber schwer dauerhaft zu erhalten ist (Cleland-Huang et al., 2014). Forschung zu agiler Dokumentation begrenzt den Anspruch zusätzlich: Dokumentation bleibt nur nützlich, wenn sie selektiv, aktuell und an reale Arbeitsfragen gebunden bleibt (Islam et al., 2023).
Für den Lutions Knowledge Layer ist diese Einordnung wichtig. Der relevante Nutzen liegt nicht zuerst in einer allgemeinen Retrieval-Verbesserung. Er liegt darin, Aufgabe, Wiki, Primärquellen, Prüfgrenzen und Antwortstruktur besser miteinander zu verbinden.
6. Nächste Prüfstufe
Aus den Gegenproben ergeben sich zwei Hypothesen, die getrennt bleiben müssen.
H1: Bei mehrschichtigen Aufgaben unterscheidet sich der Knowledge-Layer-Arm im dokumentierten Such- und Prüfpfad. Fachliche Ebenen, Quellenfamilien und Antwortgrenzen werden früher oder expliziter sichtbar.
H2: Diese veränderte Prüfkette führt häufiger zu quellengetreuen, gut begrenzten und fachlich richtigen Endantworten.
Die vorliegenden Gegenproben stützen H1 vorläufig und qualitativ. H2 bleibt offen. Um H2 zu prüfen, bräuchte es eine kleine, sauberere Folgestufe: eingefrorener Repository- und Wiki-Stand, frische Sitzung pro Lauf, balancierte Reihenfolge, dokumentierte Prompts, drei Vergleichsarme und vorab definierte Goldstandard-Checklisten.
Sinnvoll wären drei Bedingungen: repo-first, classic-docs-first und wiki-first. Die Aufgaben sollten verschiedene Falltypen abdecken: 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 feststehen, welche Ebenen, Primärquellen, Gegenbedingungen, Datenabhängigkeiten und unzulässigen Verkürzungen erwartet werden. Danach könnten Endantworten zunächst ohne sichtbare Pfadzuordnung bewertet werden. Selbst dann wären Signifikanztests kaum sinnvoll. Tragfähig wären eher deskriptive Befunde: Wie oft wurden obligatorische Ebenen, Primärquellen und korrekte Grenzen genannt?
7. Fazit und Ausblick
Die ersten Lutions-Gegenproben sind ernüchternd im guten Sinn. Sie verhindern eine zu schnelle Erfolgserzählung. Der Knowledge Layer macht Agentenantworten nicht automatisch besser, und er ersetzt weder Codeverständnis noch Primärquellenprüfung.
Was sichtbar wird, ist bescheidener, aber wichtig: Bei mehrschichtigen Aufgaben kann der wiki-first Einstieg den dokumentierten Prüfpfad ordnen. Er macht fachliche Ebenen, Quellenfamilien und Grenzen früher sichtbar. Bei lokalen Codefragen mit präzisem Suchanker bleibt repo-first dagegen oft direkter.
Damit schließt der vierte Beitrag an die ersten drei Teile an. Das LLM-Wiki bleibt eine Orientierungsschicht, keine Wahrheitsschicht. Seine erste messbare Bewährungsprobe liegt nicht im Versprechen besserer Antworten, sondern in der Frage, ob es Arbeit nachvollziehbarer macht. Genau dort zeigen die Lutions-Gegenproben erste Hinweise. Ob daraus auch bessere Ergebnisse entstehen, bleibt die nächste, strengere Prüfung.
Quellenverzeichnis
Primärartikel dieser Reihe
- Hermanns, Christoph (2026a). Das LLM-Wiki: Persistentes Wissen für Menschen und KI-Agenten.
- Hermanns, Christoph (2026b). Das LLM-Wiki in der Softwareentwicklung: Persistentes Wissen über Code.
- Hermanns, Christoph (2026c). Das LLM-Wiki in Lutions: Vom Pattern 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, nicht öffentlich prüfbare Lutions-Auswertungsquellen
Die folgenden Quellen dokumentieren die interne Belegbasis der Gegenproben. Sie sind für externe Leser nicht notwendigerweise zugänglich, werden im Artikel aber nur als zusammengefasste Befunde, Fallgruppen und methodische Grenzen ausgewertet.
- 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
Wenn ich ganz ehrlich bin, bin ich mit deutlich höheren Erwartungen in diese Testreihen gestartet. Die Prämisse klang bestechend: Gib dem Agenten ein strukturiertes Wiki als Einstieg, und die Ergebnisse müssten fast zwangsläufig präziser, schneller und umfassender werden.
Die reale Auswertung der Traces war dann erst einmal ernüchternd. Die erhoffte Magie blieb aus; ein sofortiger, harter Effizienzsprung ließ sich aus den Daten nicht seriös ableiten. Manchmal muss man solche methodischen Wege gehen, um am Ende festzustellen, dass man keinen Shortcut gefunden hat.
Warum lasse ich den Text trotzdem genau so stehen? Weil diese Ernüchterung ein Wert an sich ist. Wir neigen in der aktuellen KI-Debatte dazu, jedes Architektur-Experiment sofort als Durchbruch zu verkaufen. Die Realität der Softwareentwicklung ist aber kleinteiliger. Was dieser Testlauf uns nicht gegeben hat, ist ein Beweis für ‘schneller und billiger’. Was er uns aber gegeben hat, ist etwas viel Wichtigeres für die langfristige Skalierung: Sichtbarkeit.
Wir haben die Blackbox ein Stück weit geöffnet. Dass der Agent seine Suchwege, Quellen und fachlichen Grenzen nun explizit dokumentiert, ist das architektonische Fundament, auf dem wir KI überhaupt erst systematisch debuggen, steuern und vertrauensvoll in unsere Repositories lassen können. Es ist kein Sprint-Sieg, aber ein notwendiger Schritt auf dem Weg zu echter, nachvollziehbarer Agenten-Governance.
Genau aus diesem Grund hake ich das Experiment nicht ab. Ich werde das LLM-Wiki im Entwicklungsalltag weiter nutzen, iterieren und systematisch ausbauen. Wir stehen hier erst am Anfang. Es ist gut möglich, dass sich mit wachsender Tiefe des Knowledge Layers und einer größeren kritischen Masse an Aufgaben neue, messbare Effekte einstellen. Sobald die kontinuierliche Praxis neue Erkenntnisse liefert, werde ich an dieser Stelle ein Update teilen.