Kris van Rens wirft einen Blick auf die Zukunft der Systementwicklung und darauf, dass die Zufriedenheit der Entwickler ein wichtiger Aspekt der Softwareentwicklung ist
Künstliche Intelligenz im Allgemeinen und große Sprachmodelle (LLMs) im Besonderen verändern unbestreitbar die Art und Weise, wie wir arbeiten und Code schreiben. Insbesondere beim Lernen, Erklären, Refactoring, Dokumentieren und Überprüfen von Code erweisen sie sich als äußerst nützlich.
Für mich ist die Generierung von produktionsreifem Code mit einem LLM im Chat-Stil jedoch immer noch eine gemischte Sache. Die sorgfältig ausgearbeitete Eingabeaufforderung für eine komplexe, eingeschränkte Aufgabe übersteigt den resultierenden Code oft um Größenordnungen, so dass ich die Produktivitätsgewinne in Frage stelle. Manchmal ertappe ich mich dabei, wie ich die Eingabeaufforderung iterativ bekämpfe, um den richtigen Code für mich zu generieren, nur um dann festzustellen, dass sie zufällig vergessen hat, eine meiner früheren Anforderungen zu implementieren. Manchmal erzeugen die LLMs auch Code mit ungültigen Konstrukten: Sie halluzinieren Antworten, und das immer mit großer Sicherheit. Hinzu kommt, dass die LLMs so arbeiten, dass die Antworten jedes Mal, wenn Sie eine ähnliche Abfrage eingeben, völlig anders ausfallen können oder zumindest stark von der jeweiligen Eingabeaufforderung abhängen.
OpenAI-Mitbegründer Andrej Karpathy hat es gut ausgedrückt: „In gewisser Weise ist alles, was LLMs tun, Halluzinationen. Sie sind Traummaschinen.“ Dieses scheinbar ’schwarzmagische‘ Verhalten von LLMs ist mit meinem inneren technikgetriebenen Drang, einem deterministischen Prozess zu folgen, nicht ganz vereinbar. Vielleicht liegt es an meiner völligen Inkompetenz in Sachen Sofortengineering, aber aus meiner Sicht müssen wir trotz der Macht der generativen KI, die uns zur Verfügung steht, immer noch absolut verstehen, was wir tun, anstatt blind auf die Korrektheit des Codes zu vertrauen, der von diesen Traummaschinen erzeugt wurde. Das seltsame Gefühl und die Idiosynkrasie von LLMs werden in Zukunft wahrscheinlich nachlassen, aber ich möchte den Code, den ich produziere und für den ich verantwortlich bin, immer noch wirklich verstehen.
Wahrscheinlich wird die KI in der zukünftigen Softwareentwicklung eine Abstraktionsverschiebung ermöglichen, die es uns erlaubt, auf einer höheren Abstraktionsebene zu entwerfen, als wir es heute oft tun. Das wiederum könnte dazu führen, dass wir weniger Code von Hand schreiben müssen. Ich kann jedoch nicht erkennen, wie die Verwendung von generiertem Code in der Produktion ohne die Korrektheitsgarantien strenger Tests und formaler Verifizierung gut funktionieren soll – das ist heute nicht die Realität.
''An aspect of software engineering where LLMs can make an overall positive difference is interpreting compiler feedback.''
Positiver Unterschied
Ein weiterer Anwendungsbereich von LLMs ist die Inline-Code-Vervollständigung in einem Editor/IDE. Selbst das ist für mich kein durchschlagender Erfolg. Mehr als einmal war ich davon überwältigt, dass die LLM-basierte Code-Vervollständigung eine mehrzeilige Lösung für das vorschlägt, was sie glaubt, dass ich eingeben wollte. Anstatt die Code-Idee direkt aus meiner Vorstellung zu implementieren, muss ich dann einen Klecks generierten Vorschlagscode lesen und mich fragen, was er tut und warum. Diese Vervollständigungen sind nicht einfach und bringen mich oft auf die schiefe Bahn. Ich habe in letzter Zeit mit der Embedded-Entwicklung für Mikrocontroller-Einheiten experimentiert und festgestellt, dass die LLM-basierte Vervollständigung vor allem bei Code in diesem Kontext nur Vermutungen anstellt und manchmal sogar nicht existierende GPIO-Pin-Nummern (General Purpose IO) erfindet, während sie arbeitet. Mir gefällt die Kombination von LLMs zur Codevervollständigung mit einem KI-Modell, das die Bewegungen des Editors beim Refactoring vorhersagt. Refactors sind oft Stapel von ähnlichen kleinen Operationen, die die Modelle gut vorhersagen können.
Ein Aspekt der Softwareentwicklung, bei dem LLMs einen positiven Beitrag leisten können, ist die Interpretation von Compiler-Feedback. C++ zum Beispiel ist berüchtigt für seine schwer lesbaren und oft sehr langen Compilerfehler. Die Einführung von Konzepten in C++20 sollte hier eine drastische Verbesserung bewirken, aber ich habe es nicht erlebt. Vielleicht ist das noch nicht ganz ausgereift, aber bis dahin sind wir gezwungen, uns mit komplexen und oft langen Fehlermeldungen (manchmal sogar Hunderte von Zeilen lang) zu beschäftigen. Aufgrund ihrer Fähigkeit, Compiler-Meldungen zu interpretieren oder zusammenzufassen, in Kombination mit ihren lehrreichen und generativen Funktionen, sind LLMs mit einem großen Kontextfenster geeignet, solche Rückmeldungen zu verarbeiten, was sie zu einem großartigen Begleitwerkzeug für C++-Entwickler macht. Es gibt einen enormen Bestand an bereits existierendem C++-Code und Dokumentation, aus dem man lernen kann, was eine gute Grundlage für das Training eines LLM ist.
Weitere Nachteile von C++ sind die ständig wachsende Komplexität der Sprache und die Tendenz des Compilers, Sie eher zu bekämpfen als Ihnen zu helfen. Ein effektiver Einsatz von LLMs zur Bekämpfung dieser Probleme könnte die Sprache kurzfristig retten. Die Entwicklung der C++-Sprache ist langsam, aber das Potenzial der Werkzeuge ist enorm. Angesichts der schieren Menge an bestehendem C++-Code, der heute verwendet wird, wird die Sprache auf Dauer Bestand haben, und jedes Tool, das Entwicklern bei der Arbeit mit ihr hilft, ist willkommen.
''To me, writing code is a highly creative, educational and enjoyable activity.''
Glück der Entwickler
Die Verwendung von LLMs zur Codegenerierung nimmt mir auch einen Teil der Freude am Programmieren. Für mich ist das Schreiben von Code eine höchst kreative, lehrreiche und unterhaltsame Tätigkeit, bei der ich meine Fähigkeiten verfeinern kann. Wenn ich die Arbeit von einer magischen Box erledigen lasse, wird diese Erfahrung bis zu einem gewissen Grad zunichte gemacht – selbst das manuelle Schreiben der langweiligen Teile und der Tests hat einen gewissen Bildungswert.
Ger Cloudt, ein Kollege aus dem Bereich der Softwareentwicklung, behauptet in seinem Werk über Softwarequalität, dass die organisatorische Qualität, zu der auch die Zufriedenheit der Entwickler gehört, nur die halbe Wahrheit ist. Ihm zufolge ist die organisatorische Qualität der Schlüssel, da sie die Qualität von Design, Code und Produkt ermöglicht. Sicherlich sind ein sauberer Code und eine saubere Architektur wichtig, aber ohne die richtigen Tools, die richtige Einstellung, die richtige Kultur, die richtige Ausbildung usw. wird der Entwicklungsprozess irgendwann zum Stillstand kommen.
LLMs helfen zweifellos bei den Werkzeugen und der Ausbildung, aber es gehört mehr zum Programmieren, als nur Code wie ein Roboter zu produzieren. Ein Teil des Handwerks der Softwareentwicklung ist – wie bei jedem Handwerk – die Freude und der Stolz auf Ihre Arbeit und die Ergebnisse, die Sie produzieren. Halten Sie mich für verrückt, aber ich empfinde eine große Befriedigung, wenn ich mit meinen eigenen Händen schön aussehenden Code erstellen kann.
