KI braucht Entwickler, nicht nur Data Scientists

8 Min. Lesezeit

Dasselbe Wort, ein anderer Beruf

Zwei Berufe, in ein Wort gequetscht

Die sauberste Kurzdefinition stammt noch immer von Drew Conways Data Science Venn Diagram: Data Science sitzt dort, wo praktische Programmierfähigkeiten, Statistik und Mathematik sowie fachliche Domänenkenntnis zusammenkommen. Nehmen Sie Statistik und Mathematik weg, dann ist das keine Data Science mehr. Dann ist es Softwareentwicklung mit Daten.

Die Aufgabe eines Data Scientists besteht darin, aus chaotischer Realität eine belastbare Schlussfolgerung zu ziehen. Eine Frage sauber fassen. Daten holen. Bereinigen. Erkunden. Ein Modell anpassen. Mit den Resultaten ringen. Unsicherheit quantifizieren. Entscheiden, ob die Antwort tragfähig genug ist, um darauf zu handeln. Das Ergebnis ist meist eine Erkenntnis, eine Prognose, eine Empfehlung oder ein trainiertes Modellartefakt.

Die Aufgabe eines Softwareentwicklers besteht darin, ein System zu bauen und am Leben zu halten, das für reale Nutzer etwas Nützliches tut. Entscheiden, was das System tatsächlich leisten muss. Die Fachlichkeit modellieren. Grenzen entwerfen. Code schreiben. Mit Tests absichern. In CI/CD einhängen. Beobachtbar machen. Ausfälle abfangen. Absichern. Änderbar halten. Das Ergebnis ist ein Produkt oder eine Plattform, die den Kontakt mit Kunden, Prüfern, Regulatoren und dem Montagmorgen überlebt.

Beides ist technisch. Beides berührt Code. Die Form der Arbeit ist sehr verschieden.

Woher die Verwirrung kommt

2012 veröffentlichten Davenport und Patil in der Harvard Business Review Data Scientist: The Sexiest Job of the 21st Century. Ein Jahrzehnt später nahmen dieselben Autoren die Behauptung in Is Data Scientist Still the Sexiest Job of the 21st Century? noch einmal auf und räumten ein, dass sich die Rolle aufgefächert hat. Machine-Learning-Spezialisten, Data Engineers, MLOps-Spezialisten und Analytics Engineers haben still einen großen Teil dessen übernommen, was die ursprüngliche Schlagzeile in eine mythische Einzelperson gepackt hatte.

Genau diese Auffächerung ist das eigentliche Signal.

Der Boom um den “Data Scientist” kollidierte mit dem Boom um “KI” und erzeugte eine bequeme Management-Geschichte: Data Scientists einstellen, und KI passiert. In der Praxis passiert das selten, weil der größte Teil der Arbeit, die ein Modell in ein Produkt verwandelt, gar keine Data-Science-Arbeit ist. Es ist Softwareentwicklung, Infrastruktur, Sicherheit, Integration und Betrieb.

Das ist keine Meinung. Das ist gut dokumentiert.

Die 95 %, die nicht das Modell sind

Der klassische Verweis stammt hier von Google: D. Sculley et al., Hidden Technical Debt in Machine Learning Systems, NeurIPS 2015. Die zentrale Abbildung zeigt den ML-Code als winziges schwarzes Rechteck, umgeben von Konfiguration, Datenerfassung, Feature-Extraktion, Datenvalidierung, Ressourcenmanagement, Analysewerkzeugen, Prozessmanagement, Serving-Infrastruktur und Monitoring. Die Autoren nennen ML-Systeme “die hochverzinsliche Kreditkarte technischer Schulden” und warnen, dass sie alle üblichen Kosten komplexer Software plus einen Satz ML-spezifischer Kosten mitbringen.

Googles eigener Beitrag MLOps: Continuous delivery and automation pipelines in machine learning baut denselben Punkt aus: Ein trainiertes Modell ist noch kein Produkt. Ein Modell in Produktion zu bringen verlangt versionierte Daten, reproduzierbares Training, Continuous Integration, Continuous Delivery, Überwachung von Datendrift, Rollback-Pfade und klare Verantwortlichkeiten. Das alles sind Disziplinen der Softwareentwicklung.

Andrej Karpathy formulierte die kulturelle Variante des Arguments in Software 2.0. Sein Punkt war nicht, dass Programmierer verschwinden. Sein Punkt war, dass sich das geformte Artefakt ändert: Gewichte statt von Hand geschriebener Regeln. Der umgebende Stack aus Pipelines, Evaluation, Deployment und Tooling muss trotzdem von Menschen gebaut und gepflegt werden, die Software bauen und pflegen können.

Wenn Ihre KI-Investitionsthese davon ausgeht, dass ein paar PhDs eine echte Entwicklungskapazität ersetzen, dann argumentiert die Fachliteratur in diesem Bereich seit mehr als zehn Jahren das Gegenteil.

Worin Data Scientists exzellent sind

Das hier ist kein Verriss der Rolle. Gute Data Scientists sind außerordentlich wertvoll.

Ein starker Data Scientist erkennt, wenn eine Kennzahl aus der Zukunft in die Vergangenheit leckt. Er kann Ihnen sagen, dass Ihr A/B-Test zu wenig Aussagekraft hat und der angebliche Gewinn, den Sie gleich feiern wollen, nur Rauschen ist. Er kann zeigen, dass eine Kundensegmentierung über die Zeit instabil ist, und Sie davon abhalten, darauf eine Strategie aufzubauen. Er kann das passende Modell für die Frage auswählen statt des gerade modischen. Er kann quantifizieren, wie sicher Sie einer Prognose trauen sollten, was genau der Teil ist, den Führungskräfte am liebsten überspringen.

Das sind auch die Leute, die bemerken, wenn eine “erfolgreiche” KI-Demo nur auf einem kuratierten Ausschnitt der Daten funktioniert. Das ist eine Dienstleistung.

Wofür sie meist nicht optimiert sind, ist das Ausliefern. Zuverlässige Services mit versionierten APIs, Authentifizierung, Rate Limiting, Audit Trails, Deployment-Pipelines, Rufbereitschaften und sauberer Degradation zu bauen, ist nicht ihre Kernausbildung. Viele können dorthin wachsen. Viele wollen das nicht, und müssen es auch nicht.

Worin Softwareentwickler exzellent sind

Der Vorsprung eines Softwareentwicklers besteht darin, etwas in Produktion zum Laufen zu bringen, und zwar morgen wieder, unter Last, während Prüfer zusehen.

Dazu gehören die langweilig aussehenden Teile: Tests schreiben, die stille Regressionen verhindern, ein System in Module aufteilen, die sich unabhängig ändern lassen, entscheiden, wo die Daten liegen, festlegen, welche Aufrufe synchron sind und welche nicht, Drittanbieter-APIs integrieren, die über ihre Verfügbarkeit lügen, für Beobachtbarkeit so entwerfen, dass ein Vorfall um drei Uhr morgens debuggt werden kann, und die Codebasis so formen, dass die nächste Änderung nicht teurer wird als die letzte.

Speziell für KI sind Softwareentwickler diejenigen, die:

• Modelle hinter saubere, versionierte und authentifizierte APIs packen
• Daten sicher zwischen Systemen bewegen und ihre Herkunft respektieren
• Evaluations-Harnesses bauen, damit Sie überhaupt wissen, ob ein neues Modell besser ist
• Sicherheit, Rate Limiting und Kostenkontrollen für LLM-Aufrufe durchsetzen
• Retrieval-, Caching- und Fallback-Pfade entwerfen
• KI-Funktionen in bestehende Produkte integrieren, ohne sie zu beschädigen
• das Ganze innerhalb der Sicherheits- und Compliance-Lage des Unternehmens halten

Ohne diese Arbeit ist ein Modell eine Kuriosität. Mit ihr wird das Modell zu einer Funktion.

Eine persönliche Notiz zur Ehrlichkeit

Ich habe es in einem jüngsten Interview gesagt und wiederhole es hier. Ich bin derjenige, der das Tooling, die Pipelines, die Integrationen und die Produktionsoberfläche baut, über die die Arbeit eines Data Scientists überhaupt zu den Kunden gelangt. Mit mehr als vierzig Jahren in der Software verstehe ich die inneren Abläufe von LLMs und modernen KI-Systemen als Software: Tokens, Kontextfenster, Embeddings, Retrieval, Evaluation, Latenz, Kosten, Ausfallmuster, Deployment-Muster. Genau diesen Teil unterschätzen Führungskräfte laufend.

Wofür ich mich nicht ausgebe, ist ein Mathematiker. Tiefe Maßtheorie, fortgeschrittene statistische Inferenz oder der neueste Dreh in der Optimierungsforschung sind nicht mein Heimspiel. Wenn diese Tiefe zählt, wollen Sie einen echten Data Scientist oder angewandten Forscher. Wenn die Frage lautet, ob Ihr KI-System tatsächlich laufen, skalieren, integrieren, sicher bleiben und Sie nicht mit Inferenzkosten ruinieren wird, wollen Sie einen Entwickler, der seit Jahrzehnten Systeme ausliefert.

Zwei unterschiedliche Klingen. Ein Werkzeugkasten.

Was das für Ihre KI-Strategie bedeutet

Wenn Sie als CEO, CTO oder Investor einen KI-Plan bewerten, sparen ein paar praktische Prüffragen viel Geld.

1. Fragen Sie, wer das Modell in ein Produkt verwandelt.

   Wenn der Plan voller Data Scientists ist, aber kaum Entwickler, Plattformleute und SREs hat, wird das Modell Kunden nicht auf verlässliche Weise erreichen. Das erste MVP vielleicht. Das zweite Release wird wehtun.

2. Fragen Sie, wo die Entwicklungsdisziplin verankert ist.

   Versionsverwaltung, Code-Review, automatisierte Tests, CI/CD, Beobachtbarkeit, Sicherheitsprüfung, Incident Response. Wenn keines dieser Worte im KI-Plan auftaucht, haben Sie keinen KI-Plan. Sie haben ein Experiment mit Marketingbudget.

3. Fragen Sie, wie das Team Modelle in Produktion bewertet.

   Offline-Genauigkeit auf einem statischen Datensatz ist keine Evaluation. Sie wollen kontinuierliche Evaluation, Drift-Überwachung und eine klare Antwort auf die Frage: "Woran merken wir diese Woche, dass das schlechter geworden ist?" Das ist Softwarearbeit, kein Notebook.

4. Fragen Sie nach Kosten und Ausfallmustern.

   LLM-Funktionen können unbemerkt Inferenzbudgets verbrennen, Daten leaken oder auf eine Weise scheitern, die wie Erfolg aussieht. Entwickler, die die Laufzeit verstehen, bauen die Leitplanken darum.

5. Entlassen Sie nicht die Entwickler, die Ihr Produkt gebaut haben.

   Der schnellste Weg, eine KI-Initiative scheitern zu lassen, ist, die bestehende Entwicklungskapazität als Legacy-Kopfzahl zu behandeln und gleichzeitig Geld in ein paralleles "KI-Team" zu kippen, das nichts ausliefern kann. Die Teams, die gewinnen, kombinieren tiefes Domänenwissen im Code mit neuer KI-Fähigkeit im selben System, nicht daneben.

Der nützliche Rahmen

Data Scientist und Softwareentwickler sind keine Synonyme. Sie ergänzen einander.

Sie brauchen Data Scientists, um scharfe Fragen zu stellen und die Organisation ehrlich darüber zu halten, was die Daten tatsächlich hergeben. Sie brauchen Softwareentwickler, um die Systeme zu bauen und zu betreiben, die diese Antworten in Produkte verwandeln, die Kunden jeden Tag benutzen.

Wenn Ihre KI-Strategie nur das eine ohne das andere hat, ist sie keine Strategie. Sie ist eine Wette darauf, dass die fehlende Hälfte von allein auftaucht.

Wird sie nicht.