SWE-Pro
SWE-Pro ist ein Test, mit dem geprüft wird, wie gut KI-Systeme echte Programmieraufgaben aus professionellen Softwareprojekten lösen. Statt kleiner Übungsaufgaben bekommt die KI reale Fehlerberichte und muss den Code so ändern, dass die Prüfprogramme des Projekts durchlaufen.
SWE-Pro ist ein Prüfverfahren für Programme, die selbstständig Software schreiben oder reparieren. Solche Prüfverfahren nennt man Benchmark: eine feste Sammlung von Aufgaben, die alle Teilnehmer unter gleichen Bedingungen lösen. Die Aufgaben in SWE-Pro stammen aus echten, öffentlich einsehbaren Softwareprojekten. Ein getestetes System bekommt eine Fehlerbeschreibung und den kompletten Programmcode des Projekts. Es muss herausfinden, welche Datei fehlerhaft ist, und die Stelle so ändern, dass der Fehler verschwindet. Ob das gelungen ist, entscheidet kein Mensch, sondern automatische Testprogramme, die das Projekt ohnehin schon besitzt.
Was der Test über KI-Programmierer aussagt
Fast jeder Anbieter behauptet, sein Modell könne programmieren. Solche Aussagen sind wertlos, solange niemand sie nachprüfen kann. Ein Benchmark macht die Behauptung überprüfbar, weil alle die gleichen Aufgaben bekommen. Man kann dann sagen: System A löst 43 von 100 Aufgaben, System B nur 28.
Der Name deutet an, worin der Unterschied zu älteren Tests liegt. „Pro“ steht für professionell: Die Aufgaben stammen aus Projekten, an denen bezahlte Entwickler arbeiten. Solcher Code ist unübersichtlich, gewachsen und schlecht dokumentiert. Frühere Programmiertests bestanden dagegen oft aus kleinen, sauber formulierten Einzelaufgaben. Diese Aufgaben lösen heutige Modelle fast vollständig, weshalb sie kaum noch etwas unterscheiden.
Für Firmen ist die Zahl aus solchen Tests eine Entscheidungshilfe. Wer ein KI-Werkzeug für sein Entwicklerteam kauft, will wissen, ob es bei echter Arbeit hilft. Ein hoher Wert in einem Test mit Übungsaufgaben sagt darüber wenig aus. Deshalb bekommen realistische Benchmarks in Fachnachrichten mehr Gewicht als früher.
Vom Fehlerbericht zum grünen Testlauf
Der Ablauf orientiert sich am Alltag in einem Entwicklerteam. Nutzer melden Fehler in einem öffentlichen Verzeichnis, dem sogenannten Issue-Tracker. Ein Entwickler liest den Bericht, sucht die Ursache und schickt eine Korrektur ein. Genau diese echten Fehlerberichte und die zugehörigen echten Korrekturen bilden die Grundlage der Aufgaben.
Beim Test bekommt das KI-System nur den Fehlerbericht und den Zustand des Projekts vor der Korrektur. Die Lösung des menschlichen Entwicklers bleibt verborgen. Das System muss sich durch tausende Dateien arbeiten und selbst entscheiden, wo es sucht. Am Ende liefert es eine Änderung ab, im Fachjargon ein Patch.
Danach lässt der Testrechner die Prüfprogramme des Projekts laufen. Bestimmte Tests müssen jetzt bestehen, die vorher fehlgeschlagen sind. Gleichzeitig darf kein bisher funktionierender Test kaputtgehen. Nur wenn beides zutrifft, zählt die Aufgabe als gelöst. Teillösungen oder gut gemeinte Ansätze bringen keine Punkte.
SWE-Pro in Produktankündigungen und Ranglisten
Begegnen wird dir der Begriff vor allem in Meldungen über neue Sprachmodelle. Wenn ein Anbieter ein Modell vorstellt, zeigt er meist ein Balkendiagramm mit Benchmark-Ergebnissen. Werte aus der SWE-Familie stehen dort inzwischen ganz vorn, weil Programmierhilfen ein großer Markt sind. Auch Börsenberichte greifen solche Zahlen auf, wenn sie den Vorsprung eines Unternehmens begründen wollen.
Indirekt begegnest du dem Test in Werkzeugen, die Entwickler täglich nutzen. Programme, die Code vorschlagen oder Fehler selbst beheben, werden an solchen Benchmarks abgestimmt. Verbessert sich ein Modell im Test, merkt man das oft in der Praxis. Ein Zusammenhang ist es aber nur, keine Garantie.
Ein häufiger Irrtum ist, die Prozentzahl als Maß für Menschenersatz zu lesen. Der Test misst eng umrissene Reparaturaufgaben mit klarer Erfolgsprüfung. Ein Team zu beraten, eine Architektur zu entwerfen oder eine ungenaue Anforderung zu klären, kommt darin nicht vor. Ein zweites Problem heißt Kontamination: Wenn die Aufgaben schon im Trainingsmaterial des Modells standen, kennt es die Lösung womöglich auswendig. Deshalb bauen neuere Benchmarks bewusst Aufgaben ein, die jünger sind als das Training.