// SOFTWARE
Prompts im Code: die neue Form technischer Schuld
6 Min. Lesezeitnijitech
Verteilen sich Modell-Prompts über den Quellcode, wird jede Textänderung zu einem Release. Das ist genau das, was vor zehn Jahren mit SQL-Abfragen passierte.
Ganzer Beitrag
In einer Anwendung, die um eine KI-Funktion erweitert wird, landen Prompts meist an der praktischsten Stelle: in der Funktion, die den Aufruf macht. In der ersten Woche ist das die richtige Entscheidung — schnell und funktionierend. Im sechsten Monat hat dieselbe Entscheidung den am langsamsten veränderbaren Teil des Produkts hervorgebracht.
Eine vertraute Geschichte. Vor zehn Jahren steckten auch SQL-Abfragen im Anwendungscode, und jede Abfrageänderung verlangte ein Deployment. Das Ergebnis ist dasselbe: Eine Textänderung wird zur Engineering-Aufgabe.
Vier Kosten eines fest verdrahteten Prompts
Was in der Praxis passiert
- Für eine Korrektur von einem Wort muss ein Release veröffentlicht werden
- Dieselbe Anweisung wird in mehrere Dateien kopiert; eine wird aktualisiert, die andere vergessen
- Es ist nicht sichtbar, welcher Prompt wann geändert wurde — die Ursache einer Verhaltensänderung ist nicht auffindbar
- Die Person, die den Text schreiben sollte (die Fachexpertin), hat keinen Zugriff auf die Datei
Der vierte Punkt ist der heimtückischste. Ein Prompt ist im Grunde ein Produkttext: Ton, Umfang und Grenzen verlangen Fachwissen. Steckt er im Code, ist die Befugnis, diesen Text zu schreiben, genau der Person entzogen, die ihn schreiben sollte.
Ein Prompt ist Konfiguration
Die Lösung ist nicht kompliziert: Prompts liegen getrennt vom Code an einem versionierten Ort, und die Anwendung ruft sie über eine Kennung ab. Von da an ist eine Promptänderung eine Konfigurationsaufgabe, keine Deployment-Aufgabe.
Versionierung macht Änderungen zurücknehmbar
Ändert sich ein Prompt, ändert sich das Verhalten — und manchmal wird es schlechter. Wird keine Version geführt, gibt es auch keinen Punkt zum Zurückkehren; es bleibt nur die Beobachtung „gestern war es besser".
Hier entsteht die Verbindung zum Evaluationsset. Liegen ein versionierter Prompt und ein lauffähiges Eval-Set zusammen vor, lässt sich bei jeder Änderung messen, welche Kategorie zurückgefallen ist. Fehlt eines von beiden, ist auch die Messung unvollständig.
Was beim Modellwechsel passiert
Modelle veralten, und wenn eine günstigere oder stärkere Version erscheint, will man wechseln. Sind die Prompts über den Code verstreut, wird der Wechsel zu einer Suchen-und-Ersetzen-Operation, und es muss einzeln ausprobiert werden, wie sich welcher Prompt im neuen Modell verhält.
Liegen die Prompts an einem Ort, ist derselbe Wechsel eine Konfigurationsänderung plus ein Eval-Lauf. Der Unterschied liegt zwischen Stunden und Tagen.
Wo anfangen
Die ersten drei Schritte
- Sammeln Sie alle Prompt-Texte der Codebasis an einem Ort — zunächst nur verschieben
- Geben Sie jedem Prompt eine Kennung und eine Versionsnummer
- Schreiben Sie die nächste Änderung als neue Version; löschen Sie die alte nicht
Keiner der drei Schritte verlangt eine Architekturänderung. Der Gewinn zeigt sich an dem Tag, an dem zum ersten Mal etwas zurückgenommen werden muss.
Aus dem Glossar: Modellorchestrierung · Bewertungssatz (Eval)