Wie Entwickler ihren Job sichern können (1)
Unternehmen meinen, es werden weniger Entwickler gebraucht, weil KI die Fleißarbeit erledigt. Das ist zu kurz gedacht, meint Matthias Bohlen. Wir sollten genauer hinschauen.
Die Wette, die Unternehmen gerade eingehen
Unternehmen sind zu dem Schluss gekommen, dass Coding-Agenten die Fleißarbeit erledigen und deshalb weniger Entwickler gebraucht werden. Die Kürzungen treffen vor allem Berufseinsteiger:
Eine Stanford-Studie kommt zum Ergebnis, dass junge Leute in KI-exponierten Berufen besonders betroffen sind, während das bei erfahrenen Leuten nicht erkennbar ist:
We find no evidence of widespread, economy-wide job displacement. However, employment of young workers (ages 22–25) in AI-exposed occupations now stands 19% below where it would be had it kept pace with that of their less-exposed peers; experienced workers show no comparable gap.
Eine Harvard-Studie über 65 Millionen Beschäftigte argumentiert in die gleiche Richtung: Die Zahl der Einstellungen von Junior-Beschäftigten (nicht nur Entwickler übrigens!) sank innerhalb von sechs Quartalen nach der KI-Einführung um 9 bis 10%, während die der Seniors stabil blieb.
(Es gibt sehr bekannte Artikel im Netz, die sogar von 67% Einbruch berichten, doch dabei scheint es sich um eine nicht belegbare Zahl zu handeln, weshalb ich diese Artikel hier nicht zitiere).
Aus meiner Sicht steckt hinter dem Verhalten der Unternehmen ein Fehlschluss: Woher sollen die zukünftigen Senioren kommen, wenn man keine Junioren mehr einstellt und ihnen die Erfahrung beibringt?
Was Vibe Coding produziert
Weniger erfahrene Entwickler liefern heute funktionierende Software aus, ohne sie zu verstehen. Der Code läuft, und genau deshalb bleibt das Problem unsichtbar. Eine Analyse von GitClear über 623 Millionen Code-Änderungen zeigt: Gegenüber der Zeit vor KI ist die Code-Duplizierung um 81% gestiegen und die Wiederverwendung um 70% gesunken.
Nach meiner Erfahrung ist Code-Duplizierung bei weitem nicht das einzige Problem. Wenn ich Claude Code z.B. sage, dass ich gern eine Webanwendung auf Basis von bun hätte und ein paar User Stories dazu beschreibe, generiert Claude mir daraus tatsächlich etwas, das tut was ich will.
Doch wenn ich in den Code schaue, ist fachlicher Code wild mit Datenbankzugriffen gemischt, was später die Wartungsaufwände hochtreibt.
Dann kommt der eigentliche Witz: Wenn ich Claude Code nun frage, ob es das so in Ordnung findet, sagt es "auf keinen Fall, wir sollten Technik und Fachlogik trennen" und refaktorisiert entsprechend.
Das Ergebnis: Wenn ich die Frage nicht gestellt hätte, wäre dieser Code einfach in Produktion gegangen. Architektur-unerfahrene Leute werden also mit KI-Agenten schlechten Code erzeugen ohne es zu merken.
Zwei Arten von Schulden, nicht eine
Technische Schulden stecken im Code, Verständnisschulden stecken im Team: die Lücke zwischen der Menge an vorhandenem Code und dem, was irgendjemand davon wirklich versteht. Die zweite Art ist gefährlicher, weil kein Dashboard sie misst.
"Comprehension Debt" ist ein Begriff von Addy Osmani (ehemals Director, Google Cloud AI - Gemini, Vertex, Agents). In seinem Artikel beschreibt Osmani, was passiert, wenn immer mehr Code im System existiert, aber der Anteil davon, den noch irgendein Mensch wirklich kapiert, nicht mehr mithalten kann.
Addy Osmani
Eine Studie von Anthropic ergab, dass Entwickler, die an die KI delegierten, während sie Coding erlernten, in Verständnistests deutlich schlechter abschnitten. Das würde bedeuten, dass Junioren besser ein paar harte Probleme von Hand knacken sollten, weil sie dann schneller lernen würden. Entwickler, die die KI als Sparringspartner und Erklärungs-Tool nutzten, zeigten bessere Ergebnisse als eine Gruppe, die die Arbeit komplett an die KI delegierte. Es spielt also eine Rolle, wie man mit der KI umgeht, nicht nur ob man es tut.
Anthropic
Der Tag, an dem es schief gehen wird
Gerade bei neu geschriebenen, eher kleinen Anwendungen, tut Vibe Coding ohne tieferes Verständnis überhaupt nicht weh. Man kann einem Junior das folgende Rezept geben, und er/sie wird damit ziemlich weit kommen:
- Sag dem Coding-Agenten, was gefordert ist
- Lass ihn den Code erzeugen bis alle Tests wieder grün sind
- Sag ihm dann, er soll ein ausführliches Review dessen machen, was er gerade erzeugt hat
- Wenn Fehler oder Nachteile gefunden wurden, soll der Agent sie beheben
- Wiederhole Schritte 3 und 4, bis beim Review nur noch Fehler gefunden werden, die als "minor" eingestuft werden.
- Mach ein Pull-Request aus den Änderungen und gib es jemand anderem.
Das geht so lange gut bis die erste Anforderung eintrifft, die der bestehenden Architektur widerspricht. In diesem Moment muss eben doch jemand das gesamte System verstehen, um zu entscheiden, was zu tun ist. Diese Person steht dann möglicherweise nicht mehr auf der Gehaltsliste, denn es handelte sich um jemanden mit Erfahrung, der/die inzwischen den nächsten Karriereschritt genommen hat.
Was macht so ein Unternehmen jetzt? Es wird einfach irgend jemanden die notwendigen Entscheidungen treffen lassen, und der Architekturverfall beginnt.
Der Einwand, den ich nicht abtun konnte
Als ich nach Leuten suchte, die diese Sorge teilen, fand ich viele, auch sehr bekannte Leute, z.B. Mark Russinovich, Microsofts CTO, Deputy CISO und Technical Fellow, Microsoft Azure, und Scott Hanselman, VP und Member of Technical Staff bei Microsoft/GitHub.
In ihrem Artikel für Communications of the ACM argumentieren sie, dass generative KI Risse in die Wirtschaftlichkeit von Softwareentwicklung gebracht hätte, und zwar auf eine Art und Weise, die die Industrie noch nicht in Gänze wahrnimmt.
Ich fand aber auch ernstzunehmende Ingenieure, die sagen, das ganze Problem werde sich von selbst lösen, und deren Argumente sind tatsächlich besser, als ich erwartet hatte. In der nächsten Folge dieser Serie liest Du, warum sie recht haben könnten. Bleib dran.
Wie ist Deine Meinung zu dieser Problematik? Drücke unten auf die Kommentar-Taste, um mitzudiskutieren.