Sich selbst verbessernde App: geschlossener Verbesserungszyklus

1. Warum die App einen geschlossenen Verbesserungszyklus braucht

Jede LLM‑App lebt in einer sich verändernden Welt. Ihr bekommt neue Nutzer und Szenarien, OpenAI rollt neue Modelle und Schutzmechanismen aus, ihr selbst aktualisiert den MCP‑Server, das Agents SDK, ein UI‑Widget … Und selbst wenn der gesamte Code perfekt geschrieben wäre (ja, ja, ich weiß, dass ihr es fast so macht), kann ein Modell‑ oder Prompt‑Wechsel unbemerkt die Hälfte der Use Cases zerschießen.

Ohne Verbesserungszyklus sieht der Alltag so aus: Ein Nutzer schreibt dem Support: „GiftGenius fängt an, Geschenke über dem Budget vorzuschlagen“ oder „sitzt und denkt 15 Sekunden lang“. Ihr öffnet die Logs, ändert irgendetwas im System‑Prompt, schaltet das Modell um, deployed. Eine Woche später wiederholt sich alles – nur an einer anderen Stelle. Am Ende habt ihr einen chronischen Brand und einen Haufen „magischer“ Änderungen, die niemand erklären kann.

Mit dem Zyklus ist alles anders. Ihr habt:

• einen klaren Satz von Signalen zu Technik, Kosten, Produkt und Qualität;
• ein regelmäßiges Ritual: sie ansehen und Hypothesen auswählen;
• kontrollierte Änderungen in Code/Config;
• automatische Checks: Golden‑Cases + LLM‑Evals + Experimente.

Dann wird die App aus einem „eingefrorenen Prompt“ zu einem lebendigen System, das:

• zeigt, wo es weh tut und warum;
• vorschlägt, was genau man verbessern kann;
• vor stiller Degradation nach einer „harmlosen“ Prompt‑Änderung schützt.

Bonus: Ein solcher Zyklus passt hervorragend zu allem, was ihr in den vorherigen Modulen bereits gebaut habt. Logs und SLO aus M17 liefern technische Signale, Cost‑Instrumentierung und AARRR aus M19 – wirtschaftliche und produktbezogene, Golden‑Cases und LLM‑Evals aus M20.1–2 liefern Qualitätssignale. Es bleibt nur, das in einen verständlichen operativen Zyklus zu verbinden.

2. Signal‑Landkarte für Verbesserungen

Damit die App selbst vorschlagen kann, wo sie verbessert werden sollte, muss klar sein, welche Signale es überhaupt gibt und woher sie stammen. Es ist praktisch, in vier Gruppen zu denken.

Technische Signale kommen aus eurem Observability‑Stack: Logs tool_invocation, die Metriken Latenz und Error‑Rate, Health‑Checks von MCP/ACP, OAuth‑Fehler. Sie beantworten die Frage „lebt der Dienst und wie stabil ist er“.

Wirtschaftliche Signale entstehen in der Cost‑Instrumentierung und im Billing: cost_per_tool_call, cost_per_task, cost_per_user, unerwartete Kostenpeaks bei bestimmten Tools oder Szenarien. Sie sagen: „Wir verbrennen mehr Tokens und Geld als erwartet“ oder umgekehrt: „Es gibt Spielraum, Qualität zu verbessern.“

Produktsignale werden aus Events wie app_opened, workflow_started, workflow_completed, checkout_* gebildet. Das sind Activation‑Rate, Konversionsraten zwischen den Funnel‑Schritten, Retention nach Kohorten. Sie zeigen, was im realen Nutzerverhalten passiert.

Qualitäts‑ und Verhaltenssignale umfassen die Ergebnisse von LLM‑Evals auf Golden‑Cases (Scores für Correctness/Helpfulness/Style/Safety), stichprobenartige manuelle Dialog‑Reviews, Daumen hoch/runter, Beschwerden und Rezensionen im Store. Das ist das, was dem Gefühl „Die App ist schlauer/dümmer geworden“ am nächsten kommt.

Praktisch ist es, das in einer Tabelle zu sammeln:

Der Schlüsselpunkt: Alle diese Signale werden mit Bezug auf ein konkretes Szenario und eine App‑Version geloggt. Das heißt, in Events tauchen mindestens scenario, appVersion und experimentId auf. Seht ihr dann, dass die Helpfulness auf den Golden‑Cases von 8.5 auf 6.2 gefallen ist, könnt ihr nicht nur sagen „es wurde schlechter“, sondern „es wurde im Szenario "gift_selection" nach Release "1.3.0" im Experiment‑Variant "B" schlechter“.

Im Code kann man sogar eine einfache Struktur zur Beschreibung eines Signals einführen:

// lib/improvement/signals.ts
export type SignalKind = "slo" | "cost" | "product" | "quality";

export type ImprovementSignal = {
  kind: SignalKind;
  scenario: string;       // z. B. "gift_selection"
  metric: string;         // z. B. "p95_latency_ms", "cost_per_task"
  value: number;
  previous?: number;      // Wert "vorher"
};

Solche Objekte lassen sich bequem sowohl an Dashboards als auch an euren zukünftigen Verbesserungsassistenten verfüttern.

3. Kanonischer Feedback‑Loop: 4 Schritte

Bauen wir nun den kanonischen Verbesserungszyklus, auf den ihr jedes Mal zurückgreifen könnt. Er ist sehr bodenständig: vier Schritte.

flowchart TD
  A[Signal: etwas tut weh
oder es gibt eine Wachstumschance] --> B[Hypothese:
was wir wie ändern]
  B --> C[Kontrollierte Änderung
in Code/Config]
  C --> D[Prüfung:
offline + online]
  D --> A

Schritt 1. Problem oder Chance entdecken

In diesem Schritt beantwortet ihr die Frage „wohin schauen“. Beispiele:

• LLM‑Eval auf Golden‑Cases mit Budget zeigt einen Rückgang der Helpfulness.
• p95 latency beim Tool "suggest_gifts" stieg von 1.2 s auf 3.8 s.
• cost_per_task im Szenario "gift_selection" stieg um 40 % nach dem Wechsel auf ein Reasoning‑Modell.
• Die Konversion workflow_completed → checkout_success ist um 5 Prozentpunkte gesunken, nachdem der UX‑Wizard geändert wurde.
• Im Store gab es in einer Woche 10 Beschwerden „Geschenke sind teurer als das angegebene Limit“.

Wichtige Nuance: Manchmal sagt ein Signal nicht „schlecht“, sondern „kann besser werden“. Beispielsweise seht ihr, dass cost_per_task deutlich unter dem zulässigen Schwellenwert liegt, während der Quality‑Score schon 9/10 beträgt. Dann kann man ein teureres Modell oder ein „intelligenteres“ Szenario ausprobieren – vielleicht steigt die Konversion.

Schritt 2. Eine Hypothese formulieren

Eine Hypothese ist nicht „wir schreiben den Prompt um“, sondern „wir glauben, dass die konkrete Änderung X in Komponente Y die Metrik Z verbessert, weil …“. Ohne „weil“ ist es keine Hypothese, sondern ein Wunsch.

Beispiele:

• „Wenn wir im System‑Prompt eine Regel zur strikten Einhaltung des Budgets festlegen und immer um eine Erklärung bitten, wie das Budget genutzt wurde, steigt die Helpfulness in Budget‑Cases um mindestens 2 Punkte.“
• „Wenn wir das teure Modell im Rerank‑Schritt durch "gpt-mini" ersetzen, sinkt cost_per_task um 30 %, und die Konversion fällt nicht um mehr als 1 Prozentpunkt.“
• „Wenn wir den Wizard vereinfachen (zwei Schritte zu einem zusammenfassen) und den CTA neu schreiben, steigt die Activation‑Rate um 5 Prozentpunkte.“

Im Code lässt sich eine solche Hypothese bequem explizit beschreiben, zumindest als Objekt:

// lib/improvement/hypothesis.ts
export type ImprovementHypothesis = {
  id: string;
  scenario: string;
  description: string;   // "Was wir ändern und warum"
  targetMetric: string;  // z. B. "quality.helpfulness" oder "conversion.checkout"
  successCriteria: string;
};

Ja, das ist fast wie ein Jira‑Ticket, aber immerhin typisiert.

Schritt 3. Eine kontrollierte Änderung durchführen

Hier sind zwei Wörter wichtig: kontrolliert und getrennt.

Kontrolliert bedeutet, dass die Änderung als PR/Commit erfolgt, an die Hypothese gebunden ist, ein Changelog hat und nach Möglichkeit Feature‑Flag oder Version nutzt. Ihr habt nicht einfach „den Prompt in Produktion angepasst“, sondern könnt sagen, welcher Release das gebracht hat.

Getrennt bedeutet, dass ihr versucht, nicht drei unterschiedliche Hypothesen in einem Release zu mischen. Wenn ihr gleichzeitig:

• das Modell wechselt,
• die Hälfte des System‑Prompts umschreibt
• und einen neuen UX‑Schritt hinzufügt,

ist es selbst bei besseren Metriken schwer zu verstehen, was genau gewirkt hat. Viel ehrlicher ist es, in kleinen Portionen vorzugehen.

Technisch können die Änderungen überall stattfinden:

• System‑Prompt des Agenten (lib/prompt/systemPrompt.ts);
• Beschreibungen der MCP‑Tools (description, inputSchema, annotations);
• Agent‑Config (Limits für Reasoning‑Schritte, Modellwahl für ein bestimmtes Tool);
• Widget‑Code (CTA, Schrittfolge, Fehlermeldungstexte).

Schritt 4. Prüfen, ob es besser wurde

Die Prüfung teilt sich in offline und online.

Offline‑Prüfung – das ist der Lauf der Golden‑Cases durch die neue App‑Version ohne echte Nutzer. Hier habt ihr bereits:

• LLM‑Evals (Modul 20.1);
• Threshold/Baseline‑Logik (Modul 20.2).

Ihr schaut, wie sich die Quality‑Scores in den Ziel‑Szenarien verändert haben: gestiegen, gefallen, gleich geblieben. Außerdem prüft ihr Safety‑Cases: Jegliche Prompt‑Änderungen müssen zuerst den Safety‑Satz bestehen.

Online‑Prüfung – das ist ein Experiment am echten Traffic. Im einfachsten Fall schaltet ihr die neue Version für N % der Nutzer frei und vergleicht:

• die Konversion in die Zielaktion (Checkout, erneuter Start des Szenarios);
• cost_per_task;
• Beschwerden/Feedback.

Danach wird der Zyklus entweder geschlossen (Hypothese bestätigt/widerlegt und dokumentiert) oder erzeugt eine neue Hypothese.

4. Interner „Verbesserungsassistent“ als separater Agent

Jetzt das Spannendste: Geben wir dem LLM‑Modell noch eine Rolle – nicht nur Nutzern zu antworten, sondern auch euch zu helfen, die App zu verbessern. Das ist ein interner Agent, getrennt vom Nutzer‑GiftGenius.

Was ist das für ein Wesen

Dieser Assistent lebt in eurer internen Umgebung (im selben Repo, im Dev‑Mode, in einer separaten ChatGPT‑App). Er:

• liest Logs und Stichproben von Dialogen;
• schaut auf Metriken;
• analysiert den System‑Prompt und die Tool‑Beschreibungen;
• hilft, Probleme und Änderungsvorschläge zu formulieren.

Im Grunde bekommt ihr einen „virtuellen Product‑Manager/Analysten“, der:

• nicht müde wird, Dialoge zu lesen;
• schnell wiederkehrende Muster findet;
• Entwürfe für Prompts und Changelog schreiben kann.

Welche Eingaben er erhält

Es ist hilfreich, den Input zu formalisieren, damit es der Agent leichter hat. Zum Beispiel dieser Typ:

// lib/improvement/assistant.ts
export type BadDialogExample = {
  id: string;
  userMessages: string[];
  appMessages: string[];
  qualityScore?: number;
};

export type ImprovementInput = {
  scenario: string;
  signals: ImprovementSignal[];      // aus dem vorherigen Abschnitt
  examples: BadDialogExample[];
  systemPrompt: string;
  toolsDescription: string;
};

Ihr könnt ein solches Objekt bauen, indem ihr aus den Logs 10–20 misslungene Dialoge für das Szenario "gift_selection" zieht und den aktuellen System‑Prompt sowie die Tool‑Beschreibungen anhängt.

Welche Ausgabe er liefern soll

Ebenso ist es sinnvoll, die erwartete Antwort festzulegen:

export type ImprovementSuggestion = {
  patterns: string[];     // wiederkehrende Probleme
  promptPatches: string[]; // Vorschläge für Fragmente des System-Prompts
  toolsPatches: string[];  // Ideen für Tool-Beschreibungen
  uxCopyIdeas: string[];   // Varianten für UX-Texte
  changelog: string[];     // kurze Liste "was zu ändern ist"
};

Der Meta‑Prompt für einen solchen Agenten wäre ungefähr:

• „Analysiere Beispiele und Signale“;
• „beschreibe 2–3 Problemmuster“;
• „schlage je 1–2 Änderungen im Prompt, in den Tool‑Beschreibungen und in den UX‑Texten vor“;
• „liefere alles in strikt definiertem JSON“.

Danach übernehmt ihr diese Fragmente manuell, besprecht sie im Team, integriert sie in den Code und lasst sie durch Evals und Experimente laufen. Wichtiges Prinzip: Dieser Assistent ändert nichts selbst in der Produktion. Er generiert Ideen und Text, aber keine Commits.

5. Änderungstypen: Was man überhaupt „tunen“ kann

Wenn es diesen Assistenten und einen klaren Zyklus gibt, ist es sehr leicht, alles auf „schick mir eine neue Version des System‑Prompts“ zu reduzieren. In Wirklichkeit ist der Verbesserungsraum viel breiter.

Prompt und Anweisungen

Der System‑Prompt legt Rolle, Ton, Prioritäten und harte Regeln fest (z. B. Budget, Safety, Reihenfolge der Schritte). Man kann ihn:

• vereinfachen, indem widersprüchliche oder doppelte Anweisungen entfernt werden;
• verstärken, indem fehlende Regeln ergänzt werden (wie im Budget‑Beispiel);
• an verschiedene Szenarien anpassen (separate Sub‑Prompts für "gift_selection", "post_purchase_help" usw.).

Tool‑Beschreibungen helfen dem Modell zu verstehen, wann ein bestimmtes Tool aufzurufen ist und was es tut. Hier laufen Verbesserungen oft hinaus auf:

• expliziteres „Use this when … / Do not use when …“;
• präzisere Formulierungen (weniger Überschneidung mit anderen Tools);
• Information über Konsequenzen ergänzen (destructiveHint, isConsequential).

Safety‑Regeln sind der Teil des Prompts/der Beschreibungen, der für das Verhalten in schwierigen Domänen verantwortlich ist. Man sollte sie nur nach guten Safety‑Evals anfassen.

Verhaltensarchitektur (Behavior)

Manchmal lässt sich ein Problem nicht mit dem Prompt lösen: Man muss die Abfolge der Aktionen ändern.

Beispiele:

• einen obligatorischen Schritt zur Präzisierung von Parametern vor dem Aufruf eines teuren Tools hinzufügen;
• einen Teil der Berechnungen in einen separaten, günstigeren Schritt auslagern (z. B. eine Vorfilterung im Backend);
• die Anzahl aufeinanderfolgender Tool‑Aufrufe in einem Szenario begrenzen.

Diese Änderungen werden normalerweise in der Agent‑Config oder der MCP‑Schicht beschrieben, nicht nur im Prompt.

UX und Copywriting

Ja, Texte auf Buttons und in Fehlermeldungen sind ebenfalls Teil der Qualität. Ein GiftGenius, der schreibt:

„Fehler 500. Wenden Sie sich an den Administrator.“,

erzeugt einen ganz anderen Eindruck als:

„Wir konnten keine Antwort vom Shop erhalten. Ihre ausgewählten Ideen sind nicht verloren gegangen, versuchen Sie den Kauf etwas später erneut.“.

Zwischen‑Screens, Hinweise, Wizard‑Strukturen – all das beeinflusst die Activation‑Rate und die Konversionen, die ihr messt.

Ökonomie

Hier spielen wir das bekannte Spiel „Qualität ↔ Kosten“:

• Modellwahl (teures mit Reasoning, schnelles/günstiges);
• Tiefe von Reasoning/Agent‑Schritten (wie viele Iterationen erlaubt sind);
• Dialoglimits (z. B. nicht mehr als N Neuberechnungen pro Session);
• „günstige“ Fallback‑Modi, wenn das Token‑/Limit‑Budget ausgeschöpft ist.

Die Signale fließen in cost_per_task, cost_per_user, Marge und werden mit dem Quality‑Score zusammengeführt.

6. Guardrails: Was man nicht der LLM überlassen darf

Wenn ein „Verbesserungsassistent“ und ein bequemer Zyklus in der Systemlandschaft auftauchen, ist die Versuchung groß, auf „Auto‑Optimierung“ zu drücken und Kaffee zu trinken. Einigen wir uns direkt darauf, wo so ein Button verboten ist.

Änderungen an Berechtigungen (OAuth‑Scopes, MCP‑Tools, Datenzugriffe) – das ist immer human‑in‑the‑loop. Kein Modell darf selbst entscheiden, dass die App nun Bestellungen lesen, Zahlungen anfassen oder E‑Mails an Nutzer senden darf. Gleiches gilt für Commerce‑Flows: Jegliche Änderungen rund um ACP/Stripe, Limits, Zahlungsarten und Rückerstattungen durchlaufen menschliches Review und Tests.

Der Safety‑Profil der App (in welchen Domänen sie Ratschläge geben darf, wo sie ablehnen muss) ist ebenfalls nichts, was man einer LLM überlassen sollte. Das Modell kann helfen, Regeltexte zu formulieren, aber die Entscheidung, welchen Themen ihr der App vertraut, liegt bei euch.

Daten‑ und Logging‑Policy (was geloggt wird, wie lange gespeichert wird, wie auf Löschanfragen reagiert wird) – steht auf derselben Liste. Eine LLM kann die Struktur einer Privacy Policy vorschlagen, darf aber Retention im Code nicht ohne euch ändern.

Was lässt sich halbautomatisieren? Formulierungen und Wording von Prompts, Tool‑Beschreibungen und UX‑Texten, Tool‑Prioritäten (in vernünftigen Grenzen), zusätzliche Nachfragen. All das kann dem Assistenten als Ideengeber überlassen werden, aber das letzte Wort und die Prüfung liegen bei Menschen und Eval‑Skripten.

7. End‑to‑End‑Beispiel eines Verbesserungszyklus (GiftGenius)

Kehren wir zu unserem Helden zurück.

Problem

Der Nutzer gibt ein Budget an, aber GiftGenius schlägt oft Geschenke vor, die dieses Limit überschreiten. In den Logs sieht man viele Dialogfortsetzungen wie „nein, das ist zu teuer“ und „mach es günstiger“.

Signale

Zuerst seht ihr die Qualität: LLM‑Eval auf Golden‑Cases vom Typ „wähle ein Geschenk bis 50 $“ ergibt eine Helpfulness von etwa 6/10. Der Richter schreibt regelmäßig in reason, dass „Geschenke das Budget überschreiten“ oder „nicht erklärt ist, wie das Budget berücksichtigt wurde“.

Produkt‑ und Wirtschaftssignale kommen parallel:

• die Konversion in checkout_success ist in Szenarien mit vorgegebenem Limit niedriger als ohne Limit;
• ein Teil der Nutzer bricht das Szenario ab, nachdem er zu teure Optionen gesehen hat;
• cost_per_task ist in solchen Szenarien höher, weil die App auf die Bitte „mach es günstiger“ mehrere Neuberechnungen der Geschenke durchführt.

Analyse mit Hilfe des Verbesserungsassistenten

Ihr sammelt 20 Dialoge, in denen Nutzer sich über den Preis beschwerten, und formt ein ImprovementInput:

• scenario = "gift_selection_with_budget";
• signals mit fallender Helpfulness und Konversion;
• examples mit Dialogen;
• aktueller System‑Prompt und Tool‑Beschreibungen.

Ihr gebt das an den internen Verbesserungsagenten. Als Antwort liefert er beispielsweise:

• Muster:
  • ein Budget wie „ungefähr bis 50 $“ wird zu großzügig interpretiert;
  • der System‑Prompt enthält nicht die explizite Anforderung „niemals Geschenke über dem Limit vorschlagen“;
  • die Antworten erklären dem Nutzer nicht, wie das Budget berücksichtigt wurde.
• Vorschläge:
  • eine Anweisung zur strikten Einhaltung des Limits in den System‑Prompt aufnehmen;
  • das Modell bitten, immer zu sagen, dass „alle Optionen ≤ X“ sind;
  • eine Rückfrage hinzufügen, wenn das Budget vage klingt („ungefähr“, „etwa“).

Hypothese und Änderung

Ihr formuliert die Hypothese:

„Wenn wir die strikte Einhaltung des Limits explizit festschreiben und um eine Erklärung der Budgetnutzung bitten, steigt die Helpfulness in Budget‑Cases auf mindestens 8/10, und die Konversion zum Kauf steigt um 3 Prozentpunkte.“

Ihr fügt dem System‑Prompt folgendes Fragment hinzu:

export const budgetRule = `
Wenn der Nutzer ein Budget angibt (z. B. "bis 50 $" oder "ungefähr 30 €"),
behandle diesen Betrag als STRIKTE Obergrenze.

Schlage niemals Optionen über diesem Limit vor.
Stelle in jeder Antwort ausdrücklich klar, dass alle Vorschläge innerhalb des Budgets liegen
und wie genau (z. B.: "alle Geschenke kosten höchstens 45 $").
`.trim();

Und ihr fügt budgetRule dem allgemeinen System‑Prompt von GiftGenius hinzu.

Offline‑Validierung

Ihr lasst den Satz Golden‑Cases „Geschenke mit Budget“ durch die neue Version laufen:

• LLM‑Eval‑Helpfulness steigt von 6.0 auf 8.5;
• Correctness steigt ebenfalls: das Budget wird eingehalten;
• Safety verschlechtert sich nicht (zumindest nicht).

Wenn umgekehrt die Helpfulness nicht steigt oder Safety fällt – kommt die Änderung nicht durch und die Hypothese wird überarbeitet.

Online‑Test

Dann startet ihr ein Experiment:

• 10 % der Nutzer bekommen die neue Prompt‑Version (Variante B);
• die restlichen 90 % – die alte (Variante A).

Nach einer Woche schaut ihr:

• die Konversion workflow_completed → checkout_success beträgt für B z. B. 13 % statt 10 % bei A;
• cost_per_task hat sich kaum verändert;
• der Anteil der Dialoge mit Beschwerden „zu teuer“ ist gesunken.

Das Experiment gilt als erfolgreich.

Verankerung

Danach:

• rollt ihr den neuen Prompt auf 100 % des Traffics aus;
• fügt ihr einen neuen Golden‑Case „weiches Budget bis 50 $“ zum Regression‑Satz hinzu;
• fixiert ihr das Ergebnis im Changelog und ggf. in Tech‑Notes: damit in sechs Monaten klar ist, warum es im Prompt eine so strikte Budget‑Formulierung gibt.

Der Zyklus ist geschlossen. Die nächste Iteration kann sich z. B. auf Empfehlungen für Menschen mit sehr seltenen Hobbys oder die Kostenoptimierung der Auswahl beziehen.

8. Mini‑Roadmap für die sich selbst verbessernde App

Damit das nicht wie „noch 100 500 Aufgaben obendrauf“ wirkt, ist es hilfreich zu sehen, welches Minimum nötig ist, damit die App bereits als sich selbst verbessernd gilt – und was man später ergänzen kann.

Version 1.0: Minimaler Improvement‑Loop

Im ersten Schritt reichen drei Dinge.

Erstens: strukturierte Logs und grundlegende SLO. Ihr könnt bereits tool_invocation, workflow_completed, checkout_* mit requestId, userId, scenario, appVersion, costEstimateUsd loggen. Darauf bauen SLO auf: Latenz, Error‑Rate, Checkout‑Erfolg.

Zweitens: 10–20 Golden‑Cases und ein LLM‑Eval‑Skript. Ein kleiner, aber gut zusammengestellter Satz Beispiele für die Schlüsselszenarien + Safety‑Cases. Ein CLI‑Skript, das sie durch App und Richter laufen lässt und JSON‑Scores ausgibt.

Drittens: ein einfaches Ritual alle zwei Wochen. Hinsetzen (allein oder mit dem Team), öffnen:

• 2–3 Dashboards zu SLO, Kosten, Produktmetriken;
• den LLM‑Eval‑Report zu den Golden‑Cases;

und 1–2 Hypothesen für den nächsten Zyklus auswählen. Formulieren, dokumentieren, einen kleinen Release machen, prüfen.

Version 2.0: „smarter“ Improvement‑Loop

Auf der nächsten Stufe erscheinen:

Interner Verbesserungsassistent. Das ist ein separat beschriebener Agent (oder eine ChatGPT‑App), der ImprovementInput annimmt und ImprovementSuggestion zurückgibt. Er hilft euch, nicht Stunden mit dem manuellen Durchgehen von Dialogen zu verbringen.

Automatisierte Reports. Auf Basis von Logs und Evals lassen sich generieren:

• Cluster problematischer Cases (z. B. alle Fälle, in denen der Nutzer das Budget neu formuliert hat);
• ready‑to‑use Entwürfe für Prompt‑ und Tool‑Beschreibung‑Änderungen;
• ein kurzer Changelog.

CI‑Hooks. Jede Änderung an Prompts, Agent‑Configs, Tool‑Descriptions startet automatisch:

• die funktionale Golden‑Suite;
• die Safety‑Suite.

Wenn Safety‑Cases fallen oder die Qualität der Schlüsselszenarien die Schwellen nicht mehr besteht – ist der Build rot, kein Release.

9. Praxis

Übung 1. Mini‑Feedback‑Loop für eure App

Nehmt ein Schlüsselszenario eurer Anwendung. Für GiftGenius haben wir bereits „Auswahl und Kauf eines Geschenks“ gewählt, ihr könnt ein ähnliches oder euer eigenes nehmen.

Beschreibt frei (oder legt eine kleine improvement-plan.md an):

Welche Signale ihr verfolgen werdet. Je eins:

• technisch: z. B. p95 latency für das Tool, das die Hauptarbeit macht;
• wirtschaftlich: cost_per_task für dieses Szenario;
• produktbezogen: Konversion workflow_started → workflow_completed oder bis zur Zielaktion;
• qualitativ: mittlerer quality_score über mehrere Golden‑Cases für dieses Szenario.

Legt als Nächstes fest, welche Schwellen ihr als Degradation betrachtet. Nicht „schauen wir irgendwann“, sondern ganz konkret:

• p95 > 5 Sekunden – schlecht;
• cost_per_task ist um mehr als 30 % gestiegen ohne Umsatzwachstum – Alarm;
• quality_score ist unter 7 gefallen – wir müssen es untersuchen.

Und formuliert die erste Hypothese. Zum Beispiel:

„Ich vermute, dass wir zu viele Rückfragen stellen. Wenn wir den Wizard um einen Schritt kürzen und die Fragen etwas allgemeiner machen, steigt die Activation‑Rate und die Helpfulness leidet kaum. Ich überprüfe das mit einer kleinen UX‑Änderung und einem A/B‑Experiment.“

Das ist nicht einfach „wir verbessern die UX“, sondern ein konkreter Schritt im Zyklus.

Übung 2. Meta‑Prompt für den Verbesserungsassistenten

Versucht, einen Prompt‑Text für den internen Verbesserungsagenten eurer App zu skizzieren. Ihr könnt einfach anfangen:

• Beschreibt, wer er ist: „Du bist der Qualitätsanalyst der App N, der …“.
• Zählt auf, welche Eingaben er erhält: Dialoge, Signale, System‑Prompt, Descriptions.
• Formuliert die Aufgaben:
  • 2–3 Problemmuster finden;
  • je 1–2 Änderungen in Prompt, Tools, UX‑Texten vorschlagen;
  • einen kurzen Changelog zusammenstellen.
• Beschreibt das Antwortformat: strukturiertes JSON mit den Feldern patterns, suggestions, changelog.

Auch wenn ihr diesen Agenten vorerst nicht aus dem Code aufruft, hilft euch ein solcher Prompt bereits, eure Überlegungen zur Verbesserung der App besser zu strukturieren.

10. Häufige Fehler beim Aufbau des Verbesserungszyklus

Fehler Nr. 1: Optimierung nur auf eine Metrik.
Sich auf etwas zu fokussieren ist verlockend. Man kann nur den Cost jagen, sich über niedrigere OpenAI‑Rechnungen freuen – und übersehen, wie Quality‑Score, Konversionen und Retention nach unten kriechen. Man kann umgekehrt die Qualität auf 10/10 mit Reasoning‑Modellen drehen und vergessen, dass jedes Szenario nun einen Dollar kostet. Der Verbesserungszyklus muss auf das Metrik‑Paket schauen: Qualität ↔ Geld ↔ Nutzerverhalten.

Fehler Nr. 2: „magische“ Prompt‑Änderungen ohne Messung.
Der Satz „Ich habe den System‑Prompt umgeschrieben, jetzt sollte es besser sein“ ohne Golden‑Cases und Evals – ist eine Einladung zu einer Überraschung in ein paar Wochen. Jede Prompt‑Änderung – besonders in Produktion – muss durch eine klare Pipeline: Satz von Cases, LLM‑Eval vorher/nachher, bei Bedarf – Online‑Experiment. Sonst verbessert ihr die App nicht, sondern streut die Qualität zufällig.

Fehler Nr. 3: Auto‑Deploy von Änderungen des LLM‑Assistenten.
Auch wenn der Verbesserungsassistent wunderschöne Prompt‑Fragmente und überzeugende Tool‑Beschreibungen schreibt, ist das kein Grund, sie ohne Review zu pushen. Das Modell kennt nicht alle Business‑Constraints, Safety‑Risiken, den Kontext eurer Metriken. Seine Rolle ist Berater, nicht DevOps mit Release‑Recht.

Fehler Nr. 4: fehlender Bezug der Änderungen zu Hypothese und Signalen.
Manchmal nehmen Teams Änderungen „aus dem Bauch heraus“ vor und halten nicht fest, welches Signal zur Änderung führte und welche Hypothese sie prüfen. Am Ende weiß nach einem Monat niemand mehr, warum ein seltsamer Absatz im Prompt steht und wozu er gut sein sollte. Ein guter Qualitäts‑PR sollte mindestens drei Fragen beantworten: „Was tat weh?“, „Was ändern wir?“, „An welcher Metrik erkennen wir, dass es besser wurde?“

Fehler Nr. 5: Safety bei Verbesserungen vergessen.
Im Streben nach Nützlichkeit ist es leicht, Safety‑Einschränkungen zu lockern, „überflüssige Ablehnungen“ aus dem Prompt zu entfernen oder zu vergessen, Safety‑Cases laufen zu lassen. Jede Änderung an System‑Prompt, Tool‑Beschreibungen und Agent‑Behavior muss zuerst den Safety‑Eval‑Satz bestehen. Wenn auch nur ein Case, der früher bestand, nun fällt – ist das ein Stoppsignal, egal wie schön die anderen Metriken aussehen.

Fehler Nr. 6: der Wunsch, „alles auf einmal zu optimieren“.
Die Hälfte des Prompts umzuschreiben, das Modell zu wechseln, noch ein MCP‑Tool und einen neuen Wizard hinzuzufügen – alles in einem Release – klingt produktiv, zerstört aber die Möglichkeit zu verstehen, welche Änderung den Effekt brachte. Der Verbesserungszyklus ist nur dann effektiv, wenn er iterativ und fokussiert ist: ein bis zwei Hypothesen, ein kleiner Änderungssatz, ein klarer Rollback‑Plan.

Fehler Nr. 7: den Verbesserungszyklus zu einem seltenen „Generalreinigungstag“ machen.
Wenn ihr zweimal im Jahr einen großen „Qualitätstag“ veranstaltet und die restlichen Monate ohne Evals und Metrikanalyse lebt, wird die App die meiste Zeit „treiben“. Viel hilfreicher ist ein kleines, aber regelmäßiges Ritual: wöchentlich/alle zwei Wochen Signale ansehen, Hypothesen aktualisieren und kleine Schritte gehen. Genau so hört eure ChatGPT‑App auf, statisch zu sein, und beginnt wirklich, sich selbst zu verbessern.