KI-Coding-Agenten im Data-Science-Praxistest: Wer baut autonom eine verlässliche Prognose?

Eine Möglichkeit sind Benchmark-Tabellen. Sie zeigen die tatsächliche Leistung von Programmieragenten bei der Bewältigung einer großen Zahl von Coding-Aufgaben - gemessen über die Kosten, den Token-Verbrauch und Ausführungszeit sowie die Ergebnisqualität.

In diesem Artikel legen wir den Fokus aber auf die praktische Data-Science-Perspektive. Was passiert, wenn man Agenten eine echte Aufgabe gibt, wie sie in einem Data-Science-Team täglich anfällt und die Agenten autonom arbeiten lässt?

Konkret haben wir mehrere Systeme mit teils verschiedenen Sprachmodellen auf eine alltägliche Energieprognose angesetzt. Spoiler: Die Prognosen lagen größtenteils dicht beieinander und waren brauchbar. Der Teufel steckt im Detail: Welche Forecast-Methoden wurden gewählt? Wie handwerklich sorgfältig arbeitet der Agent? Könnten wir das Ergebnis direkt produktiv setzen?

Data-Science-Praxistest der KI-Coding-Agenten: Day-Ahead Prognose als Aufgabe

Für unseren Praxistest haben wir als Aufgabe eine klassische Day-Ahead-Prognose gewählt. Vorherzusagen waren zwei Zeitreihen eines Energieversorgers:

• Zeitreihe 1 - Haushaltslast: glatt, klare Tages- und Wochenmuster
• Zeitreihe 2 - Windproduktion: volatil, mit langen Flautephasen

Beide im 15-Minuten-Takt für den jeweils nächsten Tag. Die Methodenwahl war bewusst völlig freigestellt. Ein trainiertes Modell, ein statistisches Verfahren oder ein vortrainiertes Foundation-Model waren erlaubt.

Damit die Agenten nicht einfach die Testergebnisse nachschlagen können, liefern sie statt eines fertigen Prognose-CSVs eine Python-Funktion. Diese ruft in einer CI-Pipeline den Testprozess für jeden der 30 Testtage separat auf, sodass der Agent die Testdaten nicht sehen kann. So wird ein fairer Vergleich der KI-Agenten ermöglicht und Schummeln technisch ausgeschlossen. Diese Übergabe per definierter Funktion wird auch als Contract bezeichnet.

KI-Coding-Agenten im Praxistest: Die Bewertungskriterien

Für die Bewertung haben wir vier zentrale Kriterien berücksichtigt:

• Prognosegüte: Vergleich zu naivem Benchmark
• Autonomie: Wie weit kam der Agent allein? Wie viele Eingriffe waren nötig?
• Methodentreue: Wurde das Problem methodisch sauber gelöst?
• Code-Qualität: Wie lesbar, strukturiert und reproduzierbar ist der Code?

KI-Coding-Agenten: Das Teilnehmerfeld im Data-Science-Praxistest

Zwei Klassen von Agenten treten an: Terminal-CLIs, die als Kommandozeilen-Agent direkt im Terminal laufen, sowie IDE-Assistenten, die in eine Entwicklungsumgebung eingebettet sind. Als Modelle haben wir aktuelle Mittelklassemodelle gewählt, die für derartige Coding-Aufgaben empfohlen werden und in diesem Feld ein gutes Preis-Leistungs-Verhältnis bieten.

Werkzeug	Klasse	Modell
Claude Code	Terminal-CLI	Sonnet 4.6
Codex CLI	Terminal-CLI	GPT-5.4
Junie	IDE (PyCharm)	GPT-5.4, Gemini 3.5 Flash, Sonnet 4.6
Posit Assistant	IDE (Positron)	GPT-5.4
KI-CODING-AGENTEN IM VERGLEICH

Junie haben wir mit drei verschiedenen Modellen laufen lassen, um sauber zwischen Agenten-Tool und Modell zu trennen. Die Läufe kosteten zwischen zwei und vier Dollar und dauerten zwischen einer halben und anderthalb Stunden.

KI-Coding-Agenten im Data-Science-Praxistest - die Ergebnisse

Bewertungskriterium 1: Prognosegüte

Alle sechs Varianten haben erfolgreich lauffähige Prognosefunktionen erstellt. Gewertet wird hier wie viel genauer (prozentuale Differenz des Mean Absolute Error) die Prognosen im Vergleich zur saisonal-naive Benchmark sind. Die wichtigsten Erkenntnisse zur Prognosegüte im Überblick:

• Die meisten Lösungen schlugen bei beiden Zeitreihen die saisonal-naive Referenz deutlich.
• Bei der herausfordernderen Windprognose lagen Claude Code, Codex und Posit in diesem Experiment eng beieinander. Die drei Junie-Varianten folgen mit etwas Abstand.
• Mehr Streuung gibt es bei der Stromlast-Prognose: Junie mit Gemini lieferte hier den stärksten Einzellauf im gesamten Feld, während Junie mit Sonnet sehr schlechte Prognosen bereitstellte.

Die Erkenntnis, welche sich daraus mitnehmen lässt: Wer nur auf die Metrik schaut, sieht ein enges Feld. Das taugt jedoch nicht als alleiniges Entscheidungskriterium, insbesondere bei einem Lauf pro Variante, der immer auch von Zufälligkeiten der Aufgabe abhängt.

Bewertungskriterium 2: Autonomie

Im zweiten Schritt blicken wir auf die Eigenständigkeit der Agenten und inwiefern menschliches Eingreifen nötig ist.

Beim autonomen Agieren zeigte sich ein klares Bild:

• Claude Code und Codex arbeiteten im Auto-Mode ohne Rückfragen durch
• Junie und Posit stellten zwischendurch Genehmigungsanfragen

Darüber hinaus benötigte sowohl der Posit Assistant als auch Codex einen manuellen Eingriff, um sich aus einem zu langwierigen Trainingsschritt (20+ Minuten) zu befreien.

Bewertungskriterium 3: Methodentreue

Als Machine-Learning-Methodik wurden wie erwartet überwiegend Gradient-Boosting-Lösungen erzeugt. Jedes Tool hat hierfür auf Wetterdaten zugegriffen und diese nebst Zeitfeatures in die Prognosen einfließen lassen. Das ist für dieses Data Setting eine solide Wahl und somit eine akzeptable Problemlösung. Als Ausnahme davon wählte Codex für beide Zeitreihen Ridge Regression Modelle und der Posit Assistant nahm für die Lastprognose eine Gewichtung der gelaggten Werte vor, ohne dass dies einen nennenswerten Einfluss auf die Prognosegüte nimmt.

Keiner der sechs Kandidaten hat ein modernes Foundation Model für Zeitreihen herangezogen. Mehr dazu gleich.

Darüber hinaus haben sich alle Modelle bei den Wetterdaten einen methodischen Fehler geleistet. Es wurden sowohl für die vergangenen als auch für zukünftige Werte modellierte Ist-Werte (ERA5-Modell) verwendet. Zum Zeitpunkt der Prognose können zukünftige Ist-Werte jedoch noch nicht vorliegen, sodass insbesondere bei stark wetterabhängigen Windstromprognosen der Prognosefehler unrealistisch niedrig dargestellt wird. Dieser klare Fehler hätte mittels der ebenfalls über die Open-Meteo-Schnittstelle verfügbaren letzten Wetterprognose mit vertretbarem Aufwand vermieden werden können. Keines der Modelle hat diesen Aspekt berücksichtigt.

Ein weiterer methodischer Schwachpunkt ist beim Codex-Ergebnis zu finden. Hier wird die vorgegebene Struktur der Funktion nicht eingehalten. Die Daten werden statt über den Funktionsparameter direkt aus der Datenbank eingelesen. Derartiges abweichendes Verhalten führt in der Praxis oftmals zu kniffligen Bugs. Junie mit Sonnet 4.6 hat mit einem technisch aufwändigen Ansatz (Feature Engineering und Sampling) das Problem overengineered, sodass es bei der Verbrauchszeitreihe zu den sehr schlechten Prognosen kam.

Bewertungskriterium 4: Codequalität

Insgesamt zeigt sich bei allen Coding-Agenten eine solide, funktionale Arbeit. Herausragend guten Code liefert jedoch keiner der Kandidaten von Haus aus. Die eigentliche Aufgabenstellung wird in allen Fällen korrekt gelöst und Type Hints finden sich durchgängig im generierten Code. Bei den Docstrings zeigt sich hingegen ein Unterschied: Nur Junie GPT liefert diese zuverlässig mit. Einen echten Ausreißer nach unten leistet sich Codex, der die Daten unnötigerweise von Polars- in Pandas-Dataframes konvertiert. Das ist ein Umweg, der weder der Performance noch der Codequalität zuträglich ist. Letztlich bleibt festzuhalten, dass kein Agent Code abliefert, der einer kritischen Code-Review ohne Anmerkungen standhalten würde. Ein erfahrener Reviewer würde bei jeder der sechs Lösungen noch die eine oder andere formale Nachbesserung einfordern.

Gesamtübersicht nach Kriterien

Kandidat	Prognose	Autonomie	Methode	Code
Claude Code (Sonnet)	+	+	○	○
Codex (GPT)	+	○	-	-
Junie (GPT)	+	○	○	+
Junie (Gemini)	+	○	○	○
Junie (Sonnet)	-	○	-	○
Posit Assistant (GPT)	+	-	○	○

+ gut | ○ mittel | - schwach

Zwischenfazit: Im konkreten Beispiel konnten Codex und Junie mit Sonnet am wenigsten überzeugen. Claude Code zeigte die stabilste Leistung über unsere Kriterien hinweg. Junie mit GPT oder Gemini sowie Posit Assistant liegen dazwischen.

Time Series Foundation Models: Die Erkenntnis des blinden Flecks

Die Aufgabe war methodisch offen. Trotzdem griffen fast alle Agenten zu klassischem Gradient Boosting mit Wetter- und Kalenderfeatures. Kein einziger zog ein Time-Series-Foundation-Model in Betracht, obwohl genau diese Modellklasse für solche Aufgaben inzwischen sehr stark ist.

Wir wollten wissen, ob das an mangelnder Kenntnis liegt, und setzten nachträglich einen Lauf außer Konkurrenz an. Diesmal mit der Vorgabe, ein modernes Foundation-Model (Chronos 2 von Amazon) mit Wetterdaten zu verwenden. Das Ergebnis war beim Wind das beste des ganzen Felds und bei der Last oben mit dabei. Das deckt sich mit dem, was wir bei eoda in Kundenprojekten mit vergleichbaren Energiedaten sehen: Foundation-Models mit Wetterkovariaten schlagen klassisches ML mit aufwändiger Hyperparameter-Optimierung.

Bemerkenswert ist, wie schwer dieser Befund zu erzeugen war. Ein erster Versuch, den Agenten per Prompt in Richtung Foundation-Model zu beeinflussen, wurde schlicht ignoriert. Claude Code nutzte erneut Gradient Boosting. Erst ein zweiter, deutlich strengerer Prompt führte zum Ziel. Möglicher Grund dafür könnte sein, dass die getesteten Modelle Chronos 2 (Oktober 2025) aufgrund ihres knowledge cutoffs im Training noch nicht kennen und kein Agent von sich aus initial nach der besten Methode recherchiert hat.

Junie im Detail

Alle drei Varianten mit Junie haben, unabhängig von den Modellen, in der Tendenz schwächere Prognosen als Claude Code, Codex oder Posit erstellt.

Weil Junie in derselben Umgebung mit drei Modellen lief, ließ sich hier Werkzeug und Modell sauber trennen. In diesem Experiment war Gemini 3.5 Flash am stärksten bei der Last, GPT-5.4 ausgeglichen über beide Zeitreihen und Sonnet 4.6 fiel deutlich ab. Als Einschränkung bleibt auch hier, dass wir je ein Lauf pro Modell gemacht haben, sodass dies nur eine Tendenz und keinen belastbaren Vergleich darstellt.

Coding-Agenten im Data-Science-Praxistest: Die Testfälle im Überblick

Für einen Überblick über den durchgeführten Test hier die eingebauten Herausforderungen und wie das Teilnehmerfeld damit umging:

Testfall	Was geprüft wird	Ergebnis im Feld
Störreihen in den Daten	Filtert der Agent die richtigen Zeitreihen aus der Datenbank	Von allen sauber gelöst
Wetterdaten beschaffen	Findet und zieht der Agent eigenständig Wetterdaten	Von allen gelöst, aber stets Istwerte statt Prognosen
Kontext nutzen	Nutzt die verfügbaren Daten für die Funktion	Meist korrekt, ein Verstoß (Codex)
Physikalische Grenzen	Keine negativen oder unmöglichen Werte	Überwiegend beachtet
Methodenwahl	Wird die beste Methode gewählt	Überwiegend Gradient Boosting, kein Foundation Model gewagt, ein methodischer Fehlschlag (Junie Sonnet)

Fazit für die Praxis

Jede der sechs getesteten Kombinationen machte einen grundsätzlich guten Eindruck bei der Bewältigung der Data Science Aufgabe. Dennoch sind die Ergebnisse noch ein Stück weit von einer direkt produktiv einsetzbaren Lösung entfernt.

Vollständige Autonomie und zugleich makellose Ergebnisse sind für Aufgaben mit diesem mittleren Schwierigkeitsgrad derzeit nicht zu erwarten. Entsprechend empfiehlt es sich, möglichst konkrete Anforderungen zu definieren, um die Autonomie des Agenten einzuhegen.

Überraschend war, dass keine der getesteten Kombinationen initial eine Methodenrecherche durchgeführt hat, um neuste Ansätze in Erwägung zu ziehen. Hier erscheint der konkrete Rechercheaufruf im Prompt sachdienlich.