Der Data Scientist ist tot…

Kitreel | shutterstock.com

Ein Freund von mir spielte einmal in der Laeiszhalle in Hamburg. Der Saal war ausverkauft, die Herren sahen elegant aus in ihren Zweireihern und an den Hälsen der Damen hingen Erbstücke, die nur für besondere Anlässe getragen werden. Von meinem Platz aus hatte ich einen guten Blick auf meinen Freund, der weit vorne im Orchester saß und virtuos die Geige spielte. Er sah angestrengt aus, Pizzicato, der Dirigent hob seinen Taktstock, Vibrato.

Nach der Vorstellung traf ich ihn, als er gerade sein Instrument verstaute. Ich teilte ihm mit, wie sehr mir das Musikstück gefallen hat, lobte ihn für sein versiertes Geigenspiel und fragte ihn, wie er selbst seinen Auftritt einschätzte. Ich war überrascht, als er meinte, er habe sich ein paarmal verspielt. Auf meinen fragenden Blick erwiderte er nur: „Zum Glück hat unser Dirigent mich schnell wieder eingefangen – er hat uns alle im Blick.“

Als Musiklaie hatte ich die Rolle des Dirigenten bis dahin nicht richtig verstanden. Schließlich hat dieser über vierzig Musiker vor sich, die ihre Instrumente allesamt besser beherrschen als er selbst. Nun war mir klar: Ohne ihn würde das Stück nicht halb so gut harmonieren. Denn so technisch versiert die einzelnen Musiker auch sein mögen: Es braucht jemanden, der das große Ganze im Blick hat. Der nicht bloß weiß, wie ein einzelnes Instrument zu klingen hat, sondern wie alles zusammenwirken soll. Eine weitere Erkenntnis: Ein Orchester und ein Data-Science-Team haben deutlich viel mehr gemeinsam, als es auf den ersten Blick scheint.

Der Tag des Dirigenten

Heutzutage nutzt jeder Data Scientist Large Language Models (LLMs), um schneller und besser Code zu schreiben. In der Prä-GPT-Ära kostete es mich meist ein bis zwei Wochen, einen (bei Stakeholdern vorzeigbaren) Prototypen zu entwickeln. Jetzt brauche ich dafür weniger als zwei Tage. Die Produktivitätsgewinne sind also enorm. Doch das ist nur eine oberflächliche Veränderung. Wer genauer hinsieht, erkennt einen viel fundamentaleren Wandel.

Das Data-Science-Team von InnoGames, dem ich angehöre, besteht aus sieben Menschen. Vor etwa einem Jahr entschieden wir uns, den Großteil der Programmierarbeit von Claude Code übernehmen zu lassen. Damit traten wir bei uns etwas los, was über kurz oder lang auf jeden Data Scientist zukommen wird: Wir wurden zu Dirigenten. Bislang hatten wir uns eher als Musiker gesehen: Wir wussten genau, wie unsere Instrumente zu spielen waren. Wir kannten unseren Code und unsere Pipelines in- und auswendig – und wussten, welche Techniken für welche Anwendungsfälle zu nutzen waren.

Heute treten wir einen Schritt zurück, um das große Ganze besser im Blick zu haben. Wir koordinieren KI-Agenten, die für uns Teile des Gesamten bauen. Dabei müssen wir sicherstellen, dass dieses große Ganze so aussieht, wie es aussehen soll: Mehr und mehr stehen Architektur und Design Patterns im Fokus.

Während ich über unser neues Selbstbild reflektiert habe, fragte ich mich einmal, ob ich jemals auch nur etwas so Simples wie einen Decision Tree komplett in purem Python geschrieben hatte. Die Antwort lautete nein. Das ist unserer Rolle allerdings überhaupt nicht fremd: Datenwissenschaftler importieren seit jeher den Code den Andere geschrieben haben, um ihn in ihrem eigenen Code zu verwenden.

Die agentische Erlahmung

Der von unserem Team neu eingeschlagene Weg hatte die Idee dahinter nur auf das nächste Level gehoben. Ein knappes Jahr nach dem Umstieg auf „fully agentic“ fühlt sich meine Rolle als Data Scientist immer mehr so an, wie ich mir das ursprünglich einmal vorgestellt hatte. Was wirklich im Kern des Aufgabenfeldes eines Data Scientists steht, ist die Iteration: Wir bauen Modelle, überprüfen die Ergebnisse, wägen ab, überlegen, was wir anpassen können (oder ob wir einen anderen Ansatz ausprobieren sollten) und starten dann die nächste Iteration. Solange, bis wir mit dem Ergebnis zufrieden sind. Indem wir Programmier-Tasks delegieren, können wir schneller und mehr iterieren. Zudem fällt es uns auch leichter, einen wahrscheinlich hoffnungslosen Ansatz zu verwerfen und komplett neu zu starten.

Angesichts einer solchen Veränderung der Rolle des Data Scientists ist es mit einer überarbeiteten Berufsbeschreibung nicht getan. Denn dieser Wandelt geht auch mit einer Änderung der Arbeitsweisen einher. Im Kern dieser neuen Art zu arbeiten, stand für uns, Claude Code eher als Infrastruktur – oder sogar als Mitarbeiter – anzusehen, statt als ein Programm, das man morgens öffnet und abends wieder schließt.

KI-Agenten brauchen Kontext – das implizite Wissen, das wir über Jahre hinweg angehäuft haben – und Coding Guidelines. Sie brauchen kleinere Aufgaben, die von ihnen perfekt ausgeführt werden können und insgesamt gesehen das große Ganze bilden. Vieles von unserer Arbeitsweise findet jetzt in der Konzeptphase statt – und wenn es um die Architektur geht. Sprich, bevor überhaupt Code geschrieben wird. Man muss verstehen, dass es nicht nur darum geht, bessere Prompts zu schreiben. Essenziell ist, sich eine Umgebung aufzubauen, in der die Agenten als integraler Teil funktionieren.

Nachdem wir unseren neuen Weg eingeschlagen hatten, fiel uns jedoch sehr schnell etwas auf, das sich kontraintuitiv anfühlte: Wir wurden langsamer – die Produktivitätsgewinne waren weg. Aus heutiger Perspektive lässt sich dieses scheinbare Paradox einfach erklären: Wir mussten die Agenten trainieren. Ihnen fehlte der Kontext, deswegen war der generierte Code fehlerhaft – und man musste überall ganz genau hinsehen.

Doch mit der Zeit und besserem Kontext wurden die Agenten immer besser. Nach etwa drei Monaten waren wir auf dem Produktivitätslevel von vor der Umstellung angekommen und wurden immer sicherer in unserer neuen Rolle. Nicht zuletzt hatten wir dabei auch Glück: Unsere Chefin gab uns die Zeit, die wir brauchten. Es wurde nicht erwartet, dass uns die Umstellung sofort produktiver machen würde. Und das war auch gut so.

KI-Verlockungen entgegenwirken

Ist knapp ein Jahr nach der Umstellung alles besser geworden? Nein. Es tauchen immer wieder neue Probleme auf, die frische Lösungsansätze benötigen. Mit neueren LLMs und mehr Kontext werden die Agenten zwar besser. Aber das führt dazu, dass man sehr schnell in eine Haltung kommt, in der die Coding-Vorschläge der Agenten vorschnell angenommen werden. Darunter leiden nicht nur die eigenen Programmier-Fähigkeiten: Man kann sich lebhaft ausmalen, welche Probleme entstehen, wenn nur noch die KI-Agenten den Code verstehen.

Berufseinsteiger (nicht nur) im Bereich Data Science haben es dabei besonders schwer: Zum einen, weil Junior-Rollen nun weniger gesucht werden. Zum anderen, weil Einsteigern noch das tiefere Verständnis fehlt und es gleichzeitig sehr verlockend ist, jegliche Bugs an Claude Code zu übergeben. Der löst diese zwar – aber eben ohne, dass es beim Data Scientist zu einem Lernprozess gekommen ist. Dagegen sind auch erfahrene Team-Mitglieder nicht immun. Darum versuchen wir bei Innogames, diesen Verlockungen mit kreativen Ideen entgegenzuwirken. So haben wir etwa einen monatlichen „No AI“-Tag und gemeinsame Pair-Programming-Sessions eingeführt. Ob das ausreichend ist oder sich andere Methoden als sinnvoller erweisen, wird die Zukunft zeigen.

Als ich meinem Musikerfreund kürzlich von meiner Entwicklung zum Dirigenten berichtete, musste er schmunzeln und verriet mir, dass hinter dem Rücken des Dirigenten auch viel über diesen gelacht wird. Und wer weiß, vielleicht sprechen die KI-Agenten ja auch untereinander über mich? Falls ja, würde ich mir wünschen, dass dabei folgender Satz fällt: „Zum Glück hat unser Dirigent mich schnell wieder eingefangen, der hat uns alle im Blick.“ (fm)