Vom Durcheinander zum Kontext: Wie man einen KI-Workflow aufbaut

Es gibt eine ganz eigene Art von Frust: dieselbe Korrektur mehrfach in einer einzigen Session an eine KI-Assistenz zu richten. Die Wunder moderner großer Sprachmodelle (LLMs) sorgen dafür, dass man mit dem begeisterungsfähigsten Lehrling arbeitet, den man je haben wird. Nur hat dieser Lehrling zufällig auch Amnesie. "Doch, ich will meine Commit-Nachrichten wirklich so formatiert haben, wir hatten dieses Gespräch schon dreimal."

Oder man kennt die Mühe, mehrere parallele KI-Sessions zu koordinieren, und sieht dann zu, wie sie unabhängig voneinander dieselben Probleme lösen und sich gegenseitig die Arbeit löschen.

Dieser Frust hat mich auf einen Weg des Ausprobierens gebracht. Ich habe an frühen Fassungen zweier GitLab-KI-Funktionen mitgearbeitet: Explain this vulnerability und Resolve this vulnerability. Damals wirkten sie naiv, und ich wollte mehr von ihnen.

Agentische KI hat das geliefert. Statt Einzelvorschlägen, die ich anfordern und zurückkopieren musste, konnte ein Agent die Codebasis lesen, die Änderung vornehmen und die Tests selbst laufen lassen. Er erledigte die Arbeit, statt nur dazu zu raten. Von da an ging es über GitLab Duo Custom Agents und VS-Code-Integrationen weiter bis zu OpenCode, einem quelloffenen Agenten, der sich selbst so beschreibt: Er hilft dabei, "Code im Terminal, in der IDE oder auf dem Desktop zu schreiben".

Unterwegs habe ich zusammengetragen, was für mich funktioniert. KI-Assistenz beim Programmieren verändert die Arbeit spürbar, aber sie braucht das ingenieurmäßige Gespür der Menschen, die sie führen. Sie verstärkt gute wie schlechte Entscheidungen, deshalb kommt es auf die Richtung an. Die Werkzeuge werden sich weiter ändern, doch das Folgende hat meiner täglichen Arbeit bisher geholfen.

Ein eingespielter KI-Workflow

Bevor es zu den Prinzipien geht, lohnt ein Blick darauf, wie ein eingespielter KI-Workflow in der Praxis aussieht.

Die Prioritäten kommen zu mir. Starte ich eine Session, lädt die KI meine aktiven Sessions, ungelösten Blocker, geltenden Direktiven und jüngsten Entscheidungen. Dann holt sie meine GitLab-Todos, offenen MRs und beobachteten Epics und legt sie in meiner festgelegten Reihenfolge vor: zuerst Liegengebliebenes (was durchzurutschen droht), dann Review-Anfragen anderer (niemanden blockieren), dann Fragen, die eine Antwort von mir brauchen, dann meine eigenen blockierten MRs und schließlich alles Übrige. Ich muss nicht mehr herausfinden, woran ich arbeiten sollte. Der Kontext kommt zu mir.

Konzentration funktioniert heute anders. Softwareentwicklung verlangte üblicherweise Stunden ununterbrochener Konzentration, damit etwas Nennenswertes entstand. Das hat sich geändert. In einem Fenster von 15 oder 30 Minuten kann ich fragen, was oben in der Warteschlange liegt, die KI den Kontext dazu laden lassen (frühere Entscheidungen, Blocker, einschlägige Abläufe) und mit dem Delegieren von Programmier- und Testarbeit beginnen. Die KI bringt mich fast unmittelbar auf Stand, statt dass ich den Zusammenhang im Kopf neu aufbauen muss.

Mehrere Merge Requests laufen parallel. Ich nutze Git-Worktrees mit eigenen Testdatenbanken, damit KI-Sessions gleichzeitig an mehreren Merge Requests arbeiten. Jeder Worktree bekommt seine eigene Session und seine eigene Datenbank, und ein Claiming-System verhindert, dass Sessions sich in die Quere kommen. Die KI lässt die Tests laufen und stellt sicher, dass der Code funktioniert. Ich prüfe auf Richtigkeit.

Wiederkehrende Aufgaben werden zu Abläufen. Für ein Epic, das ich mit Priorität verfolge, übernimmt die KI die wöchentliche Statusmeldung: Sie holt den aktuellen Stand aus GitLab, vergleicht ihn mit dem der Vorwoche, um die Veränderungen zu ermitteln, und entwirft die Meldung samt Fortschrittskennzahlen. Der Ablauf ist in meinen Direktiven dokumentiert, sodass ihn jede Session gleich ausführen kann.

Token-Effizienz zählt. Ich habe Verbesserungen an GitLabs REST- und GraphQL-API und am OpenCode-GitLab-Plugin beigesteuert, um den Kontext-Overhead zu senken, und einen lokalen Workflow-Server für das Model Context Protocol (MCP) gebaut, der gängige Muster festhält. Statt sich jedes Mal neu zusammenzusuchen, wie etwas geht, ruft die KI ein zugeschnittenes Werkzeug auf, das die Datenbeschaffung übernimmt und das Denken dem LLM überlässt. Das hält die Antwortzeiten kurz und den Token-Verbrauch im Rahmen.

Aktives Delegieren ist das Muster darunter. Ich halte den übergeordneten Kontext und die Richtung, während die KI die einzelnen Aufgaben ausführt. Bevor an einem Merge Request gearbeitet wird, beansprucht die KI ihn für sich, um Konflikte zu vermeiden, lädt seine Vorgeschichte aus dem Gedächtnis und prüft, welche Direktiven gelten. Ich behalte die Aufsicht über die Richtung. Die KI hält das Tempo der Ausführung.

Präzise Direktiven statt vager Anweisungen schreiben

Jede Session beginnt bei null. Ohne Zutun erklärt man dieselben Vorlieben, dieselben Konventionen, dieselben Eigenheiten der Codebasis immer wieder neu.

Die Lösung sind ausdrückliche, dauerhafte Direktiven. Agentische KI-Werkzeuge haben begonnen, sich auf AGENTS.md-Konfigurationsdateien zu verständigen, die als Startkontext geladen werden. Die entscheidende Einsicht ist aber nicht, dass es Direktiven braucht, sondern dass sie konkret sein müssen.

Eine vage Anweisung wie "sei vorsichtig mit Kommentaren" bringt nichts. Die KI nimmt sie zur Kenntnis und macht dann ohnehin, was sie vorhatte. Was wirkt, ist konkret:

"ALWAYS verify user IDs exist before posting comments under their name. STOP and ask if unsure."

Die Großbuchstaben dienen nicht nur der Betonung. Sie scheinen dafür zu sorgen, dass die KI verlässlicher auf die Anweisung reagiert.

Anzuwendendes Muster: Macht das KI-Werkzeug einen Fehler, sollte man ihn nicht nur korrigieren. Besser ist die Frage, welche Direktive diesen Fehler künftig verhindern würde. Dieses Gespräch führen und die KI dann bitten, das Ergebnis für das nächste Mal festzuhalten. Mit der Zeit entsteht so ein Satz Anweisungen, der auf den eigenen Arbeitsablauf zugeschnitten ist statt auf hypothetische Best Practices.

Mein Repository agents-config enthielt früher über ein Dutzend spezialisierter Konfigurationsdateien, die auf diesem Weg entstanden sind: Leitlinien für Code-Reviews, Abläufe für Merge Requests, Vorgehen bei Datenbank-Reviews, Standards für das Schreiben von Kommentaren. Jede einzelne gibt es, weil ich die Sache oft genug gemacht habe, dass es sinnvoll wurde, sie zu einem Ablauf zu machen und die KI ihn gleichmäßig ausführen zu lassen.

Das Gedächtnissystem, das ich weiter unten beschreibe, hat diesen Ansatz entlastet: Jene Direktiven liegen jetzt im durchsuchbaren Gedächtnis statt in statischen Dateien. Das Repository enthält inzwischen praktische Beispiele und eine Anleitung dazu, wie ich im Alltag arbeite.

Parallele Sessions brauchen Koordinationsmittel

Mehrere KI-Sessions gleichzeitig laufen zu lassen, kann sich lohnen, wenn man sie im Griff behält. Drei Terminals, drei Assistenzen, drei parallele Arbeitsstränge. Ohne Koordination stellen sich allerdings vertraute Probleme ein:

• Sessions bearbeiten dieselben Dateien, ohne voneinander zu wissen
• Mehrere Sessions arbeiten am selben Vorgang (sofern es überhaupt eine Möglichkeit gibt, Arbeit zu beanspruchen, was vermutlich noch nicht der Fall ist)
• Widersprüchliche Entscheidungen entstehen isoliert
• Sessions löschen die Arbeit der anderen oder committen sie unbekümmert mitsamt eigenen Änderungen in fremde MRs
• Doppelte Arbeit, weil keine Session weiß, was die andere getan hat

Wer schon nebenläufig programmiert hat, erkennt darin die klassischen Koordinationsprobleme. Die Lösungen ähneln sich ebenfalls: Es braucht Mittel, um Arbeit zu beanspruchen, Zustand zu verfolgen und Kontext zu teilen.

Meine erste Lösung waren dateibasierte Arbeitsnotizen. Sie funktionierten, ließen sich aber nicht durchsuchen, waren nicht mit der beschriebenen Arbeit verknüpft und überdauerten mehrere Tage schlecht. Ich brauchte etwas, das relevanten Kontext von selbst nach oben spült.

So entstand opencode-memory, ein dauerhaftes semantisches Gedächtnis. Seine Architektur spiegelt die Lösungen für Probleme, die ich zuvor immer wieder per Direktive gelöst hatte: hybride Suche (Stichworte für exakte Begriffe, Semantik für unscharfes Erinnern), Session-Koordination über Beanspruchen und Freigeben, und ein Startkontext, der die entscheidenden Direktiven von selbst sichtbar macht.

Seit der ersten Fassung ist das System erheblich gewachsen. Es ist inzwischen ein vollständiger Wissensgraph mit über 760.000 indexierten Code-Entitäten, mehr als 15.000 Memories einschließlich Gesprächszusammenfassungen und 27.000 Verknüpfungen dazwischen.

Als GitLab Orbit vorstellte, einen Wissensgraphen über den gesamten Software-Lebenszyklus (SDLC), passte das fast genau zu der Richtung, die ich lokal eingeschlagen hatte. Orbit beantwortet Fragen über den ganzen Lebenszyklus hinweg, etwa "was bricht, wenn ich diesen Dienst ändere?", indem es Code, Merge Requests und Pipelines verbindet.

Mein Gedächtnismodul indexierte meine Codebasis bereits lokal für schnelles Erinnern, also habe ich die weitere Sicht nicht neu erfunden, sondern Orbit angebunden. Das lokale Gedächtnis hält den Kontext der Session, also Entscheidungen, Blocker und Abläufe, und Orbit legt GitLabs größeren SDLC-Graphen darüber. Eines der schönsten Ergebnisse: Erwähne ich eine Funktion im Gespräch, weiß die KI genau, wo sie liegt, ohne dass ich nachsehen muss.

Auch frühere Entscheidungen tauchen von selbst auf, sobald die Arbeit an einem Merge Request beginnt. Blocker bleiben bestehen, bis sie ausdrücklich aufgelöst werden. Einmal festgelegte Abläufe stehen dauerhaft bereit. Erinnerungen melden sich dort, wo sie zählen. Und der gemeinsame Graph aus meinem lokalen Gedächtnis und Orbits SDLC-Daten beantwortet solche Fragen weit treffsicherer, als eine reine Textsuche es je konnte.

Erst nachsehen, dann bauen

Keine Idee ist einzigartig. Wer nach Gedächtnissystemen für KI-Programmierassistenz sucht, findet Dutzende Ansätze. Vermutlich hat jemand genau das, woran man denkt, schon drei Wochen vorher in einem koffeingetriebenen KI-Rausch gebaut. Es gibt sogar ein PyPI-Paket namens opencode-memory, das dem, was ich gebaut habe, sehr nahekommt, nur mit einer anderen Vektordatenbank darunter.

Die Hürde, sich selbst zu bauen, was man braucht, ist so dramatisch gesunken, dass viele unabhängig voneinander auf ähnliche Lösungen kommen. Von der Idee zum lauffähigen Prototyp vergeht eine Woche.

Ich würde empfehlen, vor einem neuen Projekt nachzusehen, ob es das schon gibt. Löst etwas das eigene Problem beinahe, ist ein Beitrag dazu womöglich sinnvoller als eine weitere Variante. Dieser Rat ist so alt wie die Softwareentwicklung selbst, KI verschärft ihn nur hundertfach.

Mein Gedächtnissystem bot anfangs kaum mehr als bestehende Lösungen. Erst nach Monaten des Nachschärfens und der tiefen GitLab-Anbindung finde ich es einigermaßen gerechtfertigt. Immerhin habe ich Verbesserungen an das OpenCode-GitLab-Plugin zurückgegeben, statt es zu forken, weil meine Änderungen dort den meisten Menschen nützen.

Die Frage, die man sich stellen sollte: Habe ich überhaupt nachgesehen, ob es dafür schon etwas gibt, oder hat KI das Programmieren so leicht gemacht, dass ich jede Form von Sorgfalt übersprungen habe?

Vom aktiven Abrufen zum beiläufigen Kontext

Die vektorisierte Gedächtnissuche war sofort ein Gewinn. Ich habe sie noch am Tag ihrer Fertigstellung in Betrieb genommen. Nützliche Einzelheiten wiederzufinden, wurde mühelos. Die nächste Hürde war, dass die KI von selbst merken sollte, wann es etwas zu merken gibt, ohne dass ich jedes Mal danach frage.

Ich war vorangekommen: token-sparsames Gedächtnis für bestimmte Abläufe, ein wachsender Bestand an Erinnerungen, die von allein abrufbar sind. Es fühlte sich aber an, als baute ich nur AGENTS.md mit Verzierungen nach. Es brauchte etwas Klügeres.

Die Lösung war das vorausschauende Einspielen von Kontext. Statt dass die KI Abruf-Werkzeuge eigens aufruft, sucht das System vor jeder Interaktion selbst nach passenden Erinnerungen. Erwähne ich die Nummer eines Merge Requests, stehen frühere Entscheidungen dazu im Kontext, ohne dass ich danach frage. Setze ich zu einem Kommentar an, tauchen die Leitlinien fürs Kommentieren von selbst auf. Meistens jedenfalls. Fertig ist es nicht, aber ich schleife täglich ein Stück daran.

Dieser Wechsel vom aktiven zum beiläufigen Abrufen hat einen echten Unterschied gemacht. Über 30 Tage erreichte das System rund 91 % Treffsicherheit dabei, passenden Kontext von selbst bereitzustellen. Sessions mit vorausschauendem Einspielen kamen im Schnitt ohne einen einzigen ausdrücklichen Abruf aus, gegenüber 17 ohne diese Funktion. Perfekt ist es nicht, es gibt weiterhin Momente, in denen ich der KI sagen muss, dass sie sich etwas merken oder etwas besser machen soll. Aber es ist ein schrittweiser Prozess, und er wird besser.

Die verbleibenden Fehlgriffe waren aufschlussreich. Viele traten auf, während ich am Laden des Startkontexts arbeitete. Die Abhilfe war ein Boot-Gate: ein minimaler Auslöser im Startkontext, der die KI anweist, innezuhalten und die Direktiven zu laden, bevor sie irgendetwas anderes tut. Selbst mit vorausschauendem Einspielen muss man der KI manchmal sagen, dass sie erst stehen bleiben und nachdenken soll.

Was KI weiterhin nicht kann

KI kann Abläufe einigermaßen gleichmäßig ausführen, sofern diese Abläufe im Kontext stehen. Sie kann ihre eigenen Anweisungen verbessern, sofern man sie dazu anhält. Sie kann sich über Sessions hinweg abstimmen, sofern sie die Mittel dafür bekommt.

Aber KI bemerkt nichts von selbst. Sie spürt nicht, dass ein Ablauf umständlich ist. Sie erkennt nicht, dass man diese Woche zum dritten Mal auf dasselbe Problem gestoßen ist. Ihr fehlt die Mustererkennung, die aus Jahren des Debuggens von Produktionssystemen um zwei Uhr nachts erwächst, während man sich fragt, ob Tischlerei nicht doch die bessere Berufswahl gewesen wäre. Zumindest bislang.

Der günstigste Punkt scheint zu sein, KI die stumpfe Arbeit abnehmen zu lassen, ihr zur rechten Zeit den richtigen Kontext zu geben und darauf zu achten, was sie übersieht. Von der menschlichen Seite kommen strategische Aufsicht und Mustererkennung. Von der KI kommen unermüdliche Ausführung und Begeisterung für Aufgaben, die wir früher zäh und langwierig fanden. Das ist befreiend.

Ich habe zugesehen, wie KI begeistert Funktionen baute und dabei Nebenläufigkeitsfehler in ihr eigenes Werkzeug einzog, weil sie sich mit synchronen Operationen selbst blockierte. Sie hatte keine Ahnung davon. Im Rückblick war das ein Ausrichtungsproblem. Ich hätte früher mit ihr planen können, um ein sauberes asynchrones Muster sicherzustellen. Ich hatte gehofft, sie würde von sich aus ein besseres Muster bauen, war damit aber zu optimistisch. Ein Hinweis von mir auf den Architekturfehler, und er war in Minuten behoben.

Das ist das Muster: Der Mensch erkennt das Problem, die KI setzt die Behebung zügig um. Ich hätte es auch selbst machen können, nur nicht so rasch. Meta-Ineffizienzen erkennt KI noch nicht, obwohl sicher gerade jemand einen eigenen Agenten dafür schreibt.

In die eigenen Werkzeuge investieren

So zu arbeiten heißt, ständige Veränderung hinzunehmen. Meine tägliche Arbeit hat sich binnen Monaten vollständig verschoben, und das mehrfach. Früher in meiner Laufbahn änderten sich Arbeitsabläufe über Jahre hinweg langsam.

Man sollte nicht versuchen, sich in einer "neuen Normalität" einzurichten. Sie wird sich ändern. Was heute hilft, kann bei diesem Tempo nächste Woche überholt sein.

Besser ist es, an den Werkzeugen selbst zu arbeiten. Der Arbeitsablauf, der einem weiterhilft, wird selbst zum Gegenstand der Verbesserung. Ich habe neue API-Endpunkte zu GitLab beigesteuert, darunter Group-Uploads und GraphQL-Mutationen für MR-Abläufe, eigens weil ich sie für die KI-gestützte Entwicklung brauchte.

Es ist eine Meta-Schleife: bessere Werkzeuge bringen mehr Produktivität, was wiederum Raum schafft, die Werkzeuge zu verbessern. Ein alter Spruch lautet: "Gebt mir sechs Stunden, um einen Baum zu fällen, und ich werde die ersten vier damit verbringen, die Axt zu schärfen." Ich verbringe dieser Tage einiges damit, meine Axt zu schärfen. Einen besseren Schleifstein hatte ich nie.

Was bleibt

Code ist heute ein Massengut. Wir werden nicht mehr in erster Linie fürs Tippen bezahlt. Wir werden dafür bezahlt zu wissen, welcher Code entstehen sollte. Zu erkennen, wann ein Ansatz grundsätzlich verfehlt ist. Ineffizienzen zu bemerken, bevor sie zu Problemen werden. Die Richtung vorzugeben, die aus roher Fähigkeit brauchbare Ergebnisse macht.

Ich hatte an einer Handreichung gearbeitet, wie sich GitLabs CREDIT-Werte auf den KI-Einsatz übertragen lassen, und dann hat GitLab Act 2 CREDIT vollständig abgelöst und durch neue Leitprinzipien für die agentische Zeit ersetzt. Ein gutes Beispiel dafür, wie rasch sich dieses Feld verschiebt: Meine eigene Handreichung war überholt, bevor sie ankam. Die Kernaussage bleibt aber: Diese Balance richtig hinzubekommen, zählt auf Ebene der Organisation und nicht nur für den Einzelnen. KI sollte menschliche Arbeit erweitern, nicht ersetzen.

Die Werkzeuge werden sich weiterentwickeln. Die Einzelheiten werden sich ändern. Diese grundlegende Einsicht bleibt: KI verstärkt menschliches Urteilsvermögen. Ersetzen sollte sie es nicht, auch wenn sie es versucht, sobald man sie lässt, meist auf Kosten von Codequalität und Stabilität. Mit Vibe Coding kommt man weit, doch selbst bei den gründlichsten KI-Reviews gibt es ein Maß an Qualitätssicherung und sorgfältiger Abwägung im Entwurf, das ich bei KI allein noch nicht gesehen habe.

Mehrere Kolleginnen und Kollegen bei GitLab haben angefangen, Abwandlungen dieses Ablaufs zu nutzen, und ihnen bei denselben Aha-Momenten zuzusehen, hat mich bestätigt. Kürzlich schrieb mir jemand: "Seit ich das Plugin nutze, merke ich definitiv eine Verbesserung in meinen Sessions." Gemeint war das Modul opencode-memory. Ich will nicht so tun, als hätte mir das nicht den ganzen Tag gerettet.

Die Fragen verschieben sich von "wie bringe ich die KI dazu, X zu tun" zu "wie gebe ich der KI den Kontext, den sie braucht, um X gut zu tun". Das ist der eigentliche Schlüssel: nicht die Werkzeuge selbst, sondern die Erkenntnis, dass der Kontext der Engpass ist.

Bemerkenswerterweise merkt man mit zunehmender Übung, dass man selbst der Engpass sein könnte. Manchmal ist das aber auch ein Hinweis darauf, dass sich die eigenen Abläufe noch weiter verbessern lassen. Ein Maximum habe ich noch nicht erreicht, bei Weitem nicht. Unterschiedliche Aufgaben profitieren von unterschiedlichen Herangehensweisen, auch mit KI, und es bleibt reichlich zu erproben.

Noch eine Anmerkung zum Tempo: Das Gedächtnissystem hat in weniger als einem Monat 143 Commits gesehen. Es setzt auf MCP auf, funktioniert also mit jedem Agenten, der das Protokoll spricht: nicht nur mit OpenCode, sondern auch mit Claude CLI, Cursor und anderen. Wenn dieser Text gelesen wird, habe ich vermutlich Funktionen ergänzt, an die ich heute noch nicht gedacht habe. So ist das derzeit in diesem Feld. Die Werkzeuge entwickeln sich schneller als die Dokumentation.

Die in diesem Beitrag genannten Werkzeuge sind quelloffen: agents-config für die Konfiguration von KI-Direktiven und opencode-memory für dauerhaftes Session-Gedächtnis.