Die Leistungsfähigkeit von Sprachmodellen wie ChatGPT ist beeindruckend. Auf Kommando erzeugen sie Source-Code in beliebigen Programmiersprachen, generieren Dokumentation aus bestehendem Code und finden Fehler in vorhandenen Methoden. Da stellt sich die Frage, ob Sprachmodelle nur nützliche Werkzeuge für Software-Entwickler sind oder ob Sprachmodelle nicht auch Software-Entwickler ersetzen können.
Für die Berufsaussichten von Entwicklern könnten Sprachmodelle dann zur Gefahr werden, wenn sie in der Lage sind, Programme in größerem Rahmen zu erstellen, also über einzelne Methoden und Algorithmen hinaus. Um das besser abschätzen zu können, möchte ich zwei unterschiedliche Fälle unterscheiden.
Die grüne Wiese
Bei der Neuentwicklung eines Software-Systems existiert kein Programmcode als Kontext. Zu den ersten Entscheidungen, die Entwickler treffen, gehört die Auswahl der zu verwendenden Technologien und Produkte. Auf dieser Grundlage muss zunächst das Grundgerüst der Anwendung aufgebaut und die gewählten Produkte miteinander integriert werden.
Für ein gut trainiertes Sprachmodell sehe ich keine grundsätzlichen Schwierigkeiten, auf der Grundlage von nicht-funktionalen Anforderungen ein solches Programmgerüst zu generieren. Für einen guten Entwickler ist das aber auch nicht die größte Herausforderung. Wichtiger und schwieriger ist es, die funktionalen Anforderungen zu verstehen und in ein gutes Domänenmodell zu übertragen.
Mit einem perfekt ausgearbeiteten, detaillierten Fachkonzept als Kontext könnte ein Sprachmodell ein passendes Domänenmodell als Source-Code erzeugen. Das eigentliche Problem liegt zu Beginn eines neuen Projekts aber darin, vage und unvollständig formulierte Anforderungen zu hinterfragen und sinnvoll zu ergänzen.
Eine der großen Errungenschaften der agilen Software-Entwicklung war die Erkenntnis, dass das Wasserfall-Modell nicht funktioniert. Ein schrittweises Vorgehen und Verstehen führt besser und schneller zum Erfolg. Diese Arbeit – vor allem das gezielte Nachfragen und Ausarbeiten des Kontextes – kann ein Sprachmodell (derzeit!) nicht abnehmen.
Die Arbeit eines Software-Entwicklers verlagert sich in diesem Fall hin zum fachlichen und technischen Analysieren. Das Programmieren wird weniger wichtig werden – wichtiger hingegen wird es, ein Sprachmodell mit einem geeigneten Kontext zu versorgen, sodass es den gewünschten Code erzeugt.
Jede grüne Wiese ist irgendwann bebaut – damit kommen wir zum zweiten Fall.
Das vorhandene System
Die allermeiste Entwicklungsarbeit wird nicht in die Entwicklung neuer Systeme, sondern in die Wartung und den Aus- und Umbau von bestehenden Systemen investiert. Aus wirtschaftlichen Gesichtspunkten ist der Einsatz von Sprachmodellen hier deutlich lohnenswerter und somit die Gefahr für Entwickler, ersetzt zu werden, deutlich größer. Hier stoßen die aktuellen Sprachmodelle aber schnell an eine Grenze, die sich durch ihre Konstruktion ergibt.
Um ein Sprachmodell zu trainieren, wird eine große Menge an Source-Code benötigt. Das fertig trainierte Sprachmodell kann im Idealfall zu allen möglichen allgemeinen Fragen sinnvollen Code erzeugen. Die Fragen sind der Kontext, innerhalb dessen die Antworten generiert werden. Während der Trainingskorpus eines Sprachmodells sehr groß sein muss, ist der Kontext einer Frage sehr beschränkt. Je größer der Kontext ist, desto aufwändiger (d.h. ressourcenintensiver und langsamer) wird es, eine passende Antwort zu erzeugen. Daher sind heutige Sprachmodelle auf einige Tausend Wörter / Tokens beschränkt.
Praktisch jedes existierende Software-System ist jedoch größer als der Kontext eines Sprachmodells. Zum Hinzufügen einer neuen Methode in eine bestehende Klasse reicht es aus, diese Klasse als Kontext zu verwenden. Bei der Weiterentwicklung eines Systems sind solche lokalen Änderungen selten ausreichend. Vielmehr müssen Anpassungen oft an vielen Stellen des Systems durchgeführt werden. Und eine der ersten Aufgaben für einen Entwickler ist es, herauszufinden, welche Stellen das sind.
Ein allgemein zugängliches Sprachmodell ist nicht mit dem speziellen Source-Code einer Anwendung vertraut und als Kontext kann der Source-Code nicht verwendet werden, da er zu umfangreich ist. Für die Zukunft zeichnen sich daher zwei Wege auf: Sprachmodelle müssen größere Kontexte akzeptieren oder sie müssen mit dem vorhandenen Source-Code trainiert werden.
Beide Wege sind vorstellbar, aber nicht umsonst zu erhalten. Ein erheblich größerer Kontext führt zu größerem Ressourcenverbrauch, d.h. größeren Kosten für die Generierung. Und das Training eines Sprachmodells mit dem Source-Code einer vorhandenen Anwendung führt zu einer Reihe von Fragen, die zunächst geklärt werden müssen: Welches Sprachmodell lässt sich durch weiteres Training an ein bestehendes System anpassen? Wo geschieht dieses Training, damit der Source-Code des Systems nicht die Organisation verlässt? Wie wird dann das angepasste Sprachmodell lokal betrieben, ebenfalls, damit das Wissen über die Anwendung nicht die Organisation verlässt?
Mein Fazit
Sprachmodelle haben ein großes Potenzial darin, Software-Entwicklung zu vereinfachen und zu beschleunigen. Das kann dazu führen, dass für die gleiche Entwicklungsarbeit weniger Entwickler benötigt werden.
Andererseits sind Sprachmodelle noch darin begrenzt, keine Rückfragen stellen zu können, um unklare Anforderungen zu präzisieren. Und allgemein verfügbare Sprachmodelle sind nicht mit dem Code vorhandener Software-Systemen trainiert. Sie können somit keine Änderungen sinnvoll durchführen, die die maximale Größe ihres Kontextes überschreiten.
Inwieweit diese Beschränkungen in den nächsten Jahren (oder Monaten) fallen, wird die Zukunft zeigen.