Chain-of-Thought-Prompting für komplexe Aufgaben

1. Was Chain-of-Thought-Prompting ist und warum es funktioniert

Chain-of-Thought-Prompting ist eine Prompting-Technik, bei der ein Sprachmodell explizit aufgefordert wird, seine Überlegungen in nachvollziehbaren Zwischenschritten zu formulieren, bevor es zu einer finalen Antwort kommt. Der Ansatz geht auf Forschungsarbeiten von Google aus dem Jahr 2022 zurück und zeigt seither konsistent: Bei Aufgaben, die mehrere logisch verknüpfte Schritte erfordern, steigt die Genauigkeit deutlich, wenn das Modell seinen Gedankengang explizit ausformuliert, statt direkt zu einer Antwort zu springen.

Der technische Grund liegt in der Funktionsweise autoregressiver Sprachmodelle: Jedes neue Token wird auf Basis aller vorherigen Tokens erzeugt, einschließlich der eigenen bisherigen Ausgabe. Ohne explizite Zwischenschritte muss das Modell komplexe Schlussfolgerungen implizit in einem einzigen Antwortversuch treffen. Schreibt es seine Überlegungen dagegen aus, kann es auf diesen eigenen Text als zusätzlichen Kontext zurückgreifen und Fehler in einer frühen Annahme erkennen, bevor sie sich auf das Endergebnis auswirken. Für Entwickler hat das einen zweiten praktischen Nutzen: Die sichtbare Argumentationskette lässt sich lesen und gezielt korrigieren, statt nur das Endergebnis zu akzeptieren oder zu verwerfen.

2. Wann sich Chain-of-Thought bei mehrstufigen Aufgaben lohnt

Chain-of-Thought entfaltet seinen Nutzen dort, wo eine Aufgabe aus mehreren voneinander abhängigen Teilschritten besteht und Zwischenergebnisse das weitere Vorgehen beeinflussen. Typische Kandidaten in der Magento-Entwicklung sind Fehleranalysen, bei denen mehrere Plugins, Observer oder Cache-Schichten zusammenspielen, oder Architekturentscheidungen, bei denen mehrere Constraints gleichzeitig erfüllt sein müssen, etwa Rückwärtskompatibilität, Performance und Testbarkeit.

Ein einfaches Erkennungsmerkmal: Wenn ein erfahrener Entwickler die Aufgabe nicht in einem einzigen gedanklichen Schritt lösen würde, sondern selbst mehrere Hypothesen prüfen, Code an verschiedenen Stellen lesen und Optionen gegeneinander abwägen müsste, profitiert auch Claude von explizitem Reasoning. Bei der Planung eines Refactorings über mehrere Module hinweg etwa lohnt es sich, das Modell explizit erst alle betroffenen Stellen auflisten zu lassen, bevor es einen Umsetzungsvorschlag macht. Diese Trennung von Analyse und Lösung reduziert das Risiko, dass eine wichtige Abhängigkeit schlicht übersehen wird.

3. Chain-of-Thought beim Debugging komplexer Fehler

Beim Debugging eines Fehlers mit mehreren möglichen Ursachen ist ein direkter Prompt wie „behebe den Fehler“ häufig kontraproduktiv: Das Modell rät auf Basis oberflächlicher Muster und liefert einen Fix, der das Symptom, aber nicht die Ursache behebt. Ein Chain-of-Thought-Prompt zwingt Claude stattdessen, zunächst mögliche Ursachen zu sammeln, jede anhand der vorliegenden Evidenz zu bewerten und erst danach eine Diagnose zu stellen.

In der Praxis bewährt sich ein dreistufiges Muster: Zuerst alle Symptome und relevanten Codepfade sammeln, dann für jede plausible Ursache prüfen, ob sie mit den beobachteten Symptomen konsistent ist, und erst danach den Fix vorschlagen. Bei einem Fehler wie einem fehlschlagenden Checkout in Magento, der durch das Zusammenspiel mehrerer Observer entstehen kann, verhindert dieses Vorgehen, dass das Modell vorschnell den ersten plausibel aussehenden Verdächtigen fixiert. Wichtig ist, dass der Prompt explizit nach der Reihenfolge fragt, sonst überspringt das Modell die Ursachenanalyse und springt direkt zur Lösung.

#!/usr/bin/env bash
# debug-prompt.sh - structured Chain-of-Thought prompt for a multi-cause bug
# Save the prompt as a file and feed it to Claude Code for a traceable analysis

cat > /tmp/debug-prompt.md << 'EOF'
Der Checkout schlägt in etwa 5 % der Fälle mit "Order could not be placed" fehl.
Betroffene Dateien: Magento/Sales/Model/Order/Payment, drei Plugins in
app/code/Mironsoft/Checkout/Plugin, ein Observer auf sales_order_place_after.

Gehe in dieser Reihenfolge vor, bevor du einen Fix vorschlägst:
1. Liste alle Stellen auf, die bei sales_order_place_after ausgeführt werden,
   inklusive Reihenfolge (sort_order) der Plugins und Observer.
2. Bewerte für jede Stelle, ob ein Fehler dort zum beobachteten Symptom passt.
3. Nenne die wahrscheinlichste Ursache mit konkreter Begründung anhand des Codes.
4. Erst danach: konkreter Fix mit betroffenen Dateien.
EOF


claude --print < /tmp/debug-prompt.md

4. Chain-of-Thought bei der Planung von Refactorings

Ein Refactoring, das mehrere Dateien und Abhängigkeiten betrifft, ist ein klassischer Fall für strukturiertes Reasoning. Statt Claude direkt Code schreiben zu lassen, lohnt es sich, das Modell zunächst einen Plan formulieren zu lassen: Welche Dateien sind betroffen, in welcher Reihenfolge sollten Änderungen vorgenommen werden, um das Projekt in jedem Zwischenschritt lauffähig zu halten, und welche Risiken bestehen für bestehende Tests oder Schnittstellen.

Diese Trennung zwischen Planung und Umsetzung korreliert stark mit der Nutzung der Extended-Thinking-Funktion der Claude-Modelle, bei der ein separates Denkbudget für die interne Analyse reserviert wird, bevor die eigentliche Antwort formuliert wird. Für API-Aufrufe lässt sich dieses Budget explizit konfigurieren. Der Effekt ist messbar: Ein Refactoring-Plan, der zuerst alle betroffenen Interfaces und Tests benennt, bevor der erste Codevorschlag entsteht, führt seltener zu vergessenen Anpassungsstellen als ein direkt generierter Diff.

# refactor_plan.py - request a structured refactor plan with extended thinking
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-4-5",
    max_tokens=4000,
    thinking={"type": "enabled", "budget_tokens": 2000},
    messages=[
        {
            "role": "user",
            "content": (
                "Wir wollen das Repository-Pattern in Mironsoft_SeoSuite "
                "von direkten Collection-Aufrufen auf Service Contracts umstellen. "
                "Denke zuerst systematisch nach, bevor du antwortest:\n"
                "1. Liste alle betroffenen Klassen und ihre Abhängigkeiten.\n"
                "2. Bestimme eine Reihenfolge, die das Projekt in jedem Schritt "
                "lauffähig hält.\n"
                "3. Nenne Risiken für bestehende PHPUnit-Tests.\n"
                "4. Erst danach: konkreter Umsetzungsplan pro Datei."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "thinking":
        print("--- Reasoning ---\n", block.thinking)
    elif block.type == "text":
        print("--- Plan ---\n", block.text)

5. Praktische Prompt-Patterns für strukturiertes Reasoning

Das einfachste Muster ist Zero-Shot Chain-of-Thought: Der Prompt endet mit einer expliziten Anweisung wie „Denke Schritt für Schritt, bevor du antwortest“ oder „Analysiere zuerst alle relevanten Faktoren, dann formuliere deine Antwort“. Dieses Muster funktioniert bei Claude zuverlässig, weil das Modell dadurch angehalten wird, seinen internen Denkprozess in Textform zu externalisieren, statt ihn implizit zu überspringen.

Few-Shot Chain-of-Thought geht einen Schritt weiter: Der Prompt enthält ein oder zwei Beispiele, in denen bereits eine vollständige Reasoning-Kette vorgeführt wird, bevor die eigentliche Aufgabe folgt. Das ist besonders nützlich, wenn ein bestimmtes Ausgabeformat gewünscht ist, etwa nummerierte Analyseschritte gefolgt von einem klar abgegrenzten Ergebnisblock. Ein drittes Muster, Self-Consistency, lässt das Modell dieselbe Frage mehrfach mit unterschiedlichen Reasoning-Pfaden beantworten und wählt die häufigste Antwort. Das erhöht die Zuverlässigkeit bei mehrdeutigen Problemen weiter, verursacht aber ein Vielfaches der Kosten und eignet sich daher nur für wenige, besonders kritische Entscheidungen.

{
  "pattern": "structured-few-shot-cot",
  "example": {
    "task": "Warum schlägt dieser Magento-Cronjob sporadisch fehl?",
    "reasoning_steps": [
      "1. Symptome sammeln: Fehler tritt nur bei parallelen Cron-Gruppen auf.",
      "2. Hypothese A prüfen: Lock-Datei fehlt -> passt zu sporadischem Muster.",
      "3. Hypothese B prüfen: DB-Deadlock -> passt zu Fehlermeldung im Log.",
      "4. Evidenz vergleichen: Log zeigt 'Deadlock found', nicht 'Lock exists'."
    ],
    "conclusion": "Ursache ist ein DB-Deadlock zwischen zwei Cron-Gruppen, kein Lock-Problem."
  },
  "instruction": "Wende dasselbe vierstufige Muster auf die folgende neue Aufgabe an."
}

6. Chain-of-Thought in Claude Code: Extended Thinking und Plan Mode

Claude Code nutzt Chain-of-Thought-Prinzipien bereits standardmäßig in seiner internen Arbeitsweise, etwa wenn es vor einer Werkzeugnutzung kurz abwägt, welche Datei als Nächstes gelesen werden sollte. Für komplexere Aufgaben lässt sich dieses Verhalten gezielt verstärken: Der Plan Mode weist Claude Code an, zunächst einen vollständigen Änderungsplan zu erstellen und zur Bestätigung vorzulegen, bevor irgendeine Datei verändert wird. Das entspricht exakt dem Prinzip, Analyse und Umsetzung explizit zu trennen.

Über die Anthropic API steht zusätzlich die Extended-Thinking-Funktion zur Verfügung, bei der ein separates Token-Budget für internes Reasoning reserviert wird, das getrennt von der finalen Antwort ausgegeben wird. Dieses Budget lässt sich pro Anfrage konfigurieren und sollte an die tatsächliche Komplexität der Aufgabe angepasst werden, denn ein zu hohes Budget für eine einfache Frage erzeugt lediglich unnötige Latenz, ohne die Qualität der Antwort zu verbessern.

// refactor-plan.ts - Extended Thinking via TypeScript SDK for a multi-file task
import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function planRefactor(taskDescription: string) {
  const response = await client.messages.create({
    model: "claude-opus-4-5",
    max_tokens: 3000,
    // Reserve a thinking budget only for genuinely complex, multi-step tasks
    thinking: { type: "enabled", budget_tokens: 1500 },
    messages: [{ role: "user", content: taskDescription }],
  });

  const thinking = response.content.find((b) => b.type === "thinking");
  const answer = response.content.find((b) => b.type === "text");

  console.log("Reasoning trace:", thinking);
  console.log("Final plan:", answer);
  return answer;
}

7. Wann Chain-of-Thought overkill ist

Nicht jede Aufgabe profitiert von explizitem Reasoning. Bei atomaren, eindeutig definierten Aufgaben wie dem Umbenennen einer Variable, dem Formatieren einer Codezeile oder dem Nachschlagen einer bekannten API-Signatur bringt eine Chain-of-Thought-Anweisung keinen Genauigkeitsgewinn, verlängert aber die Antwortzeit spürbar und erhöht den Tokenverbrauch. Studien und praktische Erfahrung zeigen übereinstimmend, dass der Nutzen von explizitem Reasoning mit der Komplexität der Aufgabe wächst und bei trivialen Aufgaben sogar ins Negative kippen kann.

Der Grund: Ein Modell, das angewiesen wird, ausführlich nachzudenken, obwohl die Antwort bereits eindeutig ist, neigt gelegentlich dazu, unnötige Sonderfälle zu konstruieren oder die eigentlich richtige erste Eingebung durch Überanalyse zu verwerfen. In Claude Code äußert sich das als spürbar längere Wartezeit bei trivialen Änderungen, ohne dass die Ergebnisqualität steigt. Die praktische Faustregel: Direkte, kurze Prompts für klar spezifizierte Einzelschritte, explizites Reasoning erst ab dem Punkt, an dem mehrere Informationsquellen gegeneinander abgewogen werden müssen.

#!/usr/bin/env bash
# prompt-comparison.sh - direct prompt vs. forced Chain-of-Thought for a trivial task

# Trivial task: rename a variable. Direct prompt is fast and just as accurate.
claude --print "Benenne die Variable \$orderTotal in \$grandTotal in \
app/code/Mironsoft/Checkout/Model/TotalsProcessor.php um."

# Same trivial task with forced Chain-of-Thought: no accuracy gain,
# measurably higher latency and token cost for no reason.
claude --print "Denke Schritt für Schritt nach, bevor du antwortest: \
Benenne die Variable \$orderTotal in \$grandTotal in \
app/code/Mironsoft/Checkout/Model/TotalsProcessor.php um."

# Rule of thumb: reserve explicit reasoning for tasks with multiple
# dependent steps, not for single, unambiguous edits.

8. Grenzen und Risiken von Chain-of-Thought

Eine sichtbare Reasoning-Kette wirkt überzeugend, ist aber keine Garantie für Korrektheit. Forschungsarbeiten zur sogenannten „Faithfulness“ von Chain-of-Thought-Ausgaben zeigen, dass der dargestellte Gedankengang nicht immer exakt widerspiegelt, wie das Modell tatsächlich zu seiner Antwort gekommen ist. Ein plausibel klingender, sauber nummerierter Argumentationsgang kann trotzdem in einer falschen Schlussfolgerung enden, und die scheinbare Stringenz der Darstellung verleitet dazu, das Ergebnis unkritischer zu übernehmen als bei einer knappen, direkten Antwort.

Daraus folgt eine klare Konsequenz für die Praxis: Eine Chain-of-Thought-Ausgabe ersetzt keine externe Verifikation. Bei Code-Änderungen bleiben Tests, Typprüfung und Code-Review Pflicht, unabhängig davon, wie überzeugend die vorgelagerte Analyse wirkt. Zusätzlich verlängert jede Reasoning-Kette den Kontext und kann bei sehr langen Ketten dazu führen, dass frühere, korrekte Zwischenschritte im späteren Verlauf der Antwort wieder verwässert werden. Wer Chain-of-Thought einsetzt, sollte die Zwischenschritte aktiv lesen und stichprobenartig gegen den tatsächlichen Code prüfen, statt nur das Endergebnis zu betrachten.

9. Chain-of-Thought im direkten Vergleich

Ob sich explizites Reasoning lohnt, hängt stark vom Aufgabentyp ab. Die folgende Übersicht stellt typische Entwicklungsaufgaben gegenüber und zeigt, welcher Prompt-Ansatz jeweils sinnvoller ist.

Die Tabelle zeigt ein wiederkehrendes Muster: Sobald mehrere Informationsquellen gegeneinander abgewogen oder mehrere Hypothesen geprüft werden müssen, überwiegt der Nutzen von Chain-of-Thought klar die zusätzlichen Kosten an Latenz und Tokens. Bei eindeutigen, atomaren Aufgaben kehrt sich dieses Verhältnis um. Die Einschätzung, in welche Kategorie eine konkrete Aufgabe fällt, bleibt eine bewusste Entscheidung des Entwicklers, keine automatische Eigenschaft des Modells.

10. Zusammenfassung

Chain-of-Thought-Prompting löst ein konkretes Problem: Bei mehrstufigen Aufgaben wie komplexem Debugging, Refactoring-Planung oder Architekturentscheidungen springt ein Modell ohne explizites Reasoning zu häufig zu einer plausiblen, aber falschen Antwort. Die Aufforderung, zuerst Zwischenschritte auszuformulieren, sei es durch eine einfache Zero-Shot-Anweisung, Few-Shot-Beispiele oder die Extended-Thinking-Funktion der Claude-Modelle, verbessert die Genauigkeit messbar und macht die Argumentation für Entwickler nachvollziehbar und korrigierbar.

Gleichzeitig ist die Technik kein Allheilmittel. Bei einfachen, eindeutig spezifizierten Aufgaben erzeugt sie nur zusätzliche Latenz und Tokenkosten, ohne die Antwortqualität zu verbessern. Und selbst eine überzeugend klingende Reasoning-Kette ersetzt keine externe Verifikation durch Tests, Typprüfung und Code-Review. Der praktische Wert von Chain-of-Thought entsteht erst durch die bewusste Entscheidung, wann die Technik eingesetzt wird und wann ein direkter Prompt die bessere Wahl ist.

11. FAQ: Chain-of-Thought-Prompting für komplexe Aufgaben