Grundlagen: der Übergang von Prompts zu Programmen

Klassische Software gibt Ihnen ein Versprechen, mit dem Sie planen können: Derselbe Input erzeugt denselben Output, Sie testen einmal und liefern aus. Prompt-basierte Software bricht dieses Versprechen. Dieselbe Anfrage kann mehrere unterschiedliche gültige Ergebnisse erzeugen. Eine erfolgreiche Demo ist also kein Beleg dafür, dass das Feature in Produktion funktioniert, und ein grüner Testlauf ist kein Beleg dafür, dass er morgen noch grün ist. Die Arbeit verschwindet nicht, sie verlagert sich: weg vom Schreiben jeder einzelnen Anweisung, hin dazu, zu definieren, was ein gültiges Ergebnis ist, und zu belegen, dass das System es erreicht.

Lassen Sie die KI semantische und kreative Details entscheiden.
Lassen Sie sie keine Permissions, Lifecycle-Regeln, Erfolgskriterien oder irreversiblen Aktionen erfinden.

Wenn etwas schiefgeht, ist die instinktive Reaktion, den Prompt umzuschreiben. Das erzeugt einen endlosen Kreislauf: Jede Änderung behebt einen Fall, bricht still einen anderen und hinterlässt keine Nachvollziehbarkeit, warum sich das System so verhält. Teams, die stattdessen Validierung, Permissions, Retries und Limits in normalen Code legen, bekommen Fehler, die reproduzierbar, erklärbar und einmalig behebbar sind. Die Grenze zwischen beiden ist die folgenreichste Architekturentscheidung im gesamten System.

Ein produktionsreifes Prompt-Feature hat sieben Teile: Spezifikation, Anweisungen, Kontext, State, Tools und Permissions, Evaluation und Governance. Nur einer davon ist der Prompt. Wenn ein Team Ihnen den Prompt und sonst nichts zeigen kann, stecken die anderen sechs in einzelnen Köpfen. Genau deshalb lassen sich solche Features so schwer übergeben, prüfen oder reproduzieren, sobald die Person, die sie gebaut hat, geht. Das ist ganz normales Key-Person-Risiko in neuem Gewand.

Nahezu die gesamte Systemlogik lässt sich im Voraus deklarieren. Ein kleiner Teil aber wirklich nicht, weil er von Urteilsvermögen, Geschmack oder Situationen abhängt, die noch niemand gesehen hat. Beides zu verwechseln, ist in beide Richtungen teuer: offenes Urteilsvermögen zu deklarieren, erzeugt starre Regeln, die an echten Nutzern scheitern; deklarierbare Regeln dem Modell zu überlassen, erzeugt variables Verhalten genau dort, wo nichts variieren darf, etwa bei Preisen, Permissions und Lifecycle. Die Klassifizierung bestimmt außerdem, wie die Arbeit getestet werden muss.