So gut (oder schlecht) ist der KI-Programmierer: 60 Prozent des Codes nutzbar
Dass KI programmieren kann, ist nicht neu – aber wie gut sie das kann, bleibt unklar. Symflower wagt jetzt den Versuch eines systematischen Vergleichs.
(Bild: iX)
- Prof. Christian Winkler
Es gibt neue Einblicke, wie gut LLMs programmieren können – denn bislang war es schwer zu messen, wie zuverlässig Sprachmodelle arbeiten. Häufig liefern sie gute Ergebnisse, manchmal keine und selten auch falsche – diese Halluzinationen sind dann aber oft sehr überzeugend formuliert. Für generische Sprachmodelle haben sich deshalb Benchmarks unter Beteiligung von Menschen etabliert, zum Beispiel die Chatbot Arena von LMSYS. Parallel dazu werden einzelne Qualitätskriterien gemessen, die man dann in Leadboards aggregiert.
Code systematisch überprüfen
Für speziellere Sprachmodelle kann man das deutlich systematischer machen. An erster Stelle bieten sich dazu LLMs an, die Programm-Code generieren können. Diesen Code kann man syntaktisch und semantisch überprüfen. Symflower, ein Anbieter von Software zur automatischen Testgenerierung, hat genau das untersucht und eine ganze Blog-Serie dazu verfasst. Die darin gewonnen Erkenntnisse sind spannend und lassen interessante Einblicke in die Leistungsfähigkeit der LLMs zu.
Allerdings gibt es ein paar Einschränkungen: Die Code-Generierung wird nur für Java und Go durchgeführt. Andere, weitverbreitete Programmiersprachen wie Python und JavaScript finden bislang keine Berücksichtigung. Ob die Ergebnisse sich dort auch reproduzieren lassen, ist somit unklar. Es wäre denkbar, dass sich wegen des größeren Umfangs an verfügbarem Code hier bessere Ergebnisse erzielen lassen.
In früheren Teilen der Blog-Serie wurden nur Tests für einfache, "leere" Klassen generiert. Das ist jetzt deutlich erweitert und das Szenario hat sich verkompliziert. LLMs sollen nun Test für 23 echte Programmierbeispiele erzeugen. Dabei finden sich spannende Erkenntnisse:
- Nur 58 Prozent der Ergebnisse waren überhaupt übersetzbar (nur bei zehn Modellen war es mehr als 80 Prozent). Hier sind also manuelle Nacharbeiten erforderlich. Diese Metrik lässt sich für Compiler-Sprachen einfach messen, bei Python und JavaScript wäre das schwierig.
- Manche Modelle haben überhaupt keinen übersetzbaren Code erzeugt. Das wäre vergleichbar mit einem echten Programmierer, der nur syntaktisch falschen Code erzeugt.
- Die meisten syntaktischen Fehler waren eher trivial und lassen sich mit IDE-Unterstützung schnell beheben.
- Für Java haben drei Modelle (gpt-4o, deepseek-coder, claude-3-opus) immer übersetzbaren Code erzeugt. Bei Go war das leider nicht möglich (was sicher mit der kleineren Trainingsmenge zusammenhängt).
Menschen bleiben unverzichtbar
Programmierer sind also in jedem Fall weiter notwendig. Erstaunlich ist, dass das die Code-Generierung mit Java so viel besser klappt als mit Go. Die größere Trainingsmenge ließe also hoffen, dass es mit Python und JavaScript auch gut funktionieren könnte. Allerdings sind die Metriken dort schwerer zu bestimmen, weil der Code nicht übersetzt werden muss. Die dynamische Typisierung kann zu weiteren Fehlern führen, die man manuell überprüfen muss.
Einzelne Modelle gehen unterschiedlich mit Exceptions um: Hier gibt es sowohl die Option, diese zu fangen, oder alternativ den Test in einem solchen Fall einfach scheitern zu lassen. Beide Strategien werden auch von menschlichen Programmierern verwendet, also haben die Modelle einfach beides gelernt.
Spannend ist das Ranking der Modelle. Im Vergleich zum letzten Test hat Symflower den Score etwas verändert und optimiert. Dieser Prozess ist noch nicht am Ende, denn manche Modelle erzeugen eine höhere Abdeckung, während sich bei anderen mehr Tests übersetzen lassen. Daher wird der Score für die nächste Iteration noch mal überarbeitet.
Schließlich stellt der Artikel noch dar, wie effizient die Tests sind. In manchen Fällen generieren die LLMs etwa synchrone statt asynchrone Methoden, was zu erheblich längeren Laufzeiten führt. Durch ungünstigen Umgang mit Permutationen und entsprechenden Logging erzeugten Tests riesige Logfiles. Beides kann leicht dazu führen, dass ganze Test-Suites nicht mehr laufen und dadurch die Stabilität der gesamten Software gefährdet wird.
Der Artikel dokumentiert genau, wie die Modelle ausgewählt wurden, welche Sandboxes zum Einsatz kamen und vieles mehr. Das ist praktisch, wenn man die Tests selbst ausprobieren möchte. Die technische Beschreibung ermöglicht einen leichten Einstieg in das Framework, das auf GitHub veröffentlicht ist.
(fo)