Nachdenken für Code und Debugging

Lektion aktualisiert am 2. November 2026. Die ursprünglichen Beispiele verwendeten Magistral, der am 31. Juli 2026 eingestellt wurde. Es werden nun Mistral Small 4 (mistral-small-2603) oder Mistral Large 4 (mistral-large-4-0) mit reasoning_effort="high" verwendet, und die Antwort wird mit der Funktion separer aus Lektion 3 ausgewertet. Quelle: Nachdenken (Mistral-Dokumentation).

Debugging: Ein Problem des Nachdenkens

Warum profitiert Debugging stärker vom Nachdenken als vom Code-Generieren? Weil das Generieren von Code eine Übung im Abruf ist – das Modell hat Millionen von Sortierfunktionen gesehen – wohingegen Debugging eine Übung im Konfrontieren ist. Sie müssen zwei Dinge gleichzeitig im Kopf behalten: was der Code sollte tun und was er tatsächlich tut, um die Lücke zu lokalisieren. Genau bei dieser Art von Aufgabe ändert das Nachdenken vor der Antwort das Ergebnis.

Das Finden eines Bugs ist im Kern eine Übung des Nachdenkens. Sie müssen die Absicht verstehen, die Ausführung verfolgen, die Divergenz zwischen erwartetem und tatsächlichem Verhalten identifizieren und eine Lösung formulieren. Genau hier macht das Nachdenken den Unterschied.

Klassisches Debugging

Beachten Sie die Form der Anfrage in diesem Beispiel. Wir sagen nicht „reparieren Sie diesen Code”. Stattdessen beschreiben wir das Symptom – was geschehen sollte versus was tatsächlich geschieht. Dies ist dieselbe Disziplin, die Sie bei einem menschlichen Kollegen anwenden: Eine Diagnose, die vom Symptom ausgeht, findet die Ursache, während ein bloßes „reparieren Sie dies” ohne Kontext oft eine Umschreibung hervorbringt, die den Bug verschleiert, anstatt ihn zu lösen.

from mistralai.client import Mistral

client = Mistral(api_key="YOUR_API_KEY")

buggy_code = """
def merge_sorted_lists(list1, list2):
    result = []
    i = j = 0
    while i < len(list1) and j < len(list2):
        if list1[i] <= list2[j]:
            result.append(list1[i])
            i += 1
        else:
            result.append(list2[j])
            j += 1
    return result

# Test: merge_sorted_lists([1, 3, 5], [2, 4, 6])
# Erwartetes Ergebnis: [1, 2, 3, 4, 5, 6]
# Tatsächliches Ergebnis: [1, 2, 3, 4, 5]
"""

response = client.chat.complete(
    model="mistral-small-2603",
    reasoning_effort="high",
    messages=[
        {"role": "system", "content": """Experte für Python-Debugging.
Methode:
1. Ausführung mental verfolgen
2. Ort identifizieren, an dem sich das Verhalten unterscheidet
3. Grundursache erklären
4. Lösung vorschlagen mit einem Test"""},
        {"role": "user", "content": f"Dieser Code hat einen Bug. Diagnose und Reparatur:\n\n{buggy_code}"}
    ],
)

Das Modell wird identifizieren, dass die Funktion verbleibende Elemente nach dem while-Loop nicht verarbeitet (es fehlt die Addition der Schwänze list1[i:] und list2[j:]).

Komplexe Code-Analyse

Das Verständnis von Legacy-Code ist der zweite große Anwendungsfall und besitzt eine interessante Eigenschaft: Die Nachdenkspur ist ebenso wertvoll wie die Antwort. Indem Sie lesen, wie das Modell die Logie rekonstruiert hat – welche Hypothesen es gebildet hat, welche Prüfungen es durchgeführt hat – erhalten Sie eine Lesekarte des Codes, die eine einfache finale Erklärung nicht bieten kann.

complex_code = """
def process(data):
    cache = {}
    def helper(n, memo=cache):
        if n in memo:
            return memo[n]
        if n < 2:
            memo[n] = n
            return n
        result = helper(n-1) + helper(n-2)
        memo[n] = result
        return result

    return [helper(x) for x in data if isinstance(x, int) and x >= 0]
"""

response = client.chat.complete(
    model="mistral-small-2603",
    reasoning_effort="high",
    messages=[
        {"role": "user", "content": f"""Analysieren Sie diesen Code im Detail:
1. Was tut er genau?
2. Gibt es potenzielle Probleme?
3. Wie kann er verbessert werden?

{complex_code}"""}
    ]
)

Debugging spezifischer Fehler

Typfehler

type_error = """
TypeError: unsupported operand type(s) for +: 'NoneType' and 'int'

Code:
def calculate_total(items):
    total = None
    for item in items:
        price = item.get('price')
        total = total + price
    return total
"""

response = client.chat.complete(
    model="mistral-small-2603",
    reasoning_effort="high",
    messages=[
        {"role": "user", "content": f"Erklären Sie diesen Fehler und reparieren Sie den Code:\n\n{type_error}"}
    ]
)

Leistungsprobleme

slow_code = """
def find_duplicates(lst):
    duplicates = []
    for i in range(len(lst)):
        for j in range(i + 1, len(lst)):
            if lst[i] == lst[j] and lst[i] not in duplicates:
                duplicates.append(lst[i])
    return duplicates

# Dieser Code ist bei großen Listen (100.000+ Elemente) sehr langsam
"""

response = client.chat.complete(
    model="mistral-small-2603",
    reasoning_effort="high",
    messages=[
        {"role": "system", "content": "Analysieren Sie die algorithmische Komplexität und schlagen Sie eine optimierte Version vor."},
        {"role": "user", "content": f"Optimieren Sie diesen Code:\n\n{slow_code}"}
    ]
)

Architektur und Refactoring

Nachdenken gilt auch für architektonische Entscheidungen:

architecture = """Meine Flask-Anwendung hat diese Struktur:

app.py (2000 Zeilen):
- API-Routen (20 Endpunkte)
- Geschäftslogik
- Datenbankzugriff
- Datenvalidierung
- Fehlerbehandlung

Wie sollte ich diese Anwendung umstrukturieren?"""

response = client.chat.complete(
    model="mistral-small-2603",
    reasoning_effort="high",
    messages=[
        {"role": "system", "content": """Senior-Software-Architekt.
Denken Sie durch SOLID-Prinzipien, Trennung der Belange
und langfristige Wartbarkeit durch."""},
        {"role": "user", "content": architecture}
    ],
)

Muster: Code-Review-Assistent

Kombinieren Sie Nachdenken mit systematischer Analyse:

def code_review(client, code, language="python"):
    """Führt einen tiefgehenden Code-Review mit Nachdenken durch."""

    review_prompt = f"""Führen Sie einen detaillierten Code-Review für diesen {language}-Code durch.

Analysieren Sie systematisch:
1. **Korrektheit**: Tut der Code, was er tun soll?
2. **Randfälle**: Sind Randfälle behandelt (None, leer, negativ)?
3. **Leistung**: Was ist die Komplexität? Ist sie optimal?
4. **Lesbarkeit**: Ist der Code klar und gut benannt?
5. **Sicherheit**: Gibt es Schwachstellen (Injection, XSS usw.)?

Für jedes gefundene Problem angeben:
- Die Zeilennummer
- Die Schweregrad (kritisch / wichtig / geringfügig)
- Die empfohlene Lösung

Code zum Review:
```{language}
{code}
```"""

    response = client.chat.complete(
        model="mistral-small-2603",
        reasoning_effort="high",
        messages=[{"role": "user", "content": review_prompt}]
    )

    return separer(response.choices[0].message.content)[1]  # die Antwort, ohne das Nachdenken

Small 4 oder Large 4 für Code?

Für Debugging und Code-Analyse hängt die Wahl zwischen den beiden Ansätzen von der Tiefe des Problems ab. Ein einfacher Bug – Syntaxfehler, explizite Ausnahme, offensichtliche Optimierung – wird von Mistral Small 4 (mistral-small-2603) mit reasoning_effort="high" zu moderatem Token-Kosten sehr gut gehandhabt. Bewahren Sie Mistral Large 4 (mistral-large-4-0, in Public Preview) für Fälle auf, in denen die Ursache nicht im Code selbst sichtbar ist: architektonische Analysen, subtile Bugs wie Race Conditions oder Speicherlecks, die nur in der Produktion auftreten, und komplexe Code-Reviews, bei denen Sie Korrektheit, Leistung und Sicherheit ausbalancieren müssen.

# Einfacher Bug: Small ist ausreichend
simple_bug = "warum wirft 'hello'.split('')[0] einen Fehler?"
response = client.chat.complete(
    model="mistral-small-2603",
    messages=[{"role": "user", "content": simple_bug}],
    reasoning_effort="high"
)

# Komplexer Bug: Large 4, bewerten Sie Ihre eigenen Fälle
complex_bug = "Meine Django-Anwendung hat in der Produktion ein Speicherleck, das in der Entwicklung nicht auftritt..."
response = client.chat.complete(
    model="mistral-large-4-0",
    reasoning_effort="high",
    messages=[{"role": "user", "content": complex_bug}]
)

Kernaussagen

• Debugging ist eine ideale Übung des Nachdenkens für reasoning_effort="high"
• Leiten Sie das Modell mit einem System-Prompt, der die diagnostische Methode strukturiert
• Nachdenken glänzt bei subtilen Bugs, Leistungsanalysen und Architektur
• Small 4 im high-Modus ist für häufige Bugs ausreichend; bewerten Sie Large 4 bei subtilen Bugs und Architektur
• Kombinieren Sie Nachdenken mit systematischem Code-Review, um die Qualität zu maximieren
• Fordern Sie immer eine Verifizierungstest mit dem vorgeschlagenen Fix an