„Überzeugend und selbstsicher falsch“: Die Grenze von OpenAIs Coding-Agenten

OpenAI-Feldbericht: Coding-Agenten machen marode Forschungssoftware bis zu 60-mal schneller, doch die Prüfarbeit landet weiter bei Menschen.

Eine Bibliothek zur RNA-Qualitätskontrolle brauchte für einen Datensatz früher fast sechzehn Stunden. Mit einer von Coding-Agenten neu geschriebenen Version dauert derselbe Lauf knapp fünfzehn Minuten. Diese Zahl steht in einem neuen Feldbericht von OpenAI und akademischen Partnern, der acht Fallstudien aus der biologischen Forschung dokumentiert, wie The Decoder berichtet.

Der Bericht ist kein unabhängiges Audit, sondern eine Sammlung von Selbstauskünften der beteiligten Forschenden, die mit Codex und teils zusätzlich mit Anthropics Claude Code gearbeitet haben. Genau das macht ihn interessant: Er zeigt nicht nur, was Agenten können, sondern auch, wo Forschende ihnen bewusst nicht vertrauen. Viele der betroffenen Werkzeuge entstanden ursprünglich als Beiwerk zu einem einzelnen Fachartikel, geschrieben von kleinen Teams ohne Budget für Wartung. Genau diese Lücke will der Bericht adressieren.

Wo Agenten wirklich Zeit sparen

Die Beschleunigungen sind konkret und teils drastisch. RustQC bündelte 15 einzelne Qualitätskontroll-Tools und beschleunigte die Verarbeitung um mehr als das 60-Fache, so AI News. HelixForge, ein GPU-Nachbau des Mutationssimulators BAMSurgeon, lief in einem Testlauf mit echten menschlichen Daten rund 59,6-mal schneller als das Original, beim eigentlichen Rechenschritt sogar um das 98,6-Fache.

Kleinere, aber ökonomisch relevante Gewinne gab es bei hifiasm mit etwa 15 Prozent und bei HI.SIM mit rund 31 Prozent Laufzeitreduktion bei unverändertem Ergebnis. Auch reine Wartungsarbeit gehörte dazu: cyvcf2 bekam ein modernisiertes Build-System, MHCflurry wurde von der veralteten Basis TensorFlow auf PyTorch migriert, immerhin rund 10.000 Codezeilen. Bei rustar-aligner, einer Neuentwicklung des verbreiteten, aber unzureichend gepflegten Alignierungstools STAR, stimmten die Ergebnisse in mehr als 99,8 Prozent der Testfälle mit dem Original überein.

Fehler, die kein Benchmark findet

Die Fallstudie zum Statistikpaket bayesm zeigt, warum reine Geschwindigkeit nicht reicht. Die Rust-Neufassung rechnete zwei- bis zwanzigmal schneller, enthielt aber zunächst einen Fehler, bei dem eine zentrale Steuergröße genau verkehrt herum eingesetzt war, laut The Decoder. Ein zweiter, unabhängiger Fehler fiel erst auf, als die Forschenden das Programm mit Tausenden künstlich erzeugten Datensätzen mit bekanntem Ergebnis konfrontierten. Ein verwandtes Verfahren namens HART lieferte ebenfalls plausible Zahlen, enthielt aber unnötig aufwendige Rechenwege und einen falsch skalierten Korrekturfaktor.

RustQC-Verantwortlicher Philip Ewels beschreibt Agenten als „wortgewandt, überzeugend und selbstsicher falsch“ und sagt, er habe die Modelle nie selbst über die Korrektheit ihrer Arbeit entscheiden lassen, sondern einen unabhängigen Testaufbau gebaut. Auch cyvcf2-Entwickler Brent Pedersen betont, dass es fachliches Urteilsvermögen brauche, um in der Wissenschaft „weit zu kommen“. Ein früherer Versuch, MHCflurry auf PyTorch zu übertragen, war Anfang 2025 gescheitert; Entwickler Sergey Feldman verortet die Ursache rückblickend in den damaligen Modellen, nicht in der Idee selbst.

Wer die Software danach betreut

Damit verschiebt sich der Engpass laut Bericht von der Implementierung zur Validierung und zur Frage, wer ein neu geschriebenes Werkzeug langfristig pflegt. Changes an MHCflurry und cyvcf2 flossen zurück in die Originalprojekte, rustar-aligner wechselte unter das Dach des Forschungsverbunds scverse, weil das ersetzte Tool STAR nicht mehr aktiv gepflegt wurde.

Bei FastQC lehnte der Originalautor eine Rust-Ersetzung ab, die gefundenen Verbesserungen flossen stattdessen in die bestehende Java-Version ein und brachten dort dieselbe dreifache Beschleunigung. Die Autoren warnen ausdrücklich davor, billige Neuentwicklungen ohne geklärte Zuständigkeit zu veröffentlichen, weil das Nutzergemeinschaften spalten und Ergebnisse zwischen Laboren unvergleichbar machen kann.

Business Punk Check

Fakt ist: Die im Bericht genannten Beschleunigungsfaktoren, etwa das 60-Fache bei RustQC, stammen aus Selbstauskünften einzelner Projektteams, nicht aus einer unabhängigen Studie.

Interpretation: Der eigentliche Wert liegt weniger in der reinen Rechenleistung als in der Erkenntnis, dass Prüfaufwand die eingesparte Entwicklungszeit teilweise zurückholt. Offen bleibt, ob Forschungsinstitutionen die nötige Governance für Validierung und Langzeitpflege aufbauen, bevor der nächste Agenten-Rebuild live geht.

Auf einen Blick

• Ein OpenAI-Feldbericht dokumentiert acht Fallstudien, in denen Coding-Agenten wie Codex veraltete Forschungssoftware modernisierten.
• RustQC lief nach dem Umbau mehr als 60-mal schneller, HelixForge erreichte rund das 59,6-Fache gegenüber dem Original.
• Bei bayesm blieben zwei Berechnungsfehler zunächst unentdeckt und wurden erst durch aufwendige Tests mit simulierten Daten sichtbar.
• Die Autoren sehen den Engpass inzwischen bei Validierung und Langzeitpflege statt bei der reinen Programmierung.

Quellen: AI News, The Decoder