thoughts
Warum Kontext wichtiger ist als das Modell
Bis hierhin ging es um Werkzeuge, die Wissen erzeugen und speichern. Jetzt geht es um das, was daraus einen echten Produktivitätssprung macht. Und der liegt, anders als die ewige Debatte über das nächste, noch größere Modell vermuten lässt, an einer unscheinbaren Stelle: im Kontext.
Codex und Claude: der eigentliche Motor
ChatGPT, Claude und Codex sind meine wichtigsten Daily Driver. Über ChatGPT habe ich bereits gesprochen. Claude und Codex erfüllen für mich grundsätzlich einen ähnlichen Zweck.
Der entscheidende Unterschied liegt dabei weniger im jeweiligen Modell, als die permanente Diskussion über Modellvergleiche vermuten lässt. Wichtiger sind die Systeme und Skills, die ich selbst darauf aufbaue.
Der erste Schritt ist meist derselbe: Ich verbinde Codex oder Claude mit GitHub, beispielsweise über die GitHub CLI. Ab diesem Moment hat die KI Zugriff auf mein Repository – und genau das verändert die Qualität der Zusammenarbeit grundlegend.
Sie kennt die Codebasis.
Sie kann den aktuellen Stand analysieren, Pull Requests lesen, Dateien durchsuchen, bestehende Strukturen erkennen und technische Zusammenhänge erklären. Sie kann nachvollziehen, welche Patterns bereits verwendet werden und wie einzelne Bestandteile des Produkts miteinander verbunden sind.
Zum ersten Mal entsteht echter Kontext.
Genau an diesem Punkt unterscheiden sich ein allgemeiner Chatbot und ein produktives KI-System.
Ein Modell ohne Kontext kann lediglich aus allem, was es gelernt hat, eine plausible Durchschnittsantwort bilden. Ein Modell mit Zugriff auf mein Repository spricht nicht mehr über Software im Allgemeinen. Es spricht über meine konkrete Software.
Dieser Kontext ist für mich oft wertvoller als allgemeines Modellwissen.
Die Branche verwendet dafür zunehmend den Begriff Context Engineering. Gemeint ist, einem Modell nicht einfach nur einen möglichst langen Prompt zu geben, sondern gezielt den richtigen Kontext aus den relevanten Systemen bereitzustellen.
Standards wie das Model Context Protocol verfolgen genau dieses Ziel. Sie schaffen einen strukturierten Weg, über den Modelle auf jene Systeme zugreifen können, in denen die eigentlichen Informationen liegen – statt alles manuell in einen Prompt kopieren zu müssen.
Auf dieser Grundlage baue ich eigene Skills.
Diese Skills kennen nicht irgendeine allgemeine Best Practice aus dem Internet. Sie kennen meine Arbeitsweise: meine Ticketstruktur, meine Coding-Konventionen und die Art, wie Anforderungen bei uns formuliert werden.
Ein solcher Skill kann auf Grundlage der tatsächlichen Codebasis ein Jira-Ticket vorbereiten. Er kann Rückfragen stellen, statt eine unklare Anforderung ungeprüft zu übernehmen. Er kann Anforderungen strukturieren, technische Dokumentation erstellen und neue Erkenntnisse anschließend wieder in Obsidian ablegen.
Dadurch schließt sich ein Kreis.
Es entsteht nicht nur Automatisierung. Mit jeder Runde wächst auch das Verständnis für das eigene Produkt.
Das ist für mich der Unterschied zwischen einem Werkzeug, das einzelne Aufgaben abarbeitet, und einem System, das mit dem Produkt und dem vorhandenen Wissen mitwächst.
Erst das Zusammenspiel macht den Unterschied
Bis hierhin habe ich die Werkzeuge einzeln beschrieben. Der eigentliche Mehrwert entsteht jedoch nicht in einem einzelnen Tool.
Er entsteht dann, wenn die Systeme miteinander verbunden werden.
An diesem Punkt hört KI für mich auf, eine Sammlung einzelner Anwendungen zu sein. Sie wird zu etwas, das eher wie ein Betriebssystem für meinen Arbeitsalltag funktioniert.
Der Ablauf greift ineinander.
Fireflies zeichnet Meetings auf, transkribiert sie und fasst die wichtigsten Erkenntnisse zusammen. Diese Informationen wandern anschließend nach Obsidian.
Dadurch entsteht nicht nur eine Meeting-Dokumentation, sondern langfristiges Wissen.
Obsidian speichert alles, was ein Produkt über die Zeit ausmacht: Produktentscheidungen, Protokolle, Projektnotizen, technische Erkenntnisse, Fachwissen und neue Ideen.
Dieses Wissen wächst kontinuierlich weiter.
Dann kommt der entscheidende Schritt: Codex oder Claude erhalten Zugriff auf Obsidian und gleichzeitig auf GitHub.
Damit kennen sie beide Seiten.
Sie kennen die Dokumentation und den aktuellen Quellcode. Sie kennen nicht nur das Was, sondern zunehmend auch das Warum. Zum ersten Mal entsteht ein vollständiger Kontext, der nicht mehr an der Grenze zwischen Produktwissen und Software endet.
Genau dieser Kontext macht KI wesentlich leistungsfähiger.
Das System kennt nicht mehr nur allgemeine Prinzipien der Produktentwicklung. Es versteht mein Produkt, meine Arbeitsweise, meine Dokumentation, den aktuellen Stand der Software und die Entscheidungen, die zu diesem Stand geführt haben.
Darin liegt für mich die wichtigste Erkenntnis des gesamten Aufbaus – und sie widerspricht ein wenig dem, worüber die Branche am liebsten spricht.
Der größte Fortschritt liegt nicht zwangsläufig im nächsten noch größeren Modell.
Er liegt im Kontext.
Ein durchschnittlich gutes Modell mit Zugriff auf mein Wissen und meinen Code kann für mich wertvoller sein als das leistungsfähigste Modell der Welt, das mein Produkt nicht kennt.
Retrieval-Augmented Generation, Knowledge Graphs und verbundene KI-Systeme verfolgen im Kern alle dasselbe Ziel: dem Modell nicht nur mehr Intelligenz, sondern vor allem den richtigen Kontext zu geben.
Wie dieser vollständige Kontext im Alltag aussieht – von der ersten Idee bis zum fertigen Pull Request – beschreibe ich im letzten Teil.