Monat: Februar 2025

Die ASML-Ingenieurin Buket Şahin ist die erste Person, die das ECP2 Silber-Zertifikat erhalten hat. Für Şahin ist das nur der Nebeneffekt ihrer Leidenschaft für das Lernen. Sie liebt es, sich in neue Bereiche einzuarbeiten, und ist dadurch eine bessere Systemingenieurin geworden.

Als Buket Şahin ihren Bachelor-Abschluss in Maschinenbau in Istanbul machte, schloss sie sich den Solarauto- und Formel-SAE-Teams ihrer Universität an. Eine Entscheidung, die ihr schnell die Grenzen ihres Wissens vor Augen führte. Das brachte sie auf den Weg, sich ein Leben lang mit anderen Bereichen als ihrem eigenen zu beschäftigen.

„Da hat alles angefangen“, erinnert sich Şahin. „Ich sah, wie notwendig es war, andere Disziplinen kennenzulernen. Natürlich kannte ich mich im mechanischen Bereich gut aus, aber plötzlich musste ich zum Beispiel mit Elektroingenieuren zusammenarbeiten. Ich konnte nicht verstehen, wovon sie sprachen, und ich wollte es wirklich.“

Şahin schloss schließlich einen Bachelor in Maschinenbau und einen Master in Mechatronik ab und absolvierte außerdem einen MBA. Sie arbeitete zunächst als Systemingenieurin in der türkischen Verteidigungsindustrie, bevor sie 2012 zu ASML wechselte. Sie arbeitete zunächst in der Entwicklung und Konstruktion der NXT- und NXE-Plattformen. Derzeit arbeitet sie als Systemingenieurin für Produktsicherheit an den EUV-Maschinen von ASML.

Während dieser Reise suchte sie beharrlich nach neuem Wissen und belegte eine Reihe von Kursen in Bereichen wie Elektronik, Optik und Mechatronik. Ende 2024 war sie diejenige, die das erste ECP2 Silber-Zertifikat erhielt. ECP2 ist das europäisch zertifizierte Kursprogramm für Feinmechanik, das aus einer Zusammenarbeit zwischen euspen und DSPE hervorgegangen ist. Um das Zertifikat zu erhalten, musste sie 35 Punkte an ECP2-zertifizierten Kursen absolvieren.

„Mein Ziel war es nicht, diese Zertifizierung zu erreichen“, lacht sie. „Aber am Ende war ich die erste, die sie erhalten hat.“

Blick aus dem Hubschrauber

Şahins Position bei ASML kombiniert Systemtechnik mit einem Blick auf die Sicherheit. „Wir sind für die gesamte EUV-Maschine unter dem Gesichtspunkt der Sicherheit verantwortlich“, erklärt sie. „Dazu gehören die interne und externe Abstimmung, die Überwachung des Programms und die Verwaltung der Ingenieure und Architekten.“

Das Team, in dem sie arbeitet, umfasst bis zu Hunderte von Mitarbeitern, darunter ein Kernteam von etwa fünfzehn Systemingenieuren. Einer davon ist ein sicherheitsspezifischer Systemingenieur, wie sie es ist.

Es gefällt ihr, eine breitere, systemische Perspektive einzunehmen, die verschiedene Bereiche miteinander verbindet. Es ermöglicht ihr, die verschiedenen Dinge, die sie im Laufe ihrer Karriere gelernt hat, in die Praxis umzusetzen. „Ich habe breit gefächerte Interessen“, sagt Şahin. „Ich mag alle Arten von Teilbereichen der Wissenschaft und Technik. In der Systemtechnik kann ich dieser Neugierde nachgehen. Das ist auch der Grund, warum ich so gerne lerne und Kurse besuche. Als Systemingenieur muss man ein komplexes System und den technischen Hintergrund der einzelnen Teile kennen. Sie müssen in der Lage sein, tiefer in das Design einzutauchen. Sie müssen in der Lage sein, in die verschiedenen Disziplinen einzutauchen, aber gleichzeitig den Blick aus dem Hubschrauber nicht verlieren. Dieses Gleichgewicht zu halten ist etwas, das ich sehr mag.“

Buket Şahin im ASML-Erfahrungszentrum.

NASA-Handbuch

Şahin begann, Kurse zu belegen, sobald sie bei ASML gelandet war. Sie erkannte, dass sie ihr Wissen über das hinaus erweitern sollte, was ihre Abschlüsse ihr beigebracht hatten. „Sie waren sehr theoretisch“, gibt sie zu. „Sie waren nicht sehr anwendungsbezogen. Die Forschungs- und Entwicklungsindustrie in der Türkei ist nicht so ausgereift wie in den Niederlanden, insbesondere im Bereich der Halbleiter. In den Niederlanden gibt es eine sehr gute Interaktion zwischen den Universitäten und der Industrie. Ich wollte dieses praktische Wissen erwerben. Also begann ich mit Kursen in Mechatronik und Elektronik. Dann wollte ich etwas über Optik lernen, ein sehr relevantes Gebiet, wenn man bei ASML arbeitet. Von da an habe ich einfach weitergemacht.“

Neugierde ist eine treibende Kraft für Şahin. „Einige Kurse habe ich belegt, weil ich das Wissen für meine Arbeit brauchte, aber andere waren aus Neugierde. Ich wollte mich weiterentwickeln und neue Dinge lernen. Die Kurse haben mir das ermöglicht.“

Interessanterweise belegte sie jedoch keine Kurse über Systemtechnik. „Ich war hauptsächlich auf der Suche nach tieferen Kenntnissen in verschiedenen technischen Disziplinen“, blickt sie zurück. „Meine erste Stelle war die eines Systemingenieurs, aber die Art und Weise, wie die Rolle in den verschiedenen Unternehmen definiert ist, variiert stark. Systemingenieure in der Halbleiterindustrie benötigen Kenntnisse in den verschiedenen Teilbereichen der Branche. Eine ASML-Maschine ist außerdem sehr komplex, so dass Sie Ihr Wissen auf den neuesten Stand bringen müssen. Die Dinge können sich schnell ändern, und Sie müssen auf dem Laufenden bleiben. Deshalb ist das Lernen ein so wichtiger Teil meiner Karriere.“

Sie hat gelernt, wie man bei ASML Systemingenieurin wird, sowohl durch Lernen am Arbeitsplatz als auch durch interne Kurse. „Es gibt interne ASML-Schulungen für Systemtechnik“, sagt Şahin. „Deshalb brauchte ich keine externen Kurse. Außerdem habe ich das Fachgebiet aus dem NASA System Engineer Handbook in der Türkei gelernt. Das ist auch die Methodik, die ASML verwendet.“

Praktisches Wissen

Wenn Şahin auf all die Kurse zurückblickt, die sie seit ihrem Umzug in die Niederlande belegt hat, sind es die praktischen Kurse, die hervorstechen. „Das Wichtigste, was ich gelernt habe, war angewandtes Wissen“, sagt sie. „An der Universität habe ich die Theorie gelernt, aber es sind die alltäglichen Erkenntnisse, die wichtig sind. Ich mag es besonders, wenn man in den Kursen Faustregeln, pragmatische Ansätze und Beispiele aus der Branche selbst lernt. Das ist für mich das wichtigste Wissen. Es ist besonders hilfreich, wenn die Dozenten aus der Branche kommen, so dass sie uns zeigen können, woran sie selbst gearbeitet haben.“

Seit 2012 ist auch das Lernen einfacher geworden. „Als ich anfing, gab es nicht so viele Lernstrukturen, an denen man sich orientieren konnte. Das High Tech Institute hat heute zum Beispiel eine leicht zugängliche Kursliste. Im Jahr 2012 musste ich dagegen viel mehr recherchieren, und die Kurse wurden nicht so stark beworben und waren sogar nur auf Niederländisch. Ich musste Kollegen fragen und mich selbst erkundigen. Wenn ich heute anfangen würde, wäre es viel einfacher gewesen.“

„Wenn es Ihnen hilft, Ihr Ziel zu erreichen, ist es sehr einfach, Kurse zu belegen, wenn Sie bei ASML arbeiten“, sagt Şahin.

Bei ASML freut man sich über Şahins neue Zertifizierung und den Hunger, den sie zeigt, um neue Dinge zu lernen. „Meine Manager haben mich immer unterstützt“, sagt Şahin. „Wir definieren Entwicklungsziele und wählen die Schulungen aus, mit denen diese Ziele erreicht werden können. Wenn es Ihnen hilft, Ihr Ziel zu erreichen, ist es sehr einfach, Kurse zu besuchen, wenn Sie bei ASML arbeiten.“

Şahin ist noch lange nicht fertig. Für sie hört das Lernen nie auf. „Ich habe gerade ein Masterprogramm an der KU Leuven begonnen. Es ist ein fortgeschrittener Master in Sicherheitstechnik, der mit meiner Position bei ASML verbunden ist. Mein kurzfristiges Ziel ist es, diesen Master abzuschließen. Danach möchte ich meine Karriere hier bei ASML als Systemingenieur fortsetzen. Lernen ist für mich jedoch ein Ziel an sich, ob es nun mit meinem Job zusammenhängt oder nicht.“

Dieser Artikel wurde von Tom Cassauwers geschrieben, freier Mitarbeiter bei Bits&Chips.

 

Ger Cloudt begann in den frühen 1980er Jahren mit Lochkarten und lernte dabei wertvolle Lektionen über die Entwicklung guter Software. Der neue Trainer des High Tech Institute teilt seine Erkenntnisse über das Zusammenspiel von Prozessen und Fähigkeiten, über die Messung von Softwarequalität und über die Förderung einer Unternehmenskultur, in der Ingenieure hochwertige Software liefern können.

Ger Cloudts erste Begegnung mit der Programmierung war die Verwendung von Lochkarten während seines Elektronikstudiums an der Fontys Venlo University of Applied Sciences in den frühen 1980er Jahren. Nach seinem Abschluss begann er eine Karriere als digitaler Elektronikingenieur, wobei er sich sowohl auf das Design digitaler Schaltungen als auch auf die Entwicklung von Software zur Steuerung von Mikroprozessoren konzentrierte. „Das war in Assembler und ich erinnere mich, dass ich wirklich unstrukturierten Spaghetti-Code erstellt habe“, erinnert sich Cloudt. „Das machte die Fehlersuche und -behebung natürlich äußerst schwierig und erteilte mir eine harte Lektion, dass es einen besseren Weg geben muss.“

Glücklicherweise bekam Cloudt bei seinem zweiten Auftrag einen erfahrenen Mentor zur Seite gestellt, der ihm beibrachte, mit strukturiertem Pseudocode zu beginnen und diesen dann in Assembler umzuwandeln. „Das war das erste Mal, dass ich erlebte, dass Struktur die Erstellung von robustem Code erleichtern und die Fehlersuche vereinfachen kann.“ Diese Erfahrung führte dazu, dass er ein paar Jahre später in die Softwareentwicklung wechselte.

Prozess versus Fähigkeit

Cloudt arbeitete anschließend bei Philips Medical Systems als Softwareentwicklungsingenieur und später als Softwarearchitekt, wo er lernte, wie sich Prozesse und Fähigkeiten gegenseitig ergänzen. „Um Handlungen auszuführen, braucht man ein bestimmtes Fähigkeitsniveau, während Handlungen durch einen Prozess strukturiert werden müssen, um Ergebnisse zu erzielen. Die Bedeutung von Prozessen oder Fähigkeiten hängt jedoch von der Art der Aufgabe ab. Einerseits gibt es Aufgaben wie die Arbeit am Fließband oder der Aufbau der gekauften Ikea-Möbel, die einen strengen Prozess, aber nur minimale Anforderungen an die Fähigkeiten erfordern. Andererseits sind Aufgaben wie das Malen der Mona Lisa, wie es Leonardo da Vinci getan hat, weniger prozessorientiert, erfordern aber ein hohes Maß an Fähigkeiten, über die nur wenige verfügen.“

In dieser Zeit beobachtete Cloudt eine starke Betonung der Prozesse in der Softwareentwicklung. „Dies war die Zeit, in der das Capability Maturity Model aufkam, das auf die Verbesserung der Softwareentwicklungsprozesse abzielte. Doch selbst wenn Prozesse vorhanden sind, sind Fähigkeiten weiterhin unerlässlich. Bei dem Streben nach hohen CMM-Niveaus besteht die Gefahr, dass die Fähigkeiten unterbewertet werden.“ Diese Einsicht wurde noch verstärkt, als Cloudt bei Philips Medical Systems in eine Führungsposition wechselte und Teams mit sechzig Mitarbeitern leitete. „Das Erreichen eines bestimmten CMM-Levels wird schnell zu einem Ziel an sich, und wie Goodharts Gesetz besagt: Wenn eine Maßnahme zu einem Ziel wird, hört sie auf, eine gute Maßnahme zu sein. Ich war zunehmend der Meinung, dass für Software-Ingenieure Fähigkeiten wichtiger sind als Prozesse. Ein Prozess kann die Anwendung Ihrer Fähigkeiten erleichtern, aber bei unzureichenden Fähigkeiten hilft kein Prozess.“

Cloudt lernte später die Bedeutung von Transparenz kennen. „In meiner ersten Rolle im Qualitätsmanagement musste ich mich mit einem Problem befassen, bei dem es um die Integration von zwei verschiedenen Software-Stacks ging. Ein Team entwickelte NFC-Software, ein anderes arbeitete an Software für ein sicheres Element. Beide zu integrieren, erwies sich als Herausforderung. Als ich mir die Sache genauer ansah, entdeckte ich, dass die Teams zwar ihre Software testeten, Testfehler aber nicht systematisch überwacht wurden. Also erstellten wir täglich aktualisierte Dashboards mit den Testergebnissen, und die Entwickler diskutierten täglich über die Ergebnisse. Wir teilten die Dashboards sogar mit dem Kunden. Natürlich sah anfangs alles rot aus, aber das war ein starker Anreiz für die Entwickler, sich zu verbessern. Folglich war das Projekt erfolgreich.“

Lernen durch Teilen

In seiner Funktion als Software R&D Manager bei Bosch verspürte Cloudt das Bedürfnis, seine Erkenntnisse über Softwarequalität mit anderen zu teilen. Er begann damit, Artikel im internen sozialen Netzwerk des Unternehmens sowie auf Linkedin zu veröffentlichen. „Ich erhielt viel positives Feedback, insbesondere von Bosch-Kollegen“, sagt er. „Also beschloss ich 2020, ein Buch zu schreiben: ‚Was ist Softwarequalität?‘. Diese Erfahrung war sehr bereichernd, da sie viel von meinem impliziten Wissen explizit machte und auch Lücken in meinem Wissen aufdeckte.“

In einem Qualitätsausschuss bei Bosch traf Cloudt einen jungen Absolventen mit einem Master-Abschluss in Qualitätsmanagement. Als er den Absolventen fragte, ob er einen Kurs über Softwarequalität belegt habe, war die Antwort negativ. „Daraufhin wandte ich mich an das Doktorandenprogramm für Ingenieure an der Technischen Universität Eindhoven, wo man mich einlud, eine Gastvorlesung zu halten. Schließlich wurde ich Dozentin für einen Qualitätsmanagementkurs.“ Cloudt begann auch, auf Veranstaltungen über Softwarequalität zu sprechen, z. B. auf einer Bits&Chips-Veranstaltung im Jahr 2021, und er führt derzeit zwei Schulungsprogramme am High Tech Institute durch, eines für Ingenieure und eines für Manager. Derzeit ist er Software-Qualitätsmanager für die Entwicklung der Digital Application Platform bei ASML.

Messung der Softwarequalität

Softwarequalität als solche ist nicht messbar, behauptet Cloudt, weil das Konzept so vielfältig ist. „Sie können einige spezifische Aspekte der Softwarequalität messen, die als ‚modellierte Qualität‘ bezeichnet werden. Dazu gehören die zyklomatische Komplexität des Codes, Abhängigkeiten, Codeabdeckung, Zeilenzahl und offene Fehler. Solche Metriken sind nützlich, aber jeder, der sich damit Ziele setzt, sollte sich vor dem Goodhart’schen Gesetz in Acht nehmen.“

Ein wesentlicher Teil der Qualität bleibt unmessbar: die transzendente Qualität. Um dies zu veranschaulichen, vergleicht Cloudt es mit der Bewertung eines Gemäldes. „Sie können die Dicke der Farbe und die Größe der Leinwand messen, aber Sie können nicht die Schönheit des Gemäldes messen. Dasselbe gilt für Softwarequalität: Sie können die Codeabdeckung durch Ihre Unit-Tests messen, aber das sagt nichts darüber aus, ob die Tests gut sind. Dafür brauchen Sie eine Expertenmeinung, die durch die von Ihnen gemessene modellierte Qualität gestützt wird.“

Wenn man über Softwarequalität nachdenkt, werden oft Aspekte wie Modularität, sauberer Code und Benutzerfreundlichkeit genannt. Dies sind Beispiele für Designqualität (z.B. Modularität, Wartbarkeit und Trennung von Belangen), Codequalität (z.B. sauberer Code, Portabilität und Unit-Tests) und Produktqualität (z.B. Benutzerfreundlichkeit, Sicherheit und Zuverlässigkeit). Cloudt zufolge erfordern diese drei Arten von Qualität jedoch ein häufig übersehenes Element: die organisatorische Qualität. „Diese Art von Qualität bestimmt, ob Ihre Organisation in der Lage ist, hochwertige Software zu entwickeln. Aspekte wie Software-Handwerk, ausgereifte Prozesse, Zusammenarbeit und Kultur sind für die organisatorische Qualität entscheidend. Unterschätzen Sie niemals die Kultur. Ein Unternehmen sollte ein Umfeld schaffen, in dem sich Softwareingenieure entfalten und exzellente Design-, Code- und Produktqualität liefern können.“

Geplantes und umgesetztes Design

Es gibt mehrere bekannte Best Practices für die Entwicklung hochwertiger Software, darunter die testgetriebene Entwicklung (TDD) und die Paarprogrammierung, sowie die statische Codeanalyse. Cloudt fügt noch etwas hinzu, das weniger bekannt ist: die statische Designanalyse. „Vielen ist nicht klar, dass es einen Unterschied zwischen dem beabsichtigten Design und dem implementierten Design von Software gibt. Softwarearchitekten dokumentieren ihr geplantes Design in UML-Modellen. Oft besteht jedoch eine Lücke zwischen diesem beabsichtigten Design und seiner Umsetzung in Code. Diese Lücke klein zu halten, ist eine bewährte Praxis. Tools können die Konsistenz zwischen Ihrem Code und den UML-Modellen überprüfen und Warnungen ausgeben, wenn Diskrepanzen auftreten.“

Diese Diskrepanz zwischen beabsichtigtem und umgesetztem Design entsteht oft unter Zeitdruck, zum Beispiel aufgrund von Projektfristen. „In solchen Fällen nehmen Sie eine Abkürzung, indem Sie eine Lösung ‚hacken‘, die es Ihnen ermöglicht, die Frist einzuhalten, wobei Sie weniger Wert auf Qualität legen“, erklärt Cloudt. „Dies ist eine bewusste Entscheidung, um technische Schulden aufgrund von Zeitdruck einzuführen. Auch wenn dies die einzige unmittelbare Lösung sein mag, ist es wichtig, diese technischen Schulden später anzugehen. Nach der Veröffentlichung sollten Sie sich etwas Zeit nehmen, um eine angemessene, qualitativ hochwertige Lösung zu entwickeln. Leider ist das nicht oft der Fall. Manager sollten erkennen, dass sie den Entwicklern Zeit geben müssen, um diese Lücke und diese technischen Schulden abzubauen, um zukünftige Probleme zu vermeiden. Durch ihre Entscheidungen tragen Manager wesentlich zur Qualität des Unternehmens bei und haben damit direkten Einfluss auf die Softwarequalität.“

Dieser Artikel wurde geschrieben von Koen Vervloesem, freier Mitarbeiter bei Bits&Chips.

Da KI-Technologien aufgrund ihrer Produktivitätsgewinne in Softwareentwicklungsprozesse eingebettet werden, stehen Entwickler vor komplexen Sicherheitsherausforderungen. Erkunden Sie mit Balázs Kiss die wesentlichen Sicherheitspraktiken und Eingabeaufforderungstechniken, die für einen verantwortungsvollen und effektiven Einsatz von KI erforderlich sind.

Der Einsatz von künstlicher Intelligenz (KI) in der Softwareentwicklung hat in den letzten Jahren zugenommen. Wie bei jedem technologischen Fortschritt bringt dies auch Sicherheitsaspekte mit sich. Balázs Kiss, Leiter der Produktentwicklung beim ungarischen Schulungsanbieter Cydrill Software Security, hat die Sicherheit des maschinellen Lernens bereits vor der allgemeinen Aufmerksamkeit für generative KI unter die Lupe genommen. „Während heute alle über große Sprachmodelle diskutieren, lag der Fokus im Jahr 2020 vor allem auf maschinellem Lernen, wobei die meisten Anwender Wissenschaftler in Forschungs- und Entwicklungsabteilungen waren.“

Bei der Untersuchung des aktuellen Stands der Technik stellte Kiss fest, dass viele grundlegende Konzepte aus der Welt der Software-Sicherheit ignoriert wurden. „Aspekte wie Eingabevalidierung, Zugriffskontrolle, Sicherheit der Lieferkette und die Vermeidung einer übermäßigen Ressourcennutzung sind für jedes Softwareprojekt wichtig, auch für das maschinelle Lernen. Als ich also feststellte, dass die Leute diese Praktiken in ihren KI-Systemen nicht einhalten, habe ich mich mit möglichen Angriffen auf diese Systeme beschäftigt. Das Ergebnis ist, dass ich nicht davon überzeugt bin, dass maschinelles Lernen sicher genug ist, um es ohne menschliche Aufsicht einzusetzen. Der KI-Forscher Nicholas Carlini von Google Deepmind verglich den aktuellen Stand der ML-Sicherheit sogar mit den Anfängen der Kryptographie vor Claude Shannon, ohne starke Algorithmen, die auf einer strengen mathematischen Grundlage beruhen.“

Als die Popularität großer Sprachmodelle zunahm, bemerkte Kiss, dass die gleichen grundlegenden Sicherheitsprobleme wieder auftauchten. „Sogar die gleichen Namen tauchten in Forschungsarbeiten auf. Carlini war beispielsweise an der Entwicklung eines Angriffs beteiligt, mit dem automatisch Jailbreaks für jedes LLM generiert werden können – ein Spiegelbild der gegnerischen Angriffe, die seit einem Jahrzehnt gegen Computer-Vision-Modelle eingesetzt werden.“

Fabrizierte Abhängigkeiten

Wenn Entwickler derzeit einen LLM verwenden, um Code zu generieren, müssen sie bedenken, dass sie im Wesentlichen eine erweiterte Autovervollständigungsfunktion verwenden. „Die Ausgabe ähnelt dem Code, auf den sie trainiert wurde, und wirkt recht überzeugend. Das ist jedoch keine Garantie für seine Korrektheit. Wenn ein LLM beispielsweise Code generiert, der eine Bibliothek enthält, fabriziert er oft einen falschen Namen, weil das ein Wort ist, das in diesem Kontext Sinn ergibt. Cyberkriminelle erstellen jetzt Bibliotheken mit diesen fiktiven Namen, betten Malware ein und laden sie in beliebte Code-Repositories hoch. Wenn Sie also diesen generierten Code verwenden, ohne ihn zu überprüfen, kann Ihre Software unbeabsichtigt Malware ausführen.“

In den USA hat das National Institute of Standards and Technology (NIST) sieben wesentliche Bausteine für eine verantwortungsvolle KI festgelegt: Validität und Zuverlässigkeit, Sicherheit, Sicherheit und Widerstandsfähigkeit, Rechenschaftspflicht und Transparenz, Erklärbarkeit und Interpretierbarkeit, Datenschutz und Fairness mit Abmilderung schädlicher Verzerrungen. „Der Angriff mit den gefälschten Bibliotheken ist ein Beispiel, bei dem Sicherheit und Widerstandsfähigkeit gefährdet sind, aber die anderen Bausteine sind für eine vertrauenswürdige und verantwortungsvolle KI ebenso wichtig. Validität und Zuverlässigkeit‘ bedeutet zum Beispiel, dass die Ergebnisse durchweg korrekt sein sollten: Wenn Sie einmal ein korrektes Ergebnis erhalten und das nächste Mal ein falsches, wenn Sie das LLM mit der gleichen Aufgabe betrauen, ist das nicht zuverlässig.“

Was die Voreingenommenheit betrifft, so wird diese oft in anderen Bereichen verstanden, z. B. bei großen Sprachmodellen, die stereotype Annahmen über Berufe von Männern und Frauen ausdrücken. Aber auch ein Datensatz mit Code kann eine Verzerrung aufweisen, erklärt Kiss. „Wenn ein LLM ausschließlich auf Open-Source-Code von Github trainiert wird, könnte es zu Code tendieren, der dieselben Bibliotheken verwendet wie der Code, auf dem es trainiert wurde, oder zu Code mit englischer Dokumentation. Dies wirkt sich auf die Art des Codes aus, den der LLM generiert, und auf seine Leistung bei Aufgaben, die mit Code ausgeführt werden, der sich von dem unterscheidet, den er in seinem Trainingsset gesehen hat, und der möglicherweise schlechter abschneidet, wenn er mit einer benutzerdefinierten Closed-Source-API interagiert.

Balasz Kiss
Credits: Egressy Orsi Foto

Effektive Eingabeaufforderung

Laut Kiss sind viele Best Practices für den verantwortungsvollen Einsatz von KI in der Softwareentwicklung nicht neu. „Validieren Sie die Benutzereingaben in Ihrem Code, überprüfen Sie die von Ihnen verwendeten Bibliotheken von Drittanbietern, suchen Sie nach Schwachstellen – all das ist im Sicherheitsbereich allgemein bekannt. Es gibt viele Tools, die Sie bei diesen Aufgaben unterstützen.“ Sie können sogar KI verwenden, um von KI erzeugten Code zu überprüfen, schlägt Kiss vor. „Geben Sie den generierten Code zurück in das System und bitten Sie es um Kritik. Gibt es irgendwelche Probleme mit diesem Code? Wie könnten sie behoben werden?“ Die Ergebnisse dieses Ansatzes können recht gut sein, so Kiss, und je präziser Ihre Fragen sind, desto besser ist die Leistung des LLM. „Fragen Sie nicht nur, ob der generierte Code sicher ist. Wenn Sie wissen, welche Art von Schwachstellen zu erwarten sind, wie z.B. Cross-Site-Scripting-Schwachstellen in Webanwendungen, sollten Sie diese in Ihren Fragen angeben.“

Für die Erstellung effektiver Prompts, d.h. der Fragen, die Sie dem LLM stellen, gibt es viele neue Best Practices. One-shot oder few-shot Prompting, bei dem Sie dem LLM ein oder wenige Beispiele für die erwartete Ausgabe vorgeben, ist laut Kiss eine leistungsstarke Technik, um zuverlässigere Ergebnisse zu erzielen. „Wenn Ihr Code zum Beispiel derzeit XML-Dateien verarbeitet und Sie zu JSON wechseln möchten, können Sie einfach darum bitten, den Code so umzuwandeln, dass er JSON verarbeiten kann. Der generierte Code wird jedoch viel besser sein, wenn Sie ein Beispiel für Ihre Daten im XML-Format neben denselben Daten im JSON-Format einfügen und um einen Code bitten, der stattdessen Daten im JSON-Format verarbeitet.“

Eine weitere nützliche Prompting-Technik ist das sogenannte Chain-of-Thought-Prompting, bei dem ein LLM angewiesen wird, seinen Denkprozess zur Erlangung einer Antwort darzustellen und so das Ergebnis zu verbessern. Kiss hat diese und andere Prompting-Techniken sowie wichtige Fallstricke in einer eintägigen Schulung über verantwortungsvolle KI in der Softwareentwicklung am High Tech Institute zusammengestellt. „Zum Beispiel sind Unit-Tests, die von einem LLM generiert werden, oft ziemlich repetitiv und daher nicht besonders nützlich. Aber mit den richtigen Aufforderungen können sie verbessert werden. Sie können auch testgetriebene Entwicklung betreiben, indem Sie die Unit-Tests selbst schreiben und den LLM bitten, den entsprechenden Code zu erzeugen. Diese Methode kann sehr effektiv sein.“

Hier zu bleiben

Bei all diesen Vorsichtsmaßnahmen könnte man sich fragen, ob das große Versprechen der KI-Codegenerierung, nämlich die Steigerung der Entwicklerproduktivität, noch gilt. „Eine aktuelle Studie, die auf randomisierten kontrollierten Studien basiert, bestätigt, dass der Einsatz generativer KI die Produktivität von Entwicklern um 26 Prozent erhöht“, stellt Kiss fest, wobei die Vorteile für weniger erfahrene Entwickler sogar noch größer sind. Er warnt jedoch davor, dass dies ein Fallstrick für junge Entwickler sein könnte. „Beim derzeitigen Stand der generativen KI ist es möglich, Code zu schreiben, ohne das Programmieren zu verstehen. Der bekannte KI-Forscher Andrej Karpathy bemerkte sogar: ‚Die heißeste neue Programmiersprache ist Englisch.‘ Aber wenn Sie den generierten Code nicht verstehen, wie sollen Sie ihn dann pflegen? Das führt zu technischen Schulden. Wir wissen noch nicht, wie sich der dauerhafte Einsatz dieser Tools auf die Wartbarkeit und Robustheit auswirken wird.“

Auch wenn der Einsatz von KI in der Softwareentwicklung nicht ganz unproblematisch ist, so Kiss, wird sie sich zweifelsohne durchsetzen. „Auch wenn es heute wie eine Blase oder ein Hype aussieht, gibt es nachweisbare Vorteile, und die Technologie wird sich weiter durchsetzen. Viele Tools, die wir heute sehen, werden verbessert und sogar in integrierte Entwicklungsumgebungen integriert werden. Microsoft hat seinen Copilot bereits fest in seine Visual Studio Produkte integriert und ist damit nicht allein. Die menschliche Aufsicht wird jedoch immer notwendig sein. Letztendlich ist die KI nur ein Werkzeug, wie jedes andere Werkzeug, das Entwickler verwenden. Und LLMs haben inhärente Grenzen, wie z.B. ihre Tendenz zu „Halluzinationen“ – also zu Fälschungen. Das liegt an ihrer probabilistischen Natur, und die Benutzer müssen sich dessen immer bewusst sein, wenn sie sie einsetzen.

Dieser Artikel wurde geschrieben von Koen Vervloesem, freier Mitarbeiter bei Bits&Chips.