Wie Entwickler ihren Job sichern können (2)
Bekannte Persönlichkeiten aus der Softwarebranche haben die Warnung vor der versiegenden Nachwuchs-Pipeline zum Mainstream gemacht. Zustimmung ist bequem. Deshalb nimmt die zweite Folge der Serie stattdessen die Gegenseite ernst.
Hier sind Links auf die Posts dieser Blog-Reihe:
- Folge 1: Worauf Unternehmen mit KI wetten
- Folge 2: Was die Optimisten sagen und was ich davon halte
- Folge 3: Meine Empfehlungen für Dich als Entwickler:in, und für Sie als Führungskraft
Offenbar bin ich nicht der Einzige, der das Problem sieht: Der Coding-Muskel der Menschen wird nachlassen, je weniger er benutzt wird. Die "HR-Pipeline" wird aus Junioren keine Senioren mehr machen, wenn die Unternehmen mit der Idee weitermachen, keine Junioren mehr einzustellen.
Matthias Bohlen
Schon vor zwei Jahren hat Charity Majors, Cofounderin und CTO von honeycomb.io, in ihrem Essay im Stackoverflow-Blog auf dieselbe Falle hingewiesen. Ich könnte mich also einfach im Recht fühlen und es genießen, oder? Doch das wäre zu einfach.
Charity Majors
Das Argument der Optimisten
Simon Willison argumentiert, schlechteren Code mit Agenten auszuliefern sei eine Entscheidung, und Refactoring sei eine ideale Aufgabe für Agenten.
Simon WillisonSimon ist nicht gerade irgendwer: Er ist Mitentwickler des Web-Frameworks Django. Von ihm stammt z.B. auch der Begriff Prompt Injection. Er ist ein Befürworter von agentischem Coding, aber mit kritischem Blick.
Simon unterscheidet (wie ich) scharf zwischen zwei Dingen: Vibe Coding, bei dem man den Code nicht mehr prüft, und verantwortungsvoller KI-gestützter Entwicklung. (Leider benutzen viele Leute inzwischen den Namen "Vibe Coding" auch für das letztere, was den Begriff verwässert.)
Charlie Graham hat als Gründer sogar noch mehr Optimismus und geht noch weiter: Schulden, die das heutige Modell übersieht, findet das nächste, sie bestehen also nur ein paar Monate.
Charlie Graham
Früher waren technische Schulden etwas, das akkumulierte und schnell die Refactoring-Kapazität der Menschen überstieg. Simon und Charles sagen, dass dies mit KI anders geworden ist. Wenn die beiden recht haben, kommt die Krise, die ich prophezeie, also einfach nicht. 🤔
Bis wohin die Optimisten recht haben
Duplizierung, zu lange Funktionen, fehlende Tests und uneinheitliche Benennung sind lokale Probleme. Modelle können sie schon heute gut beheben und werden darin besser. Diesen Punkt gebe ich ab: Meine ursprüngliche Hypothese war zu breit gefasst.
Modelle sind gut in Aufgaben wie diesen:
1. Duplizierten Code zusammenführen. Ein Modell erkennt, dass dieselbe Validierungslogik in fünf Controllern leicht abgewandelt vorkommt, und zieht sie in eine gemeinsame Funktion. Die Änderung lässt sich Datei für Datei prüfen, weil das Verhalten gleich bleiben soll und vorhandene Tests das belegen.
2. Überlange Funktionen zerlegen. Eine Methode mit 300 Zeilen wird in benannte Teilschritte aufgeteilt, etwa Eingabe prüfen, berechnen und speichern. Dafür muss das Modell nur diese eine Funktion und ihre direkten Aufrufer verstehen, nicht das ganze System.
3. Fehlende Tests nachziehen. Für eine bestehende Funktion schreibt ein Modell Unit-Tests, die den Normalfall, Randwerte und Fehlerfälle abdecken. Das gelingt gut, weil sich das erwartete Verhalten aus dem Code selbst ablesen lässt und der Testlauf sofort zeigt, ob die Tests stimmen.
4. Benennung und Stil vereinheitlichen. Wenn dieselbe Sache im Code mal „customer”, mal „client” und mal „user” heißt, benennt ein Modell sie im gesamten Projekt konsistent um. Das ist mühsame Fleißarbeit über viele Dateien, verlangt aber keine Entwurfsentscheidung und fällt bei Fehlern sofort im Compiler oder Linter auf.
Allen vier Beispielen ist gemeinsam, dass die nötige Information im Code steht und sich das Ergebnis automatisch prüfen lässt.
Meine Argumentation geht mehr in Richtung Architektur, also Strukturen, die fundamental sind und viel Erfahrung, Überblick und Urteilskraft, ja teilweise sogar Geschmack benötigen. Das lässt sich nicht aus einer lokalen Codestelle ermitteln.
Charlie Graham gibt zu, dass die meisten technischen Schulden keine Architekturfragen sind:
But most technical debt is not architecture. It is imperfect implementation around an unproven idea. The slightly wrong abstraction. The feature built before anyone knew if users wanted it. The elegant system designed for a scale that never arrived.
Doch er geht davon aus, dass Modelle auch dies bereits in 2027 lösen könnten.
Ich bin nicht seiner Meinung. Eine kaputte Architektur ist keine unordentliche Datei, sondern eine falsche Entscheidung. Die Informationen, die man zu ihrer Korrektur braucht (kommende Anforderungen, echte Randbedingungen, Entwurfs- und Evolutionsprinzipien), stehen einfach nicht im Code. Es braucht also eine Mitteilung vom erfahrenen Menschen an die KI, sonst kann sie es nicht wissen.
Meine Hypothese, jetzt überarbeitet
Die Optimisten haben mich gezwungen, meine Hypothese zu schärfen, und dafür bin ich ihnen dankbar. In einem Punkt haben sie recht: Doppelten Code, überlange Funktionen und fehlende Tests räumen die Modelle schon heute auf, und sie werden darin besser. Wer an dieser Stelle die große Krise erwartet, wird vergeblich warten.
Meine Hypothese lautet deshalb jetzt: Bessere Modelle werden die lokale Unordnung beseitigen. Sie werden aber vorerst nicht entscheiden, was aus dem System werden soll. Der Grund ist fehlende Information. Welche Anforderungen im nächsten Jahr kommen, welche Randbedingungen echt sind und welche nur historisch gewachsen, was das Geschäft während eines Umbaus verkraftet, usw.: Nichts davon steht im Code.
Für diese Entscheidung braucht es jemanden mit Urteilsvermögen, der die Architektur versteht und die Werkzeuge beherrscht. Das Modell führt den Umbau aus. Wohin umgebaut wird, muss ein Mensch verantworten.
Das schrumpfende Angebot
Wenn das stimmt, sind die wertvollsten Ingenieure des nächsten Jahrzehnts genau die, deren Ausbildung die Unternehmen gerade eingestellt haben. In der nächsten Folge: wer gewinnt, wo ich falsch liegen könnte und worauf Entwickler und Unternehmen achten sollten.
Wie ist Deine Meinung zu dieser Problematik? Drücke unten auf die Kommentar-Taste, um mitzudiskutieren.