Warum ich jeden produktiven Prompt versioniere – und wie

Alles, was ich auch nur ansatzweise produktiv nutze und Gefahr läuft, wiederverwendet zu werden – oder schlimmer, in einer Agenten-Pipeline oder einem Systemprompt landet –, wird bei mir versioniert. Volles Programm. Prompt-Versionierung über Git ist dabei keine Ordnungsliebe, sondern die billigste Versicherung, die ich kenne.

Was die Versionierung konkret rettet

Der Klassiker: Ein Prompt läuft seit Wochen stabil, dann „optimiert“ man eine Formulierung – und zwei Tage später liefert die Pipeline Müll. Ohne Versionierung beginnt jetzt das Raten. Mit Versionierung tippe ich git diff und sehe auf den Zeichen genau, was sich zwischen v2.3.0 und v2.4.0 geändert hat. Welcher der Commits das Verhalten gekippt hat, muss ich dann zwar noch eingrenzen – aber ich suche in Minuten statt in Stunden. Voraussetzung ist Disziplin beim Committen – eine Änderung, ein Commit. Verschlimmbessern ist keine Schande. Es nicht zurückverfolgen zu können schon.

Das gilt umso mehr für umfangreiche Prompts mit strengen Ausgabeprotokollen, etwa einem strikten JSON-Format. Wenn ein nachgelagertes System das JSON parst, ist jede Formatänderung ein potenzieller Breaking Change – und genau deshalb will ich nachvollziehen können, wann welches Feld dazukam, umbenannt wurde oder geflogen ist.

Wie mächtig schon die Git-Bordmittel auf reinen Prompttexten sind, hat Simon Willison im April demonstriert: Er hat Anthropics offiziell veröffentlichte System-Prompts für Claude in ein Repo mit datierten Commits zerlegt – eine Datei pro Modell. Die Evolution eines der meistgenutzten Systemprompts der Welt lässt sich seitdem mit git log und git diff durchblättern wie eine Commit-History. Kein Spezialtool, kein Dashboard. Nur Git.

Der Stack: Prompt, Doku, Changelog – strikt getrennt

Zu einem brauchbaren Prompt-Stack gehören für mich drei Dinge, und zwar als getrennte Dateien: der Prompt selbst, eine kurze Dokumentation und ein Changelog. Im Prompt steht ausschließlich, was das Modell für die Aufgabe braucht – plus die Versionsnummer im Frontmatter, mehr Meta-Information bekommt er nicht. Die Versionsnummer ist die eine Ausnahme von meiner Nichts-Extra-Regel – aus gutem Grund. Sobald ein Prompt per Copy-Paste in einer UI oder Pipeline landet, ist er vom Repo getrennt. Das Frontmatter ist dann die einzige Verbindung zurück zur richtigen Doku und zum richtigen Stand. Die Doku beantwortet das Was, Wie, Wann und Warum in einem eigenen Hilfedokument. Der Changelog hält jede Änderung fest.

Gerade der manuelle Changelog klingt erstmal nach Redundanz – Git protokolliert doch ohnehin alles. Stimmt, aber git log ist eine Rohdatenliste, kein kuratiertes Dokument. Der gepflegte CHANGELOG.md liegt direkt im Repo, ist ohne Terminal oder GitHub-Oberfläche lesbar und erklärt Änderungen so, dass ich oder auch jemand anderes sie auch in sechs Monaten noch versteht. Der Preis dafür ist Disziplin: Jede Änderung muss wirklich ins Log. Wer da schludert, kann sich notfalls mit einem Diff und einem willigen kleinen LLM einen Automatismus bauen – funktioniert erstaunlich gut.

Wichtig ist die Reihenfolge der Pflege. Nach jeder Prompt-Änderung werden Doku und Changelog aktualisiert, dann wird committet. Klingt pedantisch, dauert zwei Minuten und ist der Unterschied zwischen einem Archiv und einem Müllhaufen mit Timestamps.

Keine Kommentare im Prompt

In der klassischen Softwareentwicklung gehören Erklärungen in den Code – Kommentare, Docstrings, Inline-Doku. Prompt-Engineering ist aber nicht Code-Schreiben, auch wenn das gerne behauptet wird. Ein Kommentar im Code ist für den Compiler unsichtbar. Ein Kommentar im Prompt ist für das Modell Kontext, und zwar potenziell missverständlicher. Jede Zeile, die nicht der Aufgabe dient, ist Ablenkung, mögliche Fehldeutung und verbranntes Token-Budget.

Deshalb fliegt alles Erklärende raus in die externe Doku. Das ist dieselbe Logik, die ich auch bei CLAUDE.md-Dateien fahre: so kurz und eindeutig wie möglich, nur Ziele, Constraints und Voraussetzungen. Der Prompt arbeitet, die Doku erklärt.

SemVer für Prompts – ein Beispiel aus der Praxis

Versionsnummern vergebe ich nach Semantic Versioning. Ein Patch ist ein Formulierungs-Fix ohne Verhaltensänderung, ein Minor eine neue Fähigkeit oder ein neuer Befehl, ein Major ein Bruch – im Verhalten oder im Ausgabeformat. Das ist keine Wissenschaft, aber es zwingt mich bei jeder Änderung zu der Frage, was sie für die Nutzer des Prompts bedeutet.

Ein wichtiger Erfahrungsstrang meinerseits ist ein umfangreiches Promptsystem für Zielgruppenanalysen, das ich seit Längerem betreue (Details bleiben aus NDA-Gründen anonym). Das System war als Monolith gewachsen: ein Prompt für alles, B2B-Vertriebslogik und Consumer-Psychografie in einem Dokument. In der Praxis führte das zu Kontextverwechslungen – Lifestyle-Frameworks tauchten plötzlich in CFO-Profilen auf. Die Lösung war ein Major-Sprung: Aufteilung in zwei getrennte Systeme, eines für B2B, eines für B2C, mit gemeinsamer Basistechnik. Genau so ein Schnitt ist ohne sauberen Changelog und versionierte Stände kaum seriös machbar. Die alte monolithische Version bleibt als Legacy im Repo liegen und ist weiter lauffähig – wer sie braucht, findet sie samt Doku.

Im Alltag reicht mir bei einzelnen Prompts ein simpler Workflow mit Commits auf dem Hauptzweig. Releases und Tags kommen erst ins Spiel, wenn es umfangreicher wird, etwa bei Agentensystemen mit mehreren zusammenspielenden Prompts. Wem Git über das Terminal zu sperrig ist: GitHub Desktop leistet gute Dienste und die Oberfläche ist intuitiv. Alternativ tut es die IDE deiner Wahl – in meinem Fall Visual Studio Code, wobei ich mit dessen eingebauter Git-Funktion nie so richtig warm geworden bin, obwohl es vermutlich komfortabler wäre. Ein Nachmittag mit ein wenig Kaffee und genügend Motivation ändert dies vielleicht demnächst.

Regressionstests – die harte Realität

Die Best-Practice-Literatur koppelt Prompt-Versionierung inzwischen fest an Evaluations: Jede neue Version läuft gegen ein Testset, idealerweise automatisiert als Gate im Pull Request. Das ist richtig und Regressionstests sind auch bei mir Bestandteil des Workflows. Nur: So umfangreich, wie man es gerne hätte, ist das aus Kosten- und Zeitgründen selten durchführbar. Jeder Eval-Lauf kostet Tokens, und ein Testset zu pflegen kostet Zeit, die niemand bezahlt.

Mein Pragmatismus dazu: ein bewusst kleines Testset, das so nah wie möglich an die späteren Realdaten herankommt. Lieber fünfzehn realistische Fälle, die echte Grenzfälle abdecken, als zweihundert synthetische, die sich gegenseitig wiederholen. Das fängt nicht jede Regression. Es fängt die teuren.

Ab wann Git nicht mehr reicht

Für einzelne Prompts und kleine Systeme ist Git die Antwort, Punkt. Anders sieht es aus, sobald agentische Systeme ins Spiel kommen, ich Orchestrierung betreibe oder Prompt und Code eng verzahnt laufen. Dann will ich Prompt-Versionen mit Traces aus dem Produktivbetrieb verknüpfen können, und dafür sind dedizierte Werkzeuge gebaut. Langfuse etwa versioniert Prompts über IDs und Labels, erlaubt Rollbacks per Label-Umzug und ist Open Source sowie self-hostbar – für alle, die ihre Prompts und Traces nicht in eine US-Cloud kippen wollen, kein Nebenaspekt.

Falls ohnehin das komplette Projekt in einem Repository landet, muss ich das Prompt-System übrigens gar nicht ausgliedern und schlage zwei Fliegen mit einer Klappe: Code und Prompts teilen sich History, Issues und Review-Prozess. Der Preis: Die Prompt-History versinkt zwischen Code-Commits, und das SemVer des Prompts läuft getrennt von den Releases der Anwendung – das muss man aushalten oder per Ordner-Konvention sauber halten.

Heißt für mich: Ein Prompt, der produktiv läuft und nicht versioniert ist, ist kein Werkzeug, sondern ein Risiko mit guter Tagesform. Git kostet nichts, die Disziplin ein wenig – und der erste ernsthafte Rollback zahlt beides zurück.