Unser zweites Gehirn, oder wie eine KI über dutzende Projekte hinweg dazulernt
Wir arbeiten an vielen Dingen gleichzeitig. Kundenprojekte, eigene Produkte, Infrastruktur, dazwischen die kleinen Experimente, aus denen manchmal das nächste Werkzeug wird. Und wir arbeiten dabei eng mit KI-Assistenten zusammen, nicht als Spielerei, sondern als täglichem Handwerkszeug.
Das bringt ein Problem mit sich, über das in den ganzen „KI verändert alles"-Artikeln erstaunlich selten jemand schreibt: Eine KI hat kein Gedächtnis über Sitzungen hinweg. Jedes Gespräch beginnt bei null. Was wir gestern in einem Projekt mühsam herausgefunden haben, ist heute im nächsten Projekt wieder unbekannt. Derselbe Fehler wird zweimal gemacht. Dieselbe Architektur-Entscheidung wird dreimal von vorn diskutiert. Das gleiche Muster wird viermal neu erfunden.
Bei einem einzelnen Projekt fällt das kaum auf. Bei über zwei Dutzend parallel wird es teuer.
Das eigentliche Problem: nicht zu wenig Wissen, sondern verdampfendes Wissen
Die naheliegende Antwort wäre, einfach alles in eine große Notiz zu schreiben. Haben wir versucht. Funktioniert nicht. Eine Notizsammlung, die niemand zum richtigen Zeitpunkt liest, ist kein Wissen, sondern Ballast. Das Wissen war oft da, es wurde nur nicht abgerufen, wenn es gebraucht wurde. Genau das war die ehrliche Diagnose, mit der wir angefangen haben: Wiederholungs-Fehler über Projekte hinweg, Muster, die mehrfach neu entdeckt wurden, Entscheidungen, an die sich niemand erinnerte.
Also haben wir uns ein System gebaut, das wir intern „das zweite Gehirn" nennen. Kein gekauftes Produkt, sondern eine schlichte, wachsende Wissensbasis aus verlinkten Textdateien, die ausschließlich die KI selbst pflegt, während der Mensch kuratiert.
Wie es aufgebaut ist
Im Kern ist es unspektakulär: Markdown-Dateien, sauber sortiert. Spektakulär ist die Trennschärfe, die sich erst über Wochen herausgebildet hat. Es gibt klar getrennte Ablagen für:
- Projekte und Kunden: was ist das, wo steht es, was ist der aktuelle Stand.
- Konzepte: wiederverwendbare technische Referenzen, ein Deployment-Muster, eine Architektur, die sich bewährt hat.
- Muster: und das ist der entscheidende Ordner, kondensierte Einzel-Lehren aus konkreten Vorfällen. Eine Seite, ein Lehrsatz, abgeleitet aus einem echten Fehler.
- Entscheidungen: projektübergreifende „Warum X statt Y", damit dieselbe Frage nicht alle vier Wochen neu aufgemacht wird.
- Sitzungen: ein Schnappschuss pro Arbeitssitzung, Auftrag, was getan wurde, was bewusst offen blieb, was gelernt wurde.
Der feine Unterschied zwischen „Konzept" (ein wiederverwendbares Rezept) und „Muster" (eine destillierte Einzel-Lehre) klingt akademisch, ist aber der Grund, warum das System funktioniert. Ein Beispiel für ein Muster, das bei uns Gold wert ist: „Bei Finanzbeträgen niemals mit Fließkommazahlen rechnen." Klingt banal. Der konkrete Auslöser war ein Bug, bei dem aus „12,50" durch eine falsche Umwandlung schlicht „12" wurde. Fünfzig Cent Verlust, jedes Mal. Seitdem ist diese Lehre eine eigene Seite. Und genau das ist passiert: In zwei späteren Projekten wurde dieselbe Falle erkannt und vermieden, bevor sie zuschlagen konnte.
So sind über hunderte dokumentierte Arbeits-Sitzungen zusammengekommen, dazu mehrere Dutzend technische Konzept-Seiten, rund vierzig destillierte Muster und gut zwei Dutzend übergreifende Entscheidungs-Dokumente. Es ist eine lebende Sammlung, kein Archiv.
Der eigentliche Trick: Es schlägt nicht nach, es meldet sich
Ein Nachschlagewerk muss man aktiv befragen. Genau das ist die Schwachstelle, denn man fragt nur, wenn man weiß, dass es etwas zu wissen gibt. Die erste Version unseres Systems war „pull-only": Wissen musste explizit abgerufen werden. Das half, aber nur dem, der ohnehin schon ahnte, dass es eine Antwort gibt.
Die zweite Ausbaustufe war der eigentliche Sprung. Heute liegt über der Wissensbasis eine lokale semantische Suche (technisch: ein Embedding-Modell, das auf unserer eigenen Maschine läuft, kombiniert mit einer schlanken Vektor-Datenbank). Eine typische Abfrage ist in einem Bruchteil einer Sekunde durch. Und entscheidend: Bei jeder neuen Aufgabe schaut das System automatisch nach, ob es dazu schon relevantes Wissen gibt. Findet es etwas Passendes oberhalb einer Relevanzschwelle, spielt es die entsprechenden Muster von selbst ein, ohne dass jemand danach fragen muss.
Aus „Wiki als Nachschlagewerk" wurde „Wiki als Arbeitspartner, der sich einmischt". Wenn wir heute ein neues Projekt auf einen kleinen Server bringen, taucht ungefragt das Deployment-Muster auf, das wir bei einem halben Dutzend früherer Projekte verfeinert haben, inklusive der Warnung, dass bei knappem Arbeitsspeicher lokal gebaut werden muss statt auf dem Server. Diese eine Zeile hat uns mehr als einmal einen Abend Fehlersuche erspart.
Wo es ehrlicherweise hakt
Und jetzt der Teil, den man in Hochglanz-Darstellungen nie liest, der für uns aber zur Sache gehört.
Die Suche ist nicht perfekt. Bei einem internen Test fand das System bei drei von fünf Anfragen die wirklich beste Quelle nicht in den vorderen Treffern. Der Grund ist lehrreich: Es gibt sehr viel mehr Sitzungs-Protokolle als destillierte Muster, und die langen, prosareichen Protokolle drängen sich bei der Suche nach vorn, obwohl die kurze, dichte Muster-Seite die bessere Antwort wäre. Wir steuern dagegen, indem wir Mustern bei der Bewertung einen Bonus geben, aber gelöst ist das nicht restlos. Eine sehr knappe, tabellarische Seite wird schlechter gefunden als ein ausschweifender Text. Das ist kein Technik-Problem, das ist ein Schreib-Problem.
Das System veraltet, wenn man es lässt. Wir haben es mehr als einmal vergessen, eine Sitzung sauber abzulegen. Einmal fiel erst nach acht Tagen auf, dass eine ganze Arbeitssitzung nie ins Gedächtnis gewandert war. Die Konsequenz war kein Vorwurf, sondern Mechanik: Wir haben ein dreifaches Sicherheitsnetz eingezogen, eine Erinnerung im Gedächtnis der KI, eine im Projekt selbst, und einen automatischen Auslöser am Sitzungsende. Das Prinzip dahinter ist eine unserer härtesten Lektionen: Auf eine einzelne Erinnerung ist kein Verlass, erst mehrere voneinander unabhängige Netze fangen den Fehler zuverlässig.
Die KI entscheidet nicht allein, was wichtig ist. Ob eine einzelne Erfahrung zu einer allgemeingültigen Lehre destilliert wird, ist und bleibt eine menschliche Entscheidung. Die KI kann vorschlagen. Ob ein Vorfall wirklich ein wiederverwendbares Muster ist oder nur ein Einzelfall, beurteilt ein Mensch. Wir halten das bewusst so.
Warum das alles auf unserer eigenen Maschine läuft
Es wäre einfacher gewesen, einen Cloud-Dienst für die semantische Suche zu mieten. Wir haben uns bewusst dagegen entschieden, und zwar aus einem Grund, der für unsere ganze Arbeit gilt: In dieser Wissensbasis stehen interne Projektunterlagen, und die behandeln wir grundsätzlich als schützenswert. Solche Inhalte verlassen das Haus nicht. Also läuft die gesamte Suchinfrastruktur lokal, ohne dass je ein Datensatz an einen externen Anbieter geht. Der angenehme Nebeneffekt: Das System funktioniert auch ohne Internet.
Erfahrung, die nicht verdampft
Wie zentral dieses zweite Gehirn inzwischen ist, merkt man am ehesten, wenn es fehlt. Startet man dieselbe KI einmal auf einem frischen Rechner, ohne unsere über Monate gewachsene Wissens- und Regelschicht, ist das ein spürbar anderes, deutlich schwächeres Erlebnis: dieselbe Technik, aber ohne das Gedächtnis, ohne die gelernten Lehren, ohne die Leitplanken. Dieses zweite Gehirn ist deshalb kein nettes Beiwerk, sondern eines unserer wichtigsten Arbeitswerkzeuge.
Die Haltung dahinter ist exakt dieselbe, mit der wir an Kundenprojekte gehen: Erfahrung darf nicht verdampfen. Was einmal schiefging, soll nie wieder aus demselben Grund schiefgehen. Und ein System, das schöne Funktionen hat, aber zur falschen Zeit schweigt, ist weniger wert als eines, das sich im richtigen Moment meldet.
Wir bauen Dinge so, dass sie über die Zeit besser werden, nicht nur einmal fertig. Das zweite Gehirn ist der Beweis, dass wir das auch von uns selbst verlangen.
Aus dem Labor ist unsere Rubrik über das, was wir selbst bauen und betreiben, bevor wir es jemandem empfehlen. Wenn du wissen willst, wie wir mehrere dieser KI-Assistenten gleichzeitig steuern, liest du weiter in Wie ein Mensch ein ganzes Team von KI-Agenten dirigiert. Fragen? Schreib uns.