Dass sich die Softwareentwicklung durch KI verändert, habe ich Anfang September schon beschrieben. Die Frage, die danach oft kommt, ist eine andere: Werden wir alle ersetzt?

Meine kurze Antwort: Das vermischt zwei Dinge. Die eine Achse ist Fähigkeit — wo ein System zuverlässig scheitert, und warum? Die andere ist Arbeit — was passiert mit Stellen und Rollen, wenn es innerhalb eines begrenzten Bereichs oft genug klappt? Ein unsicheres Assistenzsystem kann trotzdem Stunden ersetzen. Ein beeindruckender Demo-Agent kann trotzdem neue Aufgaben schaffen. Der IMF spricht von hoher Exposure — rund 40 Prozent der globalen Beschäftigung, rund 60 Prozent in fortgeschrittenen Volkswirtschaften — und betont zugleich: Exposure ist keine beobachtete Massenarbeitslosigkeit.

Im privaten Bereich bin ich von Java auf Go gewechselt. Auslöser ist, dass die Arbeit mit KI die Softwareentwicklung auf den Kopf gestellt hat. Was früher Nachschlagen, Boilerplate und viel Tippen war, erledigt ein Assistent heute in kurzer Zeit. Übrig bleibt die Frage, ob man das Ergebnis versteht, prüfen kann und später noch ändert.

Dass sich der Alltag dadurch verändert, habe ich Anfang September schon beschrieben. Hier geht es um die Folge für die Wahl der Sprache im Backend: Go auf der einen Seite, Java mit Spring Boot oder Quarkus auf der anderen. Die Punkte habe ich für mich neu geordnet. Es sind Überlegungen aus der eigenen Arbeit, keine Messreihe.

Auf dev.neitzel.de habe ich beschrieben, was Large Language Models sind und wie sie arbeiten. Das bleibt Theorie, solange man die Maschine nicht selbst laufen sieht. Deshalb habe ich dieselbe Arbeitsweise in einem kleinen Go-Projekt umgesetzt: MinimalesLLM.

MinimalesLLM ist ein winziges neuronales Netz. Es trainiert auf einer normalen CPU, ohne Grafikkarte und ohne großes Rechenzentrum. Die Texte sind keine Sätze und keine Dialoge, sondern einzelne kurze Wörter, Vornamen, Buchstabe für Buchstabe. Das Netz lernt, welches Zeichen als Nächstes wahrscheinlich folgt, hängt dieses Zeichen an und macht weiter, bis das Wort zu Ende ist. Wer einen Anfang vorgibt, bekommt eine Fortsetzung. Ohne Anfang zieht das Programm selbst ein neues kurzes Wort.

Die Softwareentwicklung hat sich in den letzten Monaten spürbar verändert. Nicht nur ein bisschen an der Oberfläche, sondern im Alltag: Was früher Nachschlagen, Boilerplate, erste Entwürfe und viel Tipparbeit war, übernehmen heute oft moderne Werkzeuge – vor allem Large Language Models und die Assistenten, die darauf aufbauen.

Damit verändert sich auch das Berufsbild. Wer Software baut, muss weiterhin verstehen, was entstehen soll, welche Architektur trägt und ob das Ergebnis stimmt. Aber immer mehr der konkreten Arbeit dazwischen wird direkt von Tools erledigt. Syntax, typische API-Aufrufe, Testskelette, Umformulieren, Erklären von fremdem Code: Das ist nicht mehr der Engpass, der es früher war.

MVVM ist aus meiner Sicht für Desktop Anwendungen mit die beste Lösung, da die UI deklarativ erstellt wird und damit gut vom Model getrennt ist. Hier war in der Vergangenheit die Library mvmFX eine sehr gute Unterstützung, jedoch hat diese zuletzt vor einigen Jahren ein Update bekommen, so dass eine produktive Nutzung eher problematisch ist.

Daher macht es Sinn, einfach einmal zu schauen, wie eine MVVM Anwendung prinzipiell aufgebaut ist und wie man hier ggf. mit ein paar wenigen Klassen eine deutliche Vereinfachung herbeiführen kann.