Warum Studierende noch coden lernen müssen, wenn KI den Code schreibt
Über Coding Literacy, neue Prüfungsformate und Data-Science-Lehre im Jahr 2026.
Warum diese Frage berechtigt ist
In meinen Veranstaltungen zur Programmierung und zu Data Science kommt inzwischen regelmäßig die Frage auf, warum Studierende noch programmieren lernen sollen. ChatGPT, GitHub Copilot und andere KI-Werkzeuge können innerhalb weniger Sekunden Code erzeugen, erläutern und korrigieren. Wer gerade mühsam die Syntax einer Funktion gelernt hat, kann daher durchaus den Eindruck bekommen, dass diese Arbeit schon bald nicht mehr notwendig sein wird.
Die Frage ist berechtigt, weil sich die praktische Arbeit mit Code tatsächlich verändert hat. Ein Sprachmodell kann beispielsweise eine Datenaufbereitung erstellen, eine Fehlermeldung erklären oder eine Kreuzvalidierung ergänzen. Dabei entstehen häufig Lösungen, für die Einsteiger:innen selbst deutlich mehr Zeit benötigen würden. Diesen technischen Fortschritt in der Lehre zu ignorieren, wäre wenig sinnvoll.
Aus meiner Sicht folgt daraus aber nicht, dass wir auf Coding-Grundlagen verzichten können. Vielmehr verändert sich der Grund, aus dem Studierende diese Grundlagen benötigen:
Studierende müssen nicht coden lernen, obwohl KI Code schreiben kann. Sie müssen coden lernen, weil KI Code schreiben kann.
Bisher bestand ein wesentlicher Teil der Programmierausbildung darin, selbst lauffähigen Code zu erstellen. Diese Fähigkeit bleibt relevant, sie wird aber um weitere Kompetenzen ergänzt. Studierende müssen KI-generierten Code lesen, verstehen, anpassen, testen und gegebenenfalls korrigieren können. Programmierkenntnisse werden damit zunehmend zu einer Voraussetzung, um automatisiert erzeugte Lösungen fachlich kontrollieren zu können.
Lauffähiger Code ist nicht automatisch richtiger Code
KI-generierter Code sieht häufig überzeugend aus. Die Variablennamen sind verständlich, die Kommentare passen zur Aufgabenstellung und das Programm lässt sich ohne Fehlermeldung ausführen. Daraus kann leicht der Schluss entstehen, dass auch die Analyse korrekt ist. Gerade bei Data-Science-Anwendungen ist das jedoch nicht zwingend der Fall.
Viele relevante Fehler betreffen nicht die Syntax, sondern die Logik der Analyse. Bei einem Join können zum Beispiel Beobachtungen vervielfacht werden, weil die verwendeten Schlüssel nicht eindeutig sind. Fehlende Werte können versehentlich vor dem Train-Test-Split unter Verwendung des gesamten Datensatzes ersetzt werden. Dadurch fließen Informationen aus den Testdaten in das Training ein. Ebenso kann ein Merkmal Informationen über die Zielvariable enthalten, die zum späteren Prognosezeitpunkt noch gar nicht verfügbar wären. Der Code läuft in allen drei Fällen, die resultierende Bewertung des Modells ist aber zu optimistisch.
Weitere Probleme entstehen bei der Auswahl und Interpretation von Kennzahlen. Für eine stark unbalancierte Klassifikationsaufgabe reicht die Accuracy häufig nicht aus. Eine hohe Korrelation erlaubt außerdem noch keine kausale Interpretation. Ein Sprachmodell kann zu solchen Problemen passenden Analysecode erzeugen, kennt aber nicht automatisch den Entstehungsprozess der Daten oder den betrieblichen Kontext, in dem ein Ergebnis verwendet werden soll.
Eine kleine qualitative Fallstudie mit fünf Studierenden verdeutlicht diese Ambivalenz. Ein KI-gestütztes Analysewerkzeug konnte die Auseinandersetzung mit statistischen Fragestellungen unterstützen. Gleichzeitig verließen sich Studierende teilweise auf die erzeugten Ausgaben oder verloren den Überblick über den eigenen Analyseprozess (Rao u. a. 2026). Aufgrund der kleinen Fallzahl lassen sich daraus keine allgemeinen Aussagen zur Wirksamkeit ableiten. Das Beispiel zeigt aber, dass die Bereitstellung eines KI-Werkzeugs allein noch kein fachliches Verständnis sicherstellt.
In der Praxis kommt ein weiterer Aspekt hinzu: Für die Folgen einer Analyse ist nicht das verwendete Sprachmodell verantwortlich. Die Verantwortung liegt bei den Personen und Organisationen, die Daten verarbeiten, Modelle auswählen und Ergebnisse für Entscheidungen verwenden. Wer KI-generierten Code einsetzt, muss daher auch beurteilen können, ob dieser Code für die konkrete Aufgabe geeignet ist.
Die Programmierlehre muss sich ebenfalls verändern
Dass Coding-Grundlagen weiterhin notwendig sind, bedeutet nicht, dass Programmierlehre unverändert fortgeführt werden sollte. Reine Syntaxübungen verlieren an Bedeutung, wenn Studierende außerhalb einer Prüfung jederzeit auf Dokumentationen, bestehende Code-Beispiele und KI-Assistenten zugreifen können. Es ist daher wenig hilfreich, den Lernerfolg ausschließlich daran zu messen, ob eine bestimmte Funktion ohne Hilfsmittel auswendig aufgeschrieben werden kann. Denny und Kolleg:innen kommen für die Informatiklehre zu einer ähnlichen Einordnung: Codegenerierende Modelle können viele typische Aufgaben aus einführenden Programmierveranstaltungen lösen, sodass Lernziele, Lehrformen und Prüfungen angepasst werden müssen (Denny u. a. 2024).
In der Statistik- und Data-Science-Lehre werden bereits unterschiedliche Ansätze für den Einsatz generativer KI diskutiert. Ellis und Slade beschreiben unter anderem Einsatzmöglichkeiten für Erklärungen, Beispiele und Feedback, weisen aber auch auf die notwendige kritische Prüfung der Ausgaben hin (Ellis und Slade 2023). Bien und Mukherjee verwendeten generative KI in einem einführenden Data-Science-Kurs für MBA-Studierende zur Erzeugung des Analysecodes. Dadurch konnte sich die Lehrveranstaltung stärker auf Datenfragen und die Interpretation der Ergebnisse konzentrieren (Bien und Mukherjee 2025). Für Zielgruppen, bei denen die eigenständige Softwareentwicklung kein primäres Lernziel ist, kann dies ein sinnvoller Ansatz sein.
Für Studiengänge in Data Science, Statistik oder Wirtschaftsinformatik reicht die Bedienung eines solchen Werkzeugs allerdings nicht aus. Absolvent:innen werden in der Praxis bestehende Analysen weiterentwickeln, fremden Code prüfen, Datenfehler suchen und methodische Entscheidungen begründen müssen. Die Programmierlehre sollte diese Tätigkeiten deshalb stärker berücksichtigen.
Coding Literacy
Der Begriff Coding Literacy beschreibt diese veränderte Zielsetzung recht gut. Coding Literacy bezeichnet nicht nur die Fähigkeit, selbst Code zu schreiben. Sie umfasst auch die Fähigkeit, Code zu lesen und seine Wirkung zu beurteilen. Dazu gehören insbesondere:
- Code in eigenen Worten erklären,
- die Rolle einzelner Datenquellen und Zwischenergebnisse nachvollziehen,
- Annahmen und mögliche Seiteneffekte erkennen,
- eine Lösung an geänderte Anforderungen anpassen,
- Tests und Plausibilitätsprüfungen formulieren,
- Fehlermeldungen systematisch untersuchen,
- Ergebnisse unabhängig validieren und
- den Einsatz von KI-generiertem Code dokumentieren.
Damit verändert sich auch die typische Fragestellung in einer Lehrveranstaltung. Es geht nicht mehr ausschließlich darum, ob Studierende die Syntax einer Funktion kennen. Wichtiger ist, ob sie erklären können, was ein Codeabschnitt mit den Daten macht und ob dieses Vorgehen zur fachlichen Fragestellung passt.
Die Beurteilung einer vorgegebenen Lösung kann dabei anspruchsvoller sein als die Umsetzung eines bekannten Beispiels. Um einen Fehler in einer Modellpipeline zu erkennen, müssen Studierende sowohl den Programmcode als auch die statistische Methode und die Struktur der Daten verstehen. Coding Literacy ist daher keine vereinfachte Form der Programmierausbildung, sondern erweitert diese um Diagnose- und Bewertungskompetenzen.
Grundlagen als Kontrollwissen
Die dafür notwendigen Grundlagen sollten aus meiner Sicht nicht als Liste einzelner Sprachkonstrukte verstanden werden. Entscheidend ist weniger, ob Studierende eine bestimmte Funktion auswendig reproduzieren können. Entscheidend ist, ob sie in einer Analyse erkennen, welche Annahme gerade gemacht wird, welche Datenbasis betroffen ist und woran man einen Fehler bemerken würde.
Zu diesem Kontrollwissen gehört zunächst ein Verständnis der Analyseeinheit: Was bedeutet eine Zeile im Datensatz? Welche Beobachtungen gehören zur Zielpopulation? Welche Information wäre zum Entscheidungszeitpunkt tatsächlich verfügbar? Viele Fehler in KI-generiertem Code werden erst sichtbar, wenn diese Fragen vor der technischen Umsetzung geklärt sind.
Ebenso wichtig ist ein Verständnis dafür, wie sich Daten im Laufe einer Analyse verändern. Eine Aggregation verändert die Ebene, auf der eine Aussage getroffen wird. Die Verknüpfung mehrerer Datenquellen kann die Fallzahl verändern oder unbeabsichtigt bestimmte Gruppen stärker gewichten. Die Behandlung fehlender Werte kann harmlos sein oder Information aus späteren Analyseschritten vorwegnehmen. Studierende müssen solche Veränderungen nicht nur ausführen können; sie müssen einschätzen können, ob sie zur fachlichen Frage passen.
Für die Modellierung bleibt die Logik der Evaluation zentral. Eine automatisch erzeugte Kreuzvalidierung ist nur dann hilfreich, wenn klar ist, was dabei getrennt werden muss, welche Kennzahl zur Fragestellung passt und welche einfache Vergleichslösung als Baseline dient. Ohne dieses Wissen kann ein KI-Werkzeug zwar einen technisch sauberen Workflow erzeugen, aber keine fachlich belastbare Bewertung garantieren.
Schließlich gehört dazu die Fähigkeit, eine Analyse in überprüfbare Zwischenschritte zu zerlegen. Wer einen Vorschlag eines KI-Assistenten übernimmt, sollte sagen können, welche Teile der Lösung geprüft wurden, welche Annahmen offen bleiben und wie Datenherkunft, methodische Entscheidungen und Interpretation dokumentiert sind. In diesem Sinn sind die Grundlagen nicht Selbstzweck. Sie sind die Voraussetzung dafür, automatisierte Analysen verantwortlich nutzen zu können.
Mehr Automatisierung erfordert mehr Überblick
Die Automatisierung in Data Science beschränkt sich nicht auf die Erzeugung einzelner Codeabschnitte. AutoML-Systeme übernehmen bereits Teile der Datenvorbereitung, Modellwahl und Optimierung. KI-Agenten können mehrere Arbeitsschritte verbinden und selbstständig unterschiedliche Werkzeuge aufrufen. Damit wird es einfacher, für eine gegebene Aufgabenstellung eine vollständige Analyse zu erzeugen.
Die fachlichen Entscheidungen verschwinden dadurch nicht. Es muss weiterhin festgelegt werden, welche Zielgröße untersucht wird, welche Daten verwendet werden dürfen und anhand welcher Kennzahl ein Modell bewertet wird. Ebenso ist zu prüfen, ob eine einfache Baseline vorhanden ist und ob ein komplexeres Modell tatsächlich einen relevanten Mehrwert liefert. Diese Fragen können nicht allein durch die technische Ausführung beantwortet werden.
Mit zunehmender Automatisierung wird daher das Verständnis des gesamten Analyseprozesses wichtiger. Studierende sollten nicht nur einzelne Funktionen kennen, sondern nachvollziehen können, wie Datenaufbereitung, Modellierung, Evaluation und Interpretation zusammenhängen. Nur so lässt sich erkennen, an welcher Stelle einer automatisierten Analyse ein Fehler entstanden ist.
KI wird Teil der Data-Science-Umgebung
Diese Entwicklung lässt sich inzwischen direkt in den Werkzeugen beobachten, mit denen Datenanalysen durchgeführt werden. Dabei geht es nicht mehr nur um eine allgemeine Chat-Anwendung neben der eigentlichen Entwicklungsumgebung. KI wird zunehmend in die Umgebung integriert, in der Daten geladen, transformiert, visualisiert, modelliert und dokumentiert werden. Dadurch erhält sie mehr Kontext und kann passendere Vorschläge erzeugen. Gleichzeitig wird ihre Nutzung schwerer von der eigentlichen Analyse zu trennen.
Man kann diese Werkzeuge auch als agentische, also handlungsfähige, Data-Science-Umgebungen verstehen. Ähnlich wie spezialisierte Coding-Agenten in der Softwareentwicklung nicht nur eine Frage beantworten, sondern Dateien lesen, Code ändern, Tests ausführen und mehrere Schritte koordinieren, können Data-Science-Assistenten zunehmend den Zustand einer Analyse erfassen und darauf aufbauend nächste Arbeitsschritte vorschlagen oder ausführen. Der Unterschied liegt vor allem im Gegenstand: Nicht nur Programmdateien sind relevant, sondern auch Daten, Zwischenergebnisse, Visualisierungen, Modellobjekte und Evaluationsmetriken.
Code- und Notebook-Umgebungen
Eine erste Form sind code- und notebookzentrierte Umgebungen. Posit Assistant kann in Positron neben geöffneten Dateien und ausgewähltem Code auch Informationen aus der interaktiven Sitzung berücksichtigen, beispielsweise geladene Daten, erzeugte Grafiken und die Konsolenhistorie (Posit Software, PBC 2026). Dadurch kann eine Frage unmittelbar auf die aktuelle Analyse bezogen werden. Für die Lehre ist dies interessant, weil der Assistent nicht mehr nur eine isolierte Programmierfrage beantwortet, sondern den Zustand einer laufenden Datenanalyse einbezieht.
Jupyter AI verfolgt einen offeneren und stärker konfigurierbaren Ansatz. Das Projekt verbindet KI-Agenten mit Notebooks in JupyterLab. Je nach Konfiguration können diese Agenten Dateien lesen und schreiben, Befehle ausführen und mit Notebooks interagieren (Project Jupyter 2026). Gespräche werden dabei als Dateien im jeweiligen Arbeitsbereich gespeichert. Dies erleichtert eine nachvollziehbare Dokumentation, wirft aber zugleich Fragen danach auf, welche Modelle angebunden werden, welche Daten an diese übermittelt werden und welche Aktionen ein Agent ausführen darf.
In integrierten Datenplattformen reicht die Unterstützung noch weiter. Der Databricks Assistant kann in Notebooks und Editoren Code erzeugen, erklären und debuggen. Ein zusätzlicher Data-Science-Agent ist darauf ausgerichtet, mehrstufige Workflows aus einer einzelnen Aufgabenbeschreibung zu koordinieren (Databricks 2026). Damit verschiebt sich die Unterstützung von einzelnen Codevorschlägen hin zur Bearbeitung größerer Teile eines Analyseprozesses.
Visuelle Workflows
Eine zweite Form sind visuelle Low- und No-Code-Umgebungen. Systeme wie KNIME, Orange oder kommerzielle Analyseplattformen stellen Data-Science-Prozesse als Workflows dar. Generative KI passt dazu nicht deshalb, weil Sprachmodelle besonders gut grafische Oberflächen bedienen. Interessant wird es vielmehr dort, wo das visuelle Werkzeug selbst eine formale Repräsentation des Workflows besitzt. Dann kann ein KI-System aus einer Aufgabenbeschreibung Knoten, Verbindungen, Kommentare oder Konfigurationen erzeugen. KNIME beschreibt für den eigenen AI Assistant beispielsweise einen Build-Modus, in dem aus einem Prompt Knoten und zugehörige Kommentare auf der Workflow-Fläche ergänzt werden können (KNIME 2026).
Damit entsteht eine Zwischenform zwischen Chat-Antwort und Programmcode. Der Prompt liefert den Einstieg, der visuelle Prozess macht die vorgeschlagenen Schritte sichtbar. Studierende können einzelne Knoten ausführen, Zwischenergebnisse prüfen und den Ablauf diskutieren. Gerade für Lernende mit wenig Programmiererfahrung kann dies den Zugang zu Data Science erleichtern. Auch aktuelle Arbeiten zu webbasierten visuellen Analyseumgebungen betonen diesen niedrigeren Einstieg und die Möglichkeit, interaktive Workflows in Lernkontexte einzubetten (Bevec u. a. 2026).
Die Risiken sind in beiden Werkzeugklassen ähnlich und werden durch agentische Fähigkeiten eher größer als kleiner. Ein automatisch erzeugter Codeabschnitt kann plausibel aussehen. Ein automatisch erzeugter Workflow kann ebenso überzeugend wirken, weil er geordnet, kommentiert und vollständig erscheint. Wenn ein System zusätzlich mehrere Schritte selbst koordiniert, kann sich ein früher Fehler unbemerkt durch die gesamte Analyse fortsetzen. Ein falsch gesetzter Filter, eine ungeeignete Aggregation oder eine problematische Evaluation kann in einem visuellen Workflow genauso vorkommen wie in einem Skript. Bei komplexen Workflows wird nicht mehr der Code zur Black Box, sondern das Zusammenspiel vieler Knoten und automatisch ausgeführter Entscheidungen.
Für die Lehre ergibt sich daraus eine gemeinsame Konsequenz. Studierende sollten nicht nur lernen, wie eine Anfrage formuliert wird. Sie müssen auch verstehen, welchen Kontext ein Assistent verwendet, wohin Daten übertragen werden, welche Änderungen er vorgenommen hat, welche Schritte automatisch ausgeführt wurden und wie sich zentrale Ergebnisse unabhängig überprüfen lassen. Promptbasierte Workflows, KI-generierter Code und agentisch erzeugte Analyseschritte sollten daher als prüfbare Hypothesen behandelt werden. Die konkrete Oberfläche kann sich schnell ändern; diese Kontrollfragen bleiben bestehen.
Ein mögliches Lehrmodell
Für die Gestaltung einer Lehrveranstaltung bietet sich aus meiner Sicht eine Aufteilung in drei Phasen an.
KI-arme Grundlagenphase
In einer ersten Phase erarbeiten sich die Studierenden zentrale Abläufe weitgehend selbst. Diese Phase muss nicht sehr lang sein. Sie sollte aber sicherstellen, dass die Studierenden ein eigenes Verständnis dafür entwickeln, wie Daten in einer Analyse entstehen, verändert, geprüft und bewertet werden. Code sollte nicht nur als eine Folge plausibel klingender Textbausteine wahrgenommen werden.
KI-arm bedeutet hierbei nicht, dass keinerlei Hilfsmittel verwendet werden dürfen. Dokumentationen, Hilfeseiten und vorhandene Beispiele gehören zur Programmierung. Der vorübergehende Verzicht auf generative KI soll lediglich ermöglichen, dass die grundlegenden Strukturen zunächst selbst nachvollzogen werden.
KI-unterstütztes Arbeiten
In der zweiten Phase kann generative KI gezielt eingesetzt werden. Studierende lassen sich beispielsweise eine Funktion erstellen oder einen bestehenden Codeabschnitt erklären. Anschließend müssen sie die Lösung testen, an veränderte Daten anpassen und die einzelnen Schritte begründen. Hierbei lässt sich auch gut zeigen, dass eine plausible KI-Antwort nicht immer korrekt ist.
Eine Aufgabe könnte zum Beispiel einen lauffähigen Code enthalten, bei dem die Imputation vor dem Train-Test-Split erfolgt. Die Studierenden sollen den Fehler erkennen, erklären und korrigieren. Eine andere Aufgabe kann verlangen, eine erzeugte Visualisierung an eine geänderte Fragestellung anzupassen. Der Schwerpunkt liegt damit nicht mehr nur auf der Erzeugung, sondern auch auf der Überprüfung und Weiterentwicklung von Code.
Projekte mit dokumentierter KI-Nutzung
In einer abschließenden Projektphase kann der Einsatz generativer KI grundsätzlich erlaubt sein. Bewertet werden dann das Problemverständnis, die Qualität der Datenaufbereitung, die Modellwahl, die Evaluation, die Reproduzierbarkeit und die Kommunikation der Ergebnisse. Zusätzlich dokumentieren die Studierenden, wofür sie KI eingesetzt haben, welche Vorschläge übernommen oder verworfen wurden und wie sie die zentralen Ergebnisse überprüft haben.
Auch das Schreiben des Projektberichts ist hierbei Teil der fachlichen Leistung. DeLuca und Kolleg:innen verglichen Texte von Sprachmodellen mit Texten von Studierenden und publizierenden Wissenschaftler:innen. Dabei zeigten sich Unterschiede unter anderem in der Strukturierung von Informationen, der sprachlichen Darstellung von Sicherheit und der Berichterstattung statistischer Ergebnisse (DeLuca u. a. 2025). Ein sprachlich glatt formulierter KI-Text ist daher nicht automatisch ein fachlich guter Analysebericht. Studierende sollten zeigen, dass sie Ergebnisse angemessen interpretieren sowie Unsicherheiten und Grenzen der Analyse darstellen können.
Geeignete Prüfungsformate
Wenn generative KI zur normalen Arbeitsumgebung gehört, sollten Prüfungen stärker erfassen, ob Studierende Code verstehen und beurteilen können. Hierzu eignen sich beispielsweise folgende Aufgaben:
- einen KI-generierten Codeabschnitt erklären und die darin enthaltenen Annahmen benennen,
- fehlerhaften, aber lauffähigen Code untersuchen und korrigieren,
- eine vorhandene Lösung an eine veränderte Fragestellung anpassen,
- Data Leakage in einer Modellpipeline erkennen,
- die Eignung verwendeter Modellmetriken beurteilen,
- eine einfache Baseline mit einem komplexeren Modell vergleichen,
- einen automatisch erzeugten Workflow oder Agentenverlauf prüfen und zentrale Entscheidungen begründen,
- die Nutzung eines KI-Werkzeugs dokumentieren und reflektieren,
- Entscheidungen in einem kurzen mündlichen Code Review begründen oder
- einen reproduzierbaren Analysebericht mit Datenherkunft, Annahmen, Unsicherheiten und Grenzen erstellen.
Solche Aufgaben verhindern nicht automatisch jede unzulässige Nutzung von KI. Sie prüfen aber unmittelbarer die Kompetenzen, die auch in der späteren Praxis benötigt werden. Entscheidend ist nicht nur, ob am Ende ein lauffähiges Programm vorliegt, sondern ob die Studierenden dessen Funktionsweise erklären und die Qualität der Ergebnisse beurteilen können.
Fazit
Generative KI macht das Erlernen von Coding-Grundlagen nicht überflüssig. Sie verändert jedoch die Schwerpunkte der Programmierausbildung. Die manuelle Erzeugung von Standardcode wird weniger wichtig, während Codeverständnis, Fehlerdiagnose, Validierung und Dokumentation an Bedeutung gewinnen.
Für die Data-Science-Lehre bedeutet dies, dass wir weniger Wert auf das Auswendiglernen einzelner Syntaxelemente legen sollten. Gleichzeitig benötigen Studierende weiterhin ein solides technisches und methodisches Fundament. Nur damit können sie beurteilen, ob automatisch erzeugter Code tatsächlich zur Aufgabenstellung, zu den Daten und zum späteren Anwendungskontext passt.
KI kann viele Schritte einer Analyse beschleunigen. Zunehmend geht es dabei nicht nur darum, dass KI einzelne Codezeilen erzeugt, sondern dass sie Teile des Analyseprozesses vorbereitet, ausführt oder koordiniert. Die Verantwortung für die fachliche Richtigkeit der Analyse bleibt jedoch bei den Menschen, die sie erstellen und verwenden. Genau deshalb müssen Studierende auch dann noch coden lernen, wenn immer mehr Code und immer mehr Analyseschritte von KI erzeugt werden.