Jede Sitzung vergisst, sobald ihr Fenster schließt; der gemeinsame Ordner ist, was maschinenübergreifend bleibt.
Ich arbeite mit mehreren Rechnern und mehreren KI-Sitzungen gleichzeitig. Eine auf dem Server, eine auf dem Windows-Rechner, gelegentlich eine dritte irgendwo dazwischen. Jede kennt genau das, was in ihrem eigenen Fenster steht, und vergisst es, sobald das Fenster zugeht. Das ist über Monate ein teures Muster geworden: dieselbe Frage dreimal beantwortet, dieselbe Falle zweimal betreten, und beim dritten Mal keiner mehr da, der sich erinnert.
Die Lösung ist banal und heißt geteiltes Gedächtnis. Ein Ordner mit Markdown-Dateien auf dem Netzlaufwerk, erreichbar von jedem Rechner. Interessant wird es erst an der Stelle, wo aus dem Ordner etwas wird, das sich selbst pflegt — und an den Stellen, wo genau das nicht funktioniert hat.
Vor jeder Anfrage, nicht einmal pro Sitzung
Die erste Fassung war: beim Start einer Sitzung einmal in den Wissensspeicher schauen. Klingt vernünftig, ist aber zu selten. Eine Sitzung dauert Stunden und wechselt dabei das Thema fünfmal. Was beim Start relevant war, ist es zwei Stunden später nicht mehr, und was jetzt relevant wäre, hat beim Start niemand gesucht.
Jetzt läuft die Abfrage vor jeder Anfrage. Ein kleines Skript nimmt den eingegebenen Text, zieht die tragenden Begriffe heraus — bevorzugt alles, was nach Fachbegriff aussieht, also Pfade, Versionsnummern, Bezeichner mit Ziffern —, sucht damit im Wissensspeicher und blendet die fünf besten Treffer mit Pfad und einer Zeile Kontext ein. Über sechshundert Notizen auf einem Netzlaufwerk, gemessene Laufzeit 0,7 Sekunden. Das ist billig genug, um es immer zu tun.
Zwei Eigenschaften waren mir dabei wichtiger als die Trefferqualität. Erstens: das Skript liest nur. Geschrieben wird ausschließlich über den dafür vorgesehenen Dienst, nie direkt in die Dateien, weil ein Skript mit Schreibrecht auf sechshundert Notizen eine Zeitbombe ist. Zweitens: es scheitert leise. Wenn irgendetwas nicht klappt — Netzlaufwerk weg, Datei kaputt, Zeitüberschreitung — gibt es null Bytes aus und die Anfrage läuft normal weiter. Ein Gedächtnis, das den Zugriff blockieren kann, wird nach dem zweiten Ausfall abgeschaltet.
Der Haken, den ich beim Nachsehen fand
Es gab schon vorher einen solchen Mechanismus. Ein Skript, das beim Sitzungsstart Kontext lädt, ordentlich eingetragen, seit Wochen aktiv. Ich habe es aufgerufen, um zu sehen, was es ausgibt, und bekam null Bytes.
In seinem eigenen Kommentar stand die Erklärung: es tut nur etwas, wenn das Arbeitsverzeichnis innerhalb des Wissensspeichers liegt. Andernfalls beendet es sich stillschweigend. Ich arbeite aber nie im Wissensspeicher, sondern in Projektverzeichnissen — der Speicher ist die Ablage, nicht der Arbeitsplatz. Das Skript hatte also in praktisch jeder Sitzung nichts getan, ohne das je zu melden.
Das ist die unangenehmste Fehlerart überhaupt: konfiguriert, eingetragen, aktiv, wirkungslos. Sie sieht in jeder Übersicht gut aus. Man findet sie nur, indem man das Ding aufruft und nachsieht, was herauskommt.
Ein Aufräumdienst, der weiß, was er nicht darf
Alle fünf Minuten läuft im Container, der den Wissensspeicher bedient, ein kleiner Dienst. Er tut zwei Dinge, und die Grenze dazwischen ist der eigentliche Entwurf.
Er repariert, was sich mechanisch reparieren lässt. Der Schreibdienst hatte eine Eigenart: bei jedem Speichern vervielfachte er eine bestimmte Überschrift. Aus einer wurden drei. Für sich genommen harmlos, aber es steht in einundzwanzig Dateien, und es macht die Struktur kaputt, an der sich sowohl Menschen als auch Suchwerkzeuge orientieren. Das Zusammenführen doppelter Zeilen ist eindeutig und verlustfrei, also darf eine Maschine das. Jede Änderung wird zurückgelesen und über eine Prüfsumme verglichen; stimmt sie nicht, gilt die Änderung als nicht geschehen.
Und er verschiebt nichts. Der Eingangskorb hat einen ordentlichen Rückstand — über hundert Notizen, alle aus den letzten zwei Wochen. Die Versuchung, das automatisch einzusortieren, ist groß, und ich habe ihr bewusst nicht nachgegeben. Wohin eine Notiz gehört, hängt vom Thema ab, davon, was sie mit anderen verbindet, und manchmal davon, ob sie zwei Notizen werden sollte. Ein Dienst, der das nach Dateinamen entscheidet, produziert in einer Woche mehr Unordnung, als er in einem Monat aufräumt.
Was er stattdessen tut: seinen Befund in eine Datei schreiben. Wie viele Notizen im Eingang liegen, wie viele repariert wurden, welche kein Kopfdatenfeld haben. Beim ersten Lauf hat er drei Notizen ohne Kopfdaten gefunden, die seit Wochen niemandem aufgefallen waren.
Ein Wächter, der die richtige Frage stellt
Der Dienst, über den geschrieben wird, war einmal drei Tage lang kaputt. Nicht abgestürzt — er lief. Die Prozessverwaltung meldete ihn als aktiv, der Speicherverbrauch war normal, im Protokoll stand nichts Auffälliges. Nur beantwortete er jede Anfrage mit einem Fehlercode.
Ein Wächter, der nur fragt „läuft der Dienst?“, hätte drei Tage lang „alles in Ordnung“ gemeldet. Deshalb fragt meiner nicht die Verwaltung, sondern den Dienst selbst: er ruft alle zwei Minuten den Endpunkt auf und schaut sich die Antwort an. Kommt keine, wird neu gestartet — und danach wird wieder aufgerufen, denn ein erfolgreicher Startbefehl ist kein Beweis für einen funktionierenden Dienst. Bleibt es dabei, schreibt er in sein Protokoll, dass es jetzt einen Menschen braucht. Es gibt Fehler, die kein Neustart behebt, und ein Wächter, der das nicht zugeben kann, verschleiert sie in Endlosschleife.
Übergabe zwischen Rechnern
Der Teil, der mich am meisten überrascht hat, ist der einfachste: ein Kanban-Board als Markdown-Datei. Spalten sind Überschriften, Karten sind Listenpunkte, Details eingerückt darunter. Kein Plugin, weil eine Sitzung auf einem anderen Rechner den Speicher als Text erreicht und nicht als gerenderte Oberfläche.
Damit kann eine Sitzung Arbeit an eine andere übergeben, die es noch gar nicht gibt. Eine Karte trägt den Befund, die Bedingung für „fertig“ und einen Marker, für welchen Rechner sie gedacht ist. Wer sie übernimmt, verschiebt sie und trägt sich ein — vor der ersten Arbeitsminute, nicht danach, sonst greifen zwei Sitzungen dieselbe Karte.
Ein Detail daran ist mir teuer beigebracht worden: der Schreibdienst kann Karten nicht verschieben. Er hängt nur an. Wer es trotzdem versucht, hängt den Text unten an und lässt die Karte oben stehen — das Board sieht dann aus, als sei die Aufgabe doppelt vergeben. Verschieben geht nur als Lesen, Ändern, ganze Datei zurückschreiben, Prüfsumme vergleichen.
Korrigieren statt umgehen
Die wichtigste Regel ist keine technische. Wenn eine Notiz nicht mehr stimmt, wird sie nicht gelöscht und nicht stillschweigend umgangen, sondern bekommt oben einen datierten Hinweis mit Verweis auf die gültige Fassung.
Warum das keine Förmlichkeit ist, habe ich diese Woche gemerkt. Ich suchte den Grund für eine Fehlermeldung über ein Netzlaufwerk, das es angeblich nicht mehr gab. Der Wissensspeicher hatte drei Notizen dazu, alle beschrieben es als aktiv und tragend, eine zitierte sogar die Konfigurationszeile. Alle drei stammten aus der Zeit vor einem Serverumzug und lasen sich wie der Ist-Zustand. Hätte ich ihnen geglaubt, hätte ich den toten Eintrag für unverzichtbar gehalten und den Fehler nie behoben.
Was ihn behoben hat, war eine Messung am laufenden System: keine einzige Konfiguration verwies noch auf den Pfad, das Verzeichnis war leer, und der Dateiserver antwortete für genau diesen Export mit „gibt es nicht“, während alle Nachbarn sauber antworteten. Daraus ist eine Regel geworden, die ich für die nützlichste des ganzen Aufbaus halte:
Bei Absichten, Entscheidungen und Vorgeschichte gewinnt das Dokument. Beim aktuellen Zustand einer Maschine gewinnt die Messung — und danach wird das Dokument korrigiert.
Der Fall hinter der Regel: drei einige Dokumente gegen eine Messung am laufenden System.
Als die Suche log, ohne zu lügen
Noch eine Geschichte aus derselben Woche, weil sie zeigt, wie leicht ein geteiltes Gedächtnis das Gegenteil von hilfreich wird. Ich suchte einen bestimmten Artikel in der Datenbank der Webseite. Abfrage abgesetzt, keine Zeile zurück. Also erweitert, andere Tabelle, wieder nichts. Nach der dritten leeren Antwort habe ich dem Ergebnis geglaubt und geschrieben, der Artikel existiere nicht.
Er existierte. Zwei Dinge waren schiefgegangen, und beide gehen auf mein Konto. Die Tabellen dieser Installation tragen kein übliches Präfix, sondern eine zufällige Zeichenfolge, die bei der Einrichtung vergeben wurde. Meine Abfragen liefen also gegen Tabellen, die es nicht gibt. Und ich hatte den Fehlerkanal nach /dev/null geleitet, weil die Ausgabe sonst unübersichtlich wird. Damit sah „diese Tabelle existiert nicht“ für mich exakt so aus wie „keine Treffer“.
Ein unterdrückter Fehlerkanal verwandelt einen Fehler in ein Negativergebnis. Das ist besonders tückisch, wenn man Abwesenheit behaupten will, denn Abwesenheit ist die eine Aussage, die sich nicht durch mehr Suchen bestätigen lässt — sie folgt immer nur daraus, dass nichts kam. Seitdem gilt für mich: wer „gibt es nicht“ schreiben will, lässt vorher den Fehlerkanal offen und prüft, ob er überhaupt am richtigen Ort gesucht hat.
Vier Fälle aus diesem Artikel, jeder auf eigene Weise lautlos — keiner meldete sich.
Was es im Alltag ändert
Der spürbarste Unterschied ist unspektakulär. Ich stelle eine Frage, und bevor die Antwort kommt, stehen darüber fünf Zeilen mit Pfaden zu Notizen, von denen ich zwei vergessen hatte. Manchmal ist keine davon nützlich. Zwei- bis dreimal am Tag ist eine dabei, die eine halbe Stunde spart, weil dort schon steht, warum der naheliegende Weg nicht funktioniert.
Der zweite Unterschied ist die Übergabe. Ich kann abends auf dem einen Rechner eine Karte hinterlegen und am nächsten Morgen auf dem anderen weitermachen, ohne den Zwischenstand aus dem Kopf zu rekonstruieren. Für eine einzelne Person klingt das nach Overhead. Sobald mehrere Sitzungen parallel laufen — und das tun sie bei mir fast immer —, ist es der Unterschied zwischen Zusammenarbeit und drei Leuten, die dasselbe Problem gleichzeitig neu lösen.
Der dritte ist unangenehm und deshalb wertvoll. Ein Gedächtnis, das nichts vergisst, hält einem die eigenen Fehler hin. In dieser Woche standen darin drei Behauptungen von mir, die sich beim Nachmessen als falsch herausstellten. Ohne den Speicher wären sie einfach verschwunden. Mit ihm stehen sie da, datiert, mit Korrektur darunter — und die Korrektur ist am Ende der nützlichere Eintrag.
Was noch fehlt
Der Eingangskorb leert sich weiterhin nicht von selbst, und das ist Absicht. Der Aufräumdienst meldet den Rückstand, mehr nicht. Ob das auf Dauer trägt, weiß ich nicht; hundert Notizen sind noch überschaubar, dreihundert wären es nicht.
Die Suche über den Speicher gibt es in zwei Ausführungen, und die bessere war auf dem Rechner, an dem ich diese Woche gearbeitet habe, gar nicht eingerichtet. Aufgefallen ist es erst, als ich einen Artikel nicht fand, den ich selbst geschrieben hatte. Auch das steht jetzt als Karte auf dem Board — was ungefähr der Punkt ist, an dem ein System anfängt, sich selbst zu tragen.
