KI-generierter Code kann gut funktionieren und dennoch für Ingenieure schwer zu erklären bleiben. Das ist nützlich, bis jemand eine Änderung prüfen, einen Fehler diagnostizieren oder entscheiden muss, was das System als Nächstes bauen soll.
Vom Schreiben von Code zur Aufsicht darüber
Jeremy Nixon, Gründer von Infinity, sagt, Programmierer verlören zunehmend den Überblick darüber, was Sprachmodelle hervorbringen. Seiner Darstellung nach bewegen sich Entwickler weg davon, Produkte Zeile für Zeile zu bauen, und hin zur Aufsicht über die Arbeit des Modells.
Ein prägnantes Beispiel stammt von OpenAI. Jordan Nanos, ein technischer Mitarbeiter bei SemiAnalysis, beschrieb, wie Ingenieure dort GPU-Kernel-Code prüften, der zur Verbesserung der Leistung geschrieben worden war. Sie hätten demnach Mühe gehabt nachzuvollziehen, was der Code tat, obwohl die Kernel korrekte und hochwirksame Ergebnisse lieferten.
Nanos sieht das nicht als Beleg dafür, dass die Ingenieure unfähig sind, sondern als Veränderung der Arbeitsteilung. Entwickler legen die Architektur fest und entscheiden, was als akzeptables Ergebnis gilt, während die KI einen größeren Teil der Implementierung übernimmt. Der Code kann seine Tests bestehen, auch wenn die Verantwortlichen nicht ohne Weiteres jeden Teil erklären können.
Diese Anordnung verändert die Bedeutung technischer Aufsicht. Ein Ergebnis zu prüfen ist nicht ganz dasselbe, wie zu verstehen, wie es entstanden ist, auch wenn beides ähnlich wirken kann, solange alles funktioniert.
Das Produktionsrisiko
Funktionierender Code ist nicht automatisch sicherer Code. KI-Systeme können Fehler machen oder plausible, aber falsche Ausgaben erzeugen, und diese Fehler können die Produktion erreichen, wenn Ingenieure sie nicht abfangen.
Amazon führte früher in diesem Jahr einen 90-Tage-Code-Sicherheitstest ein, nachdem eine Reihe von Ausfällen die Auftragsabwicklung gestört hatte. Das Unternehmen bestritt, dass KI verantwortlich sei. Interne Logs und Notizen zeigten jedoch, dass Manager über die großen möglichen Auswirkungen KI-generierter Änderungen besorgt waren.
Die Darstellung zitiert außerdem Zahlen des Softwareunternehmens Undo. Dessen Analyse ergab, dass 35 % des KI-generierten Codes in die Produktion gelangen, ohne dass Ingenieure ihn vollständig verstehen. In derselben Analyse gaben 29 % der Entwickler an, mehrmals im Monat Produktivität zu verlieren, während sie von KI geschriebenen Code entwirren, und 94 % sagten, sie hätten das in den vorangegangenen sechs Monaten mindestens einmal erlebt.
Diese Zahlen deuten auf eine Unterscheidung hin, die sich leicht verwischt: Code zu erzeugen kann in einer Phase Aufwand sparen und später mehr Arbeit schaffen. Wie groß dieser zusätzliche Aufwand ist und wie die Zahlen erhoben wurden, wird im Bericht nicht ausgeführt.
Eine Frage der Kompetenzen, nicht nur der Werkzeuge
Die Sorge reicht darüber hinaus, ob eine bestimmte Codeänderung sicher ist. Der Bericht verweist außerdem auf Forschung, die kognitiven Abbau und den Verlust von Fähigkeiten bei Fachleuten beschreibt, die aufhören, Code von Hand zu schreiben, ohne die Kompetenzen zu entwickeln, die für den Entwurf größerer Systeme nötig sind.
Das stellt Entwickler vor ein schwieriges Gleichgewicht. Wenn sie sich für mehr Implementierungsarbeit auf Modelle stützen, haben sie möglicherweise mehr Zeit, sich auf Architektur und Abnahmekriterien zu konzentrieren. Diese Aufgaben erfordern jedoch genug technisches Verständnis, um zu beurteilen, ob die Ausgabe des Modells tragfähig ist, besonders dann, wenn die Tests ein Problem nicht sichtbar machen.
Die praktische Herausforderung besteht nicht darin, dass Ingenieure persönlich jede Zeile tippen müssen. Sie besteht darin, dass Verantwortung nicht verschwindet, wenn die Urheberschaft auf ein Modell übergeht. Teams brauchen weiterhin Möglichkeiten, Änderungen zu prüfen, Fehler zu erkennen und das Wissen zu bewahren, das nötig ist, um Entscheidungen über komplexe Systeme zu treffen.
KI verändert das Programmieren womöglich vom Schreiben von Anweisungen hin zum Anleiten und Prüfen. Das Unangenehme daran ist, dass ein Programm heute korrekt sein kann und dennoch von den Menschen, die es morgen reparieren sollen, schlecht verstanden wird.