Vom Anpassen von Anfragen zu Rückkopplungsschleifen: DSPy, GEPA und Claude Code

Jahrelang war die übliche Lösung für schwache Ergebnisse von LLMs einfach: Den Prompt anpassen und es erneut versuchen. Bei agilen Systemen ist der Prompt oft nicht die Stelle, an der nachgebessert werden muss.

Stellen Sie sich einen Produktionsfehler vor, der erst nach einer Konfigurationsänderung auftritt. Übergeben Sie ihn an zwei verschiedene KI-Systeme. Das erste erhält den Stack-Trace sowie eine sorgfältig formulierte Anweisung und liefert einen Patch. Das zweite kann das Repository öffnen, die Projektregeln lesen, den Fehler nachstellen, den Code ändern, die Tests ausführen, herausfinden, was schiefgelaufen ist, und den Vorgang erneut durchlaufen.

In beiden Fällen spielt das Modell eine Rolle. Was das zweite System hat und das erste nicht, ist ein ausführbarer Feedbackkreislauf.

Sobald diese Schleife existiert, wird die Formulierung des Prompts zu nur einem von vielen Einstellmöglichkeiten. Man kann außerdem anpassen, wie die Aufgabe aufgeteilt wird, was abgerufen wird, welche Tools verfügbar sind, die Beispiele, die Überprüfung, die Regeln für erneute Versuche, wie die Ausführung abgeschirmt wird, sowie den Evaluator, der entscheidet, ob die Arbeit tatsächlich korrekt ist.

Das ist der Zusammenhang, der von Stanfords Forschungen zu DSPy, MIPRO, STORM und GEPA bis zu Anthropics Produktentwicklung bei Claude Code und dem Model Context Protocol reicht. Es handelt sich dabei nicht um eine einzige Architektur. Die gemeinsame Idee dahinter lautet: Die KI-Entwicklung wandelt sich von der Feinabstimmung eines einzelnen Prompts hin zum Aufbau von Systemen, die handeln, das Ergebnis messen und das um das Modell herum geschriebene Programm verbessern.

Der Prompt ist nun ein Parameter

Eine einmalige Anwendung bietet nur sehr wenige Einstellmöglichkeiten:

Task → Prompt → Model → Result

Für begrenzte Aufgaben ist das in Ordnung. Es wird anfällig, sobald die Aufgabe mehrere Schritte erfordert, externe Informationen benötigt, echte Nebenwirkungen hat, Überprüfungen vornimmt oder von einer schlechten Entscheidung mitten im Verlauf wiederhergestellt werden muss.

Ein für die Produktion konstruiertes System sieht eher so aus:

 Task
  ↓
Program / Planner
  ↓
Context + Retrieval
  ↓
Tools + Environment
  ↓
Execution Trace
  ↓
Evaluator
  ↓
Retry, Repair, or Optimize
  ↓
Result

Ein schlechtes Ergebnis kann viele mögliche Ursachen haben. Das Modell ist vielleicht nicht stark genug. Die Informationsabrufung könnte den falschen Kontext geliefert haben. Der Planer hat die Aufgaben möglicherweise falsch aufgeteilt. Ein Tool könnte veraltete Daten zurückgegeben haben. Der Überprüfer hat vielleicht eine ungültige Antwort einfach akzeptiert. Oder die Anweisungen müssen tatsächlich korrigiert werden.

Daher verschwindet das Prompt-Engineering nicht. Es wird zu einem Teil eines umfassenderen Problems der Fehlersuche und Optimierung.

DSPy: Das Programm explizit machen

Die erste große Idee von DSPy bestand darin, einen LM-Pipeline-Prozess nicht länger als eine Ansammlung manuell angepasster Prompt-Sätze zu betrachten. Die ursprüngliche Forschungsarbeit modelliert LM-Anwendungen als rechnerische Graphen aus deklarativen Modulen und fügt einen Compiler hinzu, der diese Module anhand einer bestimmten Metrik optimiert. Die aktuellen Dokumentationen formulieren das noch klarer: Definieren Sie strukturierte Signaturen und Module, liefern Sie Beispiele sowie eine Bewertungsfunktion und kompilieren Sie das Programm, anstatt jeden Prompt manuell anzupassen.

Ein kleines DSPy-Programm sieht so aus:

import dspy

class Diagnose(dspy.Signature):
    """Identify the most likely root cause from an issue and repository evidence."""
    issue: str = dspy.InputField()
    evidence: str = dspy.InputField()
    diagnosis: str = dspy.OutputField()

program = dspy.ChainOfThought(Diagnose)

optimizer = dspy.GEPA(
    metric=score_diagnosis,
    auto="medium",
)

optimized = optimizer.compile(
    program,
    trainset=historical_incidents,
)

Die Syntax ist nicht das Wichtigste. Entscheidend ist, dass vier Aspekte, die normalerweise in einer einzigen Anweisung miteinander verknüpft sind, nun getrennt sind: Was die Aufgabe erzeugen muss, wie sie ausgeführt wird, welche Beispiele sie leiten und wie Erfolg bewertet wird.

Das verändert die Aufgabe des Ingenieurs. Anstatt das gesamte Iterationsbudget mit der Debatte zu verschwenden, ob „kompakt formulieren“ in „vor dem Antworten sorgfältig überlegen“ umgewandelt werden sollte, kann man eine bessere Frage stellen: Welches Verhalten sollte verbessert werden und wie wird das gemessen?

Ohne eine aussagekräftige Metrik führt die automatische Optimierung lediglich dazu, dass das System am falschen Ziel besser wird.

MIPRO: Die Anpassung vieler Stufen ist ein Suchproblem

Die Situation wird schwieriger, wenn das Programm mehrere Module aufweist. Nehmen wir einen Fehlerbehebungsprozess mit Diagnose, Erstellung eines Patches und Überprüfung, bei dem der abschließende Test fehlschlägt. Welches Modul ist dafür verantwortlich? Welche Anweisung muss geändert werden? Ist eines der wenigen Beispiele irreführend? Könnte eine bessere Diagnoseschritt die Erstellung des Patches erschweren?

Das ist ein Problem der Zuweisung von Ressourcen, und genau darauf zielt MIPRO ab. Die MIPRO-Publikation geht über das Einfügen einer einzigen Anweisung hinaus. Sie optimiert gemeinsam die geschriebenen Anweisungen sowie die wenigen Beispiele jedes Moduls, kombiniert Vorschläge für Anweisungen, die sowohl das Programm als auch die Daten berücksichtigen, Bewertungen an Mini-Gruppen sowie ein Surrogatmodell, das die Suche in Richtung vielversprechender Kombinationen lenkt.

In Kurzform:

Bootstrap useful demonstrations
          ↓
Propose task-grounded instructions
          ↓
Search instruction + demo combinations
          ↓
Evaluate the whole program

Mit Llama-3-8B übertraf der Optimierer seine Baseline-Werte in fünf von sieben mehrstufigen Programmen, wobei im besten Fall eine Steigerung von bis zu 13 Prozent bei der gemeldeten Genauigkeitsmetrik erzielt wurde.

Das ist eine bescheidener formulierte Aussage als „automatische Anweisungen sind besser als Menschen“. Die wichtigere Erkenntnis ist struktureller Natur: Sobald Anweisungen und Demonstrationen zu Parametern eines mehrstufigen Programms werden, besteht die Verbesserung darin, im System zu suchen, anstatt an einem einzigen Textstring zu arbeiten.

STORM: Struktur geht vor Optimierung

Kein Optimierer kann einen schlecht strukturierten Arbeitsablauf retten. Stansfords STORM ist ein gutes Beispiel dafür, da es sich auf die Gestaltung des Ablaufs konzentriert und nicht darauf, welche Anweisung am besten funktioniert.

Ein einzelnes Modell, das alle Forschungsarbeiten und das ausführliche Schreiben auf einmal erledigt, ist die naive Variante; STORM trennt die Vorbereitungsphase in eigene Schritte auf. Es sucht nach verschiedenen Perspektiven zum Thema, nutzt sie, um quellenbasierte Fragen zu formulieren, ordnet das Gesammelte in einen Entwurf und schreibt erst danach.

Im Vergleich zu einer auf einem Entwurf basierenden Herangehensweise weist das Verfahren einen absoluten Zuwachs von 25 Prozentpunkten in Bezug auf die Organisation sowie einen Zuwachs von 10 Prozentpunkten in Bezug auf die Umfassung auf. Der STORM-Repository macht die Grenzen genauso deutlich: Die erzeugten Artikel sind noch nicht veröffentlichungsbereit und benötigen oft umfangreiche Bearbeitungen.

Die daraus resultierende Lektion lautet nicht „mehr Agenten hinzufügen“. Vielmehr zeigt sich, dass eine Aufteilung klare Bereiche zur Steuerung von Kontext, Beweisen, Fehlerbehandlung und Bewertung bietet. Bevor man einen Workflow optimiert, sollte man sicherstellen, dass seine Phasen mit den tatsächlichen Fehlerquellen übereinstimmen.

GEPA: Lernen aus dem, was tatsächlich passiert ist

Eine einzige Wertung kann Ihnen mitteilen, dass eine Leistung durchschnittlich war. In der Regel kann sie Ihnen jedoch nicht sagen, warum. Eine echte Ausführung hinterlässt weitaus umfangreichere Hinweise:

input
  ↓
retrieval choice
  ↓
reasoning
  ↓
tool call
  ↓
tool result
  ↓
constraint failure
  ↓
final output

GEPA, abgekürzt für Genetic-Pareto und im Juli 2025 veröffentlicht, nutzt dieses Signal. Es erfasst Ausführungspfade, reflektiert sie in natürlicher Sprache, schlägt Anpassungen vor, bewertet die Kandidaten und behält eine Pareto-Grenze bei, damit komplementäre Strategien nicht weggeworfen werden.

In der Produktion spielt eine Grenze eine große Rolle. GEPA optimiert anhand von bereits beobachteten Trajektorien. Es handelt sich dabei nicht um eine Erlaubnis, einem aktiven Agenten zu erlauben, sich nach jedem Benutzerantrag selbst zu überschreiben. Bevor ein optimierter Kandidat in Betrieb genommen wird, sollte er versioniert werden, an Fällen bewertet werden, mit denen er nie trainiert wurde, innerhalb eines festgelegten Optimierungsbudgets gehalten werden und einen expliziten Aufstiegsprozess gegenüber einer sorgfältig ausgewählten Bewertungsgruppe bestehen. Das ist die Grenze zwischen nützlicher Selbstverbesserung und unkontrollierter Selbstanpassung.

Claude Code: der Loop in einer echten Umgebung

DSPy angeht das Problem von der Seite der Programmoptimierung her. Claude Code betrachtet es aus der Sicht der Laufzeitumgebung. Nach der Sichtweise von Anthropic handelt es sich um einen Agenten, der in Ihrem Repository vorhanden ist: Er übernimmt die eigenen Anweisungen des Projekts, ändert Dateien, führt Shell-Befehle sowie Testsuite aus und passt sich ständig an die Ergebnisse an. In seinen fortgeschrittenen Dokumentationen wird über die Aufteilung der Arbeit auf Unteragenten, das Ausführen von Hooks zwischen den Schritten sowie das Anbinden interner Unternehmensdienste über MCP gesprochen.

Die Architektur ist nicht „Chatten mit einem klügeren Programmierer“. Sie ähnelt eher dem Folgenden:

Repository + Project Rules + Task
              ↓
            Model
       ↙      ↓      ↘
     Read    Edit   Execute
       ↘      ↓      ↙
      Tests / Runtime Evidence
              ↓
         Next Decision

Diese laufzeitbezogenen Erkenntnisse verändern das, was das Modell leisten kann. Ein fehlgeschlagener Test liefert bessere Rückmeldungen als „bitte überdenken Sie es“. Ein Compilerfehler ist besser als wenn ein Modell seinen eigenen Patch bewertet. Ob ein Diff im Rahmen bleibt, kann mechanisch überprüft werden, anstatt ein anderes Modell zu fragen, ob die Änderung angemessen umfangreich ist.

Anthropics interne Produktivitätszahlen sind interessant, aber leicht falsch interpretiert. Seine Analyseberichte für 2026 zeigen, dass bis zum zweiten Quartal 2026 pro Ingenieur pro Tag etwa achtmal so viele Codezeilen erzeugt werden wie in früheren Perioden, wobei ausdrücklich gewarnt wird, dass Codezeilen die tatsächliche Produktivität überbewerten. In diesem Zeitraum gab es außerdem große Änderungen sowohl bei den Modellen als auch bei Claude Code, sodass die Zahl nicht zeigt, dass allein die Orchestrierung den Gewinn verursacht hat. Der deutlichere Hinweis ist, dass moderne Programmiersysteme kontinuierlich die Ausgabe von Modellen in Aktionen, Beobachtungen und anschließende Entscheidungen umwandeln.

MCP verbindet Tools – es orchestriert nicht

MCP wird oft mit Agenten, Tool-Nutzung und Orchestrierung gleichgesetzt, als wären das dasselbe. Das ist jedoch nicht der Fall. Die MCP-Architektur ist eine Client-Server-Spezifikation: Eine KI-App verbindet sich mit Servern und ermittelt, welche Tools, Ressourcen und Anfragen diese bereitstellen, ruft sie anschließend auf eine einheitliche Weise auf. Der Host koordiniert die Clients und ist für Berechtigungen, Kontextverwaltung, Sicherheitsrichtlinien sowie die Anbindung des LLM verantwortlich.

Daher umfasst MCP nur eine Schicht eines größeren Systems:

Model                  capability envelope
Program / graph         task decomposition
Context / state         what the model can see
Tools / MCP             what the system can access or do
Runtime / harness       where actions execute
Evaluator               what counts as success
Optimizer               how the program improves
Observability           why a run succeeded or failed

Kein einzelnes Framework besitzt alles, und genau deshalb lohnt es sich, systematisch zu denken.

Optimieren Sie den Fehlerbehebungsprozess, nicht die Anweisung

Kehren wir zum Fehler zurück. Anstatt einer einzigen Anweisung wie „Finden Sie das Problem und beheben Sie es“, beschreiben Sie den Arbeitsablauf ausführlich:

  Issue + Repository
        ↓
    Diagnosis
        ↓
      Patch
        ↓
Tests + Lint + Runtime Checks
        ↓
    Diff Review
        ↓
  Accept or Revise

Jede Phase liefert nun Beweise: Die Laufzeitprotokolle zeigen an, welche Dateien gelesen wurden, welche Befehle ausgeführt wurden, welche Patches fehlgeschlagen sind, die Testergebnisse sowie der endgültige Diff.

Deterministische Überprüfungen decken das ab, was mechanisch nachgewiesen werden kann: Die erforderlichen Tests bestehen, der Linter zeigt keine Fehler an, verbotene Dateien werden nicht berührt, und der Patch bleibt im zulässigen Bereich. Die Modellbewertung wird für wirklich semantische Fragen aufgehoben, wie zum Beispiel ob die Diagnose die wahrscheinliche Ursache erläutert.

Im Laufe der Zeit werden frühere Fälle zu einem Bewertungssatz. MIPRO kann Anweisungen und Demonstrationen in den Diagnose- und Reparaturmodulen durchsuchen. GEPA kann fehlgeschlagene Abläufe sowie schriftliche Rückmeldungen des Evaluators nutzen, um einen besseren Programmtext vorzuschlagen. Doch die Optimierung gehört hinter eine Veröffentlichungsgrenze:

Production traces
      ↓
Curated evaluation set
      ↓
Offline optimizer
      ↓
Candidate program
      ↓
Held-out validation
      ↓
Controlled promotion

Hier treffen Forschung und Produktion endlich aufeinander. Der Agent-Runtime erzeugt Aktionen und Spuren. Der Evaluator wandelt diese Spuren in Beweise um. Der Optimierer schlägt ein besseres Programm vor. Der Deployment-Prozess entscheidet, ob eine Veröffentlichung sicher ist.

Was das für KI-Entwickler bedeutet

Prompts sind nicht irrelevant geworden. Es gibt nur mehr nützliche Stellen, an denen eingegriffen werden kann. Wenn ein Workflow nicht optimal funktioniert, sollte man nicht reflexartig mit der Formulierung beginnen. Erstellen Sie heraus, welche Schicht versagt hat:

• Kann das Basismodell die Aufgabe überhaupt bewältigen?
• Lieferte die Informationsbeschaffung den richtigen Kontext?
• Wurde die Aufgabe an sinnvollen Grenzen aufgeteilt?
• Lieferten die Tools Beweise, denen man vertrauen kann?
• War die Ausführung isoliert und beobachtbar?
• Messt der Evaluator das Verhalten, das Ihnen wirklich wichtig ist?
• Verbessert der Optimierer die Qualität der ungetesteten Daten oder passt er nur den Entwicklungsdatensatz an?

Wenn man das gesamte System betrachtet, werden auch die Kompromisse sichtbar, die in der Begeisterung oft übersehen werden. Ein schwaches Modell macht ein Graphen um es herum nicht zu einem führenden Modell. Eine schlechte Metrik optimiert das falsche Verhalten. Mehr Werkzeuge bedeuten mehr mögliche Fehlerwege sowie eine größere Angriffsfläche. Jeder Optimierungsversuch verbraucht Token und Zeit für die Bewertung. Am schlimmsten ist, dass ein Agent, der sich selbst ändert, ohne Versionshistorie und ohne unberührte Testfälle, instabiler werden kann – obwohl er auf dem Papier unabhängiger erscheint.

Die Schlussfolgerung ist also nicht, dass das Modell keine Bedeutung mehr hat. Die Modellqualität legt die Obergrenze für die Leistungsfähigkeit fest. Das Systemdesign bestimmt, wie viel von dieser Leistungsfähigkeit in zuverlässige Ergebnisse umgesetzt wird.

Das ist der eigentliche Zusammenhang zwischen der Stanford-Forschung und Anthropics Werkzeugen. Mit DSPy hört das Programm auf, sich in Prompt-Strings zu verstecken. MIPRO ermöglicht es, über Anweisungen und Beispiele aus verschiedenen Phasen zu suchen. STORM erinnert daran, dass die Struktur des Workflows an erster Stelle steht. GEPA analysiert vollständige Ausführungsprotokolle, um Verbesserungen zu finden. Claude Code bringt das Modell in ein funktionsfähiges Ingenieurumfeld, und MCP standardisiert eine der Grenzen zu externen Fähigkeiten. Verschiedene Projekte auf unterschiedlichen Ebenen – alle zeigen in dieselbe Richtung.

Nächstes Mal, wenn ein KI-System versagt, sollte „Welchen Prompt soll ich als Nächstes ausprobieren?“ nicht die einzige Frage sein. Fragen Sie sich, welcher Teil des Systems ausgefallen ist und welche Hinweise Ihnen dabei helfen, es zu reparieren.