Der Code läuft – aber stimmt die Analyse?

„Läuft“ ist nicht gleich „stimmt“

Stellen Sie sich folgende Situation vor: Sie geben Ihre Forschungsfrage und ein paar Details zu Ihren Daten in einen KI-Chatbot ein. Sekunden später haben Sie R-Code, der sich ohne Fehlermeldung ausführen lässt, Tabellen produziert und vielleicht sogar eine sauber formatierte Grafik erzeugt. Das fühlt sich an, als wäre das Problem gelöst.

Genau hier beginnt aber das eigentliche Risiko.

Eine Analyse kann technisch einwandfrei funktionieren und dennoch methodisch falsch sein. Der Code läuft, weil die Software Befehle verarbeiten kann. Ob diese Befehle aber die richtige Antwort auf Ihre Forschungsfrage liefern, ist eine vollständig separate Frage. Und diese Frage beantwortet kein Chatbot automatisch.

Was die Forschung dazu zeigt

Ausführbarkeit ist nur eine von mehreren Qualitätsdimensionen

Der StatLLM-Benchmark, veröffentlicht im Scientific Data Journal des Nature Portfolio, macht diesen Punkt sehr konkret. Die Studie bewertet LLM-generierten Statistikcode anhand von 207 Analyseaufgaben, die Bereiche wie Hypothesentests, Regression, ANOVA, generalisierte lineare Modelle und Survival-Analyse abdecken.

Das Ergebnis ist eindeutig: Ausführbarkeit ist nur eine von fünf Bewertungsdimensionen. Die anderen vier sind Korrektheit, Effektivität, Lesbarkeit und Output-Genauigkeit. Code kann also ausführbar sein und trotzdem in den verbleibenden vier Dimensionen schwächeln. Wer nur prüft, ob sein R- oder SPSS-Code ohne Fehler durchläuft, prüft damit gerade einmal zwanzig Prozent der relevanten Qualitätskriterien.

Auch mit Codeausführung bleiben Lücken

Eine Evaluation von Mathematica aus dem März 2025 zeigt eine wichtige Differenzierung. Modelle, die Code tatsächlich ausführen und Daten direkt analysieren, liefern deutlich bessere Ergebnisse als Modelle, die nur auf Basis von Text antworten. Codeausführung ist also ein Fortschritt.

Aber auch hier gilt: Selbst mit aktivierter Codeausführung lagen die Genauigkeitsraten bei deskriptiven Aufgaben je nach Modell zwischen 75 und 92 Prozent. Bei spezifischeren statistischen Aufgaben wie gewichteten Population Estimates blieben Fehler bestehen, die groß genug waren, um Schlussfolgerungen zu verändern. Codeausführung verbessert die Qualität, garantiert sie aber nicht.

Reproduzierbarkeit entsteht nicht durch Code allein

Eine groß angelegte Reproduzierbarkeitsstudie von Yiqing Xu (Stanford) und Leo Yang (Hong Kong Baptist University) analysierte 3.382 empirische Modelle aus führenden sozialwissenschaftlichen Zeitschriften. Die Autoren formulieren dabei ein klares Designprinzip: Wissenschaftliches Reasoning und computergestützte Ausführung sind zwei getrennte Qualitätsstufen.

Erfolgreich laufender Code muss demnach immer noch gegen die berichteten Ergebnisse verifiziert werden. Ausführung und Validierung sind nicht dasselbe.

Wo das Problem konkret entsteht

Die Hürde hat sich verschoben

Früher war das häufigste Problem: „Ich bekomme den Code nicht zum Laufen.“ Mit LLMs hat sich diese Hürde verschoben. Sie lautet jetzt: „Ich bekomme Code, aber ich weiß nicht sicher, ob er die richtige Analyse macht.“

Das klingt nach einem kleineren Problem. In der Praxis ist es aber ein größeres, weil es weniger sichtbar ist. Ein Syntaxfehler zeigt sich sofort. Ein methodischer Fehler kann sich hinter einer ordentlich aussehenden Tabelle verstecken.

Typische Fehlerquellen im LLM-generierten Code

Die folgenden Probleme entstehen nicht, weil der Code fehlerhaft geschrieben wurde, sondern weil die methodischen Entscheidungen dahinter nicht geprüft wurden:

• Variablen werden falsch behandelt, zum Beispiel ordinale Skalen als metrisch codiert
• Der gewählte Test passt nicht zur Hypothese oder zum Studiendesign
• Modellannahmen wie Normalverteilung oder Varianzhomogenität werden nicht geprüft
• Gewichtungen, Gruppenvergleiche oder Kontrollvariablen werden falsch umgesetzt
• Output wird formal korrekt erzeugt, aber inhaltlich falsch interpretiert
• Syntax und Methodenkapitel beschreiben nicht dieselbe Analyse

Gerade der letzte Punkt wird häufig unterschätzt. Wenn im Methodenkapitel eine bestimmte Analyse beschrieben wird, der Code aber eine andere Logik umsetzt, entsteht ein Widerspruch, der im Kolloquium auffällt.

Die entscheidende Frage: Wer prüft?

Empirische Belege für die Bedeutung menschlicher Kontrolle

Die wohl direkteste Antwort auf diese Frage liefert eine IZA-Studie mit 288 Forschenden, die auf 103 Teams in drei Gruppen aufgeteilt wurden: rein menschliche Teams, KI-unterstützte Teams und KI-geführte Teams.

Das Ergebnis ist klar: Rein menschliche Teams lagen bei der Reproduzierbarkeitsrate 57 Prozentpunkte über KI-geführten Teams. Noch aufschlussreicher ist der Befund zur Fehlererkennung. Human-only-Teams fanden signifikant mehr schwerwiegende Codierfehler als alle anderen Gruppen. KI-unterstützte Teams schnitten besser ab als KI-geführte, aber immer noch schlechter als reine Menschenteams.

Die Studie stellt damit keine pauschale Frage nach „KI oder keine KI“, sondern eine präzisere: Wer übernimmt die methodische Verantwortung?

Laufender Code ist kein Gütesiegel. Er ist der Beweis, dass eine Software Befehle verarbeiten konnte. Ob diese Befehle die Forschungsfrage angemessen beantworten, ist eine separate wissenschaftliche Frage.

Was KI kann und was nicht

Das Ziel ist hier nicht, KI pauschal abzuwerten. LLMs können bei statistischen Arbeiten durchaus nützlich sein, zum Beispiel beim Strukturieren von Syntax, beim Erklären von Fehlermeldungen, beim Kommentieren von Code oder beim Erstellen erster Analysevorschläge.

Was sie nicht leisten können: methodische Entscheidungen treffen, die auf einem tiefen Verständnis der Forschungsfrage, der Datenstruktur und der wissenschaftlichen Anforderungen basieren. Diese Entscheidungen müssen von jemandem getroffen und verantwortet werden, der das Thema kennt.

Was das für Ihre Arbeit bedeutet

Sieben Prüfschritte vor der Abgabe

LLM-Code darf ein Entwurf sein. Er darf aber nicht die letzte methodische Instanz sein. Was bedeutet das konkret? Wer LLM-generierten Statistikcode in einer empirischen Arbeit verwendet, sollte ihn an mindestens diesen sieben Punkten prüfen:

Was Prüferinnen und Prüfer wirklich sehen wollen

Im Kolloquium wird niemand fragen, welche Software den Code erzeugt hat. Die Fragen lauten: Warum haben Sie dieses Verfahren gewählt? Wie haben Sie die Variablen operationalisiert? Was sagen Ihre Ergebnisse in Bezug auf Ihre Hypothese?

Wer diese Fragen nicht beantworten kann, wird es schwer haben, egal wie ordentlich die Tabellen aussehen. Prüferinnen und Prüfer wollen eine begründete, nachvollziehbare und verteidigungsfähige Analyse sehen, keine fehlerfreie Syntax.

Der eigentliche Maßstab

LLMs haben die Einstiegshürde in Statistiksoftware deutlich gesenkt. Das ist gut. Wer früher an einem Syntaxfehler gescheitert wäre, kommt jetzt schneller zu ersten Ergebnissen.

Aber die Hürde, die wirklich zählt, ist eine andere. Sie lautet: Können Sie Ihre Analyse erklären, begründen und verteidigen? Nicht der Code, der läuft, entscheidet über die Qualität einer empirischen Arbeit. Sondern die Analyse, die sich erklären lässt.