Nagaraj formuliert in Towards AI eine These, die viele LLM-Teams in der Praxis laengst leben, aber selten so klar benennen: Der System-Prompt ist nicht ein Konfigurationsdetail, sondern das eigentliche Produkt. Alles drumherum -- UI, Routing, Tools, Retrieval -- ist Infrastruktur. Das, womit der Nutzer wirklich interagiert, sind die paar tausend Tokens, die vor jedem seiner Requests stehen.

Das klingt banal, hat aber eine unbequeme Konsequenz: Wenn der System-Prompt das Produkt ist, gehoert er nicht in eine Environment-Variable neben dem API-Key, sondern in einen Lifecycle mit Ownership, Versionierung, Reviews und Evals.

Warum "Produkt" und nicht "Feature"

Der Framing-Wechsel zaehlt, weil er aendert, wer verantwortlich ist und wie Aenderungen passieren. Ein Feature wird von einem Entwickler mal eben angepasst. Ein Produkt hat Changelogs, Regressions-Checks und jemanden, der es begruendet verantwortet.

In der Praxis sieht man beide Welten:

• System-Prompt als Feature: Ein Dev tunt eine Zeile, committet direkt auf main, niemand merkt den Regress, bis ein Kunde eine halluzinierte Antwort meldet. Es gibt keine Historie, kein A/B, keinen Rollback.
• System-Prompt als Produkt: Der Prompt lebt in einem eigenen Repo oder Verzeichnis, hat semantische Versionen, einen Owner, eine Testsuite und einen Release-Prozess. Jede Aenderung wird gegen Fixtures gemessen, bevor sie in Production geht.

Nagarajs Kernbeobachtung: Vage Prompts fuehren zu generischen Antworten. Wer die Rolle, den Stil, die Grenzen und das Ausgabeformat nicht sauber festlegt, bekommt den Mittelwert aller Trainingsdaten zurueck. Und dieser Mittelwert ist selten ein Produkt, das jemand bezahlen will.

Wie ein guter System-Prompt strukturiert ist

Es gibt keine einzig wahre Struktur, aber ein wiederkehrendes Muster hat sich bewaehrt:

• Rolle: Wer ist das Modell in dieser App? Nicht "Du bist ein hilfreicher Assistent", sondern "Du bist ein Compliance-Prüfer für Leasingvertraege nach deutschem Recht". Je spezifischer, desto konsistenter die Antworten.
• Ziel und Nicht-Ziele: Was soll das Modell tun -- und explizit: was nicht? Nicht-Ziele sind häufig wichtiger als Ziele, weil sie die Antwort eingrenzen.
• Input-Erwartung: Welche Felder, Formate und Sonderfaelle kommen rein? Was macht das Modell, wenn ein Feld fehlt?
• Regeln und Constraints: Harte Regeln (Zahlen nicht erfinden, keine PII nach draussen, nur Deutsch antworten) gehoeren an den Anfang und werden mit imperativen Formulierungen explizit gemacht.
• Output-Schema: Bei strukturierten Antworten ein formales Schema (JSON-Schema, XML-Tags, Beispiele). Bei Prosa-Antworten konkrete Stil- und Laengenvorgaben.
• Few-Shot-Beispiele: Zwei bis vier Beispiele, die auch Edge-Cases abdecken -- gerade die, bei denen das Modell sonst ins Generische faellt.
• Fallback-Verhalten: Was passiert bei Unsicherheit? Abbruch, Rueckfrage, Eskalation? Diese Zeile rettet in Production regelmaessig den Tag.

Schlechte Prompts erkennt man daran, dass sie Adjektive statt Verhalten beschreiben: "Sei professionell, hilfreich und genau." Gute Prompts ersetzen Adjektive durch beobachtbare Kriterien: "Antworte in maximal drei Saetzen, zitiere die Paragraphennummer, verweise bei Unsicherheit auf einen Menschen."

Versionierung und Evals

Wenn der System-Prompt das Produkt ist, braucht er die Werkzeuge eines Produkts:

• Versionierung: Prompt-Dateien unter Git, semantisch versioniert. Jede Production-Antwort lässt sich später auf eine konkrete Prompt-Version zurückführen -- nicht als Rekonstruktion, sondern per ID im Log.
• Fixtures: Eine wachsende Sammlung realer oder realistischer Inputs mit gewuenschten Outputs. Das ist die Basis jeder ernstzunehmenden Prompt-Arbeit. Ohne Fixtures ist jede Aenderung Bauchgefuehl.
• Evals: Automatisierte Metriken gegen die Fixtures -- Exact-Match bei strukturierten Outputs, LLM-as-Judge bei Prosa, Custom-Checks für Format- und Regel-Compliance. Ein Prompt-Change ohne Eval-Delta ist kein Merge-Kandidat.
• Regressions-Set: Jeder in Production entdeckte Fehler wird zum permanenten Testfall. So wird der Prompt über Zeit härter statt weicher.
• A/B und Shadow Mode: Neue Prompt-Versionen laufen zuerst parallel zur alten, ohne die Antwort auszuliefern. Die Differenz wird protokolliert und ausgewertet, bevor umgeschaltet wird.
• Rollback: Ein Prompt-Rollback muss so einfach sein wie ein Code-Rollback -- eine Zeile im Deployment, nicht ein Panik-Hotfix.

Ein nuetzlicher Test in der Praxis: Kann jemand, der nicht Teil des Prompt-Teams ist, die Eval-Suite auschecken und nachvollziehen, warum die aktuelle Version besser ist als die vorherige? Wenn nein, ist der Prompt noch kein Produkt.

Einordnung

Die These passt zu einer Reihe aktueller Bewegungen. Claude Skills und vergleichbare Ansaetze schieben wiederverwendbare Prompts bewusst aus dem App-Code in eigene Artefakte mit Lifecycle (siehe Expertise als wiederverwendbaren AI-Skill kodifizieren). MCP verlagert Tool- und Kontext-Definitionen aus dem Prompt in ein standardisiertes Protokoll -- und macht damit den verbleibenden Prompt schaerfer beobachtbar. Context Engineering behandelt den Kontext-Aufbau als eigene Disziplin (Context Engineering), und Harness Engineering die deterministische Schale drumherum.

All diese Bewegungen haben einen gemeinsamen Nenner: Sie nehmen ernst, dass das, was das Modell sieht, das eigentliche Produkt ist. Der System-Prompt steht im Zentrum dieser Sichtweise. Wer ihn als Wegwerf-Konfiguration behandelt, baut seine App auf einem Fundament, das niemand besitzt.

Quellen

• Your System Prompt Is the Product -- Not the Feature | Nagaraj, Towards AI