Constraint-Based Prompting bei Reasoning-Modellen schadet mehr, als das es nützt

CBP: Die Technik, die uns bis Anfang 2025 noch den Popo gerettet hat und nun manchmal im Weg steht.

Constraint-Based Prompting, kurz CBP, gehört zu den Dingen, die ich selbst vor der Reasoning-Ära gerne eingesetzt habe – insbesondere im Marketing-Kontext, in Kombination mit Few-Shot-Beispielen, Persona-Framing und expliziten Tonvorgaben. Hat funktioniert – sehr häufig und meistens gut sogar.

Prompt-Outputs wurden reproduzierbar, Halluzinationen seltener, Formate hielten. Kurz: CBP war State-of-the-Art. Heute ist die Antwort: Kommt drauf an.

Und „kommt drauf an“ ist kein Ausweichen, sondern der eigentliche Punkt – denn welche Techniken für welche Modelle noch zählen, ignorieren die meisten Guides konsequent. Wer einen constraint-schweren Prompt aus 2023 unverändert auf ein aktuelles Reasoning-Modell losschickt, wundert sich manchmal zu Recht über das Ergebnis.

Was CBP verspricht – und warum es funktioniert hat

CBP bedeutet im Kern: Du sagst dem Modell nicht nur, was es tun soll, sondern auch, was es nicht tun darf. Explizite Constraints – Länge, Format, Tonlage, Themengrenzen, Selbstcheck-Anweisungen – sollen den Output kontrollierbar und reproduzierbar machen. Ein klassischer Prompt sah – natürlich stark vereinfacht – ungefähr so aus:

{
  "role": "system",
  "content": "Du bist ein präziser Marketing-Texter. Halte dich an folgende Regeln:\n1. Maximal 80 Wörter\n2. Kein Fachjargon\n3. Prüfe vor der Ausgabe, ob die Aussage belegbar ist\n4. Keine Superlative\n5. Antworte ausschließlich mit dem Text, ohne Erklärung"
}

Das funktioniert, bzw. funktionierte, weil Modelle wie GPT-3.5 oder frühe GPT-4-Varianten ohne solche Leitplanken schnell ins Schwafeln gerieten. Constraints gaben dem Modell einen Rahmen, innerhalb dessen es weniger Unsinn produzieren konnte. Die externe Struktur kompensierte fehlende interne Urteilsfähigkeit.

Aktuelle Prompt-Engineering-Guides von 2025/26 beschreiben diese Praxis noch immer als Standard – was zeigt, wie langsam Praxis-Guides die Modellentwicklung nachverfolgen.

Was sich mit Reasoning-Modellen verändert hat

Die aktuelle Frontier-Generation – GPT-5.5 Pro, Claude Opus 4.7 und Gemini 3.1 Pro – macht intern bereits das, wozu CBP externe Struktur erzwingt. Reasoning-Modelle „denken“ vor der Ausgabe: Sie erkennen Widersprüche, prüfen Format-Anforderungen, hinterfragen Fakten. Das ist kein Marketing-Versprechen, das ist die architektonische Grundlage dieser Modellklasse.

Die Konsequenz beschreibt OpenAIs offizieller GPT-5.5-Prompting-Guide ganz direkt und unverblümt: GPT-5.5 liefert die besten Ergebnisse, wenn der Prompt das Ziel, die Erfolgskriterien, die Constraints und den verfügbaren Kontext definiert – und dem Modell dann überlässt, den Weg zu wählen. Alte Prompts über-spezifizieren den Prozess, weil frühere Modelle mehr Führung brauchten. Bei GPT-5.5 addiert das nur Rauschen, verengt den Suchraum oder erzeugt mechanisch-starre Antworten.

Empirisch belegt ist das durch ein arXiv-Paper von Oktober 2025, das diesen Effekt als „Prompting Inversion“ bezeichnet. Die Studie testet drei Prompting-Strategien über drei Modellgenerationen auf dem GSM8K-Benchmark: Zero Shot, Standard-CoT und „Sculpting“ – eine constraint-schwere, regelbasierte Methode. Das Ergebnis ist eindeutig: Sculpting liefert auf GPT-4o einen klaren Vorsprung (+4 Prozentpunkte gegenüber CoT). Auf GPT-5 kehrt sich das um – Sculpting schadet. Die Constraints, die beim mittleren Modell als Leitplanke fungierten, werden beim starken Modell zur Handschelle. Die Autoren nennen das den „Guardrail-to-Handcuff“-Übergang – oder, weniger akademisch: Cargo Cult Prompting. Form übernommen, aber Kontext ignoriert.

Die Mechanik dahinter: Starke Modelle haben robuste, internalisierte Heuristiken für Reasoning und sprachliches Urteilsvermögen. Externe Constraints überschreiben diese – und erzwingen wörtlich-mechanische Interpretationen, die schlechter sind als das, was das Modell von sich aus produzieren würde. Der Vergleich im Paper ist treffend: Experten schneiden schlechter ab, wenn sie gezwungen werden, jeden Denkschritt bewusst zu artikulieren – das Gleiche passiert mit Frontier-Modellen unter CBP.

Wo CBP noch funktioniert: kleine Modelle, Pipelines, Automatisierung

Das Bild dreht sich vollständig, sobald man von den Flaggschiffen weggeht.

Claude Haiku 4.5, Gemini 2.5 Flash, GPT-5.5-mini oder auch Mistral 4 small – schnelle, kostengünstige Worker-Modelle ohne extended Thinking – profitieren von CBP weiterhin erheblich. Sie sind das Rückgrat von automatisierten Pipelines, wo Tausende von Completions parallel laufen, Latenz zählt und kein Mensch den Output nachkorrigiert. Genau hier ist das Risiko eines unkontrollierten Outputs am höchsten – und genau hier kauft CBP immer noch Reproduzierbarkeit.
In solchen Setups ist ein explizites Output-Schema kein Overhead, sondern technische Notwendigkeit:

{
  "role": "system",
  "content": "Klassifiziere den folgenden Support-Text. Antworte ausschließlich als JSON:\n{\"kategorie\": \"<billing|tech|other>\", \"dringlichkeit\": \"<hoch|mittel|niedrig>\", \"zusammenfassung\": \"<max. 20 Wörter>\"}\nKeine Erklärungen. Kein Preamble. Nur valides JSON."
}

Das ist kein stilistischer Spleen – das ist defensive Architektur. Ohne klare Constraints schmiert eine automatisierte Pipeline beim ersten unerwarteten Output ab – das lässt sich selbst in kleinem Maßstab in z.B. n8n mit entsprechenden KI-Nodes nachvollziehen. OpenAIs offizieller Guide formuliert es selbst: Bei den kleineren, hochsteuerbaren Varianten ist explizite Constraint-Setzung nach wie vor notwendig, weil diese Modelle fehlende Schritte seltener von sich aus inferieren.

Die eigentliche These: Technik ist Kontext, kein Dogma

Das Problem mit den meisten Prompt-Engineering-Guides ist nicht, dass sie falsch liegen – es ist, dass sie kontextfrei schreiben. „CBP funktioniert“ oder „CBP ist veraltet“ sind beide sinnlose Aussagen ohne Modellangabe, Pipeline-Architektur und Einsatzszenario.

Wer einen constraint-schweren Prompt, der auf Haiku 3.5 entwickelt wurde, unverändert auf Opus 4.7 losschickt, betreibt genau das: Technik ohne Kontext. Das Modell löst das Problem längst selbst – man zwingt es nur, einen schlechteren Weg zu nehmen.

Es gibt allerdings eine Dimension von CBP, die tatsächlich modellunabhängig nützlich bleibt – und das ist die kognitive Arbeit beim Formulieren der Constraints.

Wer gezwungen ist, seine Anforderungen explizit zu nennen – was darf nicht im Output sein? Welche Grenze setzt der Use Case? – definiert damit, was er wirklich erreichen möchte. Das ist Denkwerkzeug, kein Prompting-Trick. Wer seine Anforderungen nicht klar genug „denken“ kann, um Constraints zu formulieren, hat kein Prompting-Problem – er hat ein Briefing-Problem.

Praktische Entscheidung: wann anwenden, wann weglassen

Eine grobe Faustregel für 2026 – CBP anwenden bei Non-Reasoning-Modellen (Haiku, Flash, Mini-Varianten, Mistral Small, die chinesischen non-thinking Vertreter), automatisierten Pipelines ohne menschliche Nachkontrolle, Output-Formaten, die maschinell weiterverarbeitet werden (JSON, XML), und überall dort, wo ein Formatfehler einen Downstream-Fehler (oder schlicht gar keinen Output) produziert.

CBP weglassen oder stark reduzieren bei Frontier Reasoning-Modellen (Opus 4.7, GPT-5.5 Pro, Gemini 3.1 Pro, Qwen3.6 Max, DeepSeek-V4-Pro, etc.), kreativen oder argumentativen Aufgaben, interaktiven Szenarien mit menschlichem Review und überall dort, wo das Modell besser navigiert, wenn man ihm den Weg großzügiger überlässt, statt ihn strikt vorzuschreiben.

OpenAIs eigene Formulierung trifft es: Beschreibe das Ziel, nicht die Route – und reserviere harte Constraints für echte Invarianten: Sicherheitsregeln, Pflichtfelder im Output, Aktionen, die niemals passieren dürfen.

Der Rest ist Vertrauen in das Modell, das man sich entschieden hat einzusetzen.Wenn man das nicht aufbringen kann, sollte man vielleicht das Modell wechseln – nicht den Prompt komplizierter machen.