In vielen Laboren läuft Forschung auf Software, die einmal für ein einzelnes Paper geschrieben wurde und dann jahrelang weitergetragen wird. Genau dort setzen KI-Coding-Agenten an: Sie können Abhängigkeiten erneuern, Programmiersprachen wechseln und Rechenwege beschleunigen. Ein neuer Feldbericht mit acht Fallstudien zeigt aber auch die unbequemere Seite: Je schneller ein Agent Code schreibt, desto wichtiger wird die Frage, ob dessen Ergebnis wissenschaftlich noch dasselbe bedeutet.
Das ist keine Kleinigkeit für Spezialisten. Wenn ein Programm Genomdaten auswertet oder statistische Modelle berechnet, kann ein kaum sichtbarer Fehler plausible Resultate liefern und trotzdem eine falsche Schlussfolgerung begünstigen. Die produktive Arbeitsteilung lautet deshalb nicht Mensch gegen Maschine, sondern: Menschen definieren, was gelten muss; Agenten setzen viel davon um.
Das Wichtigste in Kürze
- Der Feldbericht dokumentiert acht Projekte, von kleinen Wartungsarbeiten bis zu kompletten Neuentwicklungen wissenschaftlicher Werkzeuge.
- Bei RustQC sank die gemeldete Laufzeit eines Qualitätskontroll-Workflows von 15 Stunden 34 Minuten auf 14 Minuten 54 Sekunden.
- Die Fallstudien sind keine repräsentative Vergleichsstudie; ihre Kennzahlen stammen jeweils von den beteiligten Projektgruppen.
- Tests, Referenzdaten und fachliche Interpretation bleiben der entscheidende Schutz gegen unauffällige Fehler.
Warum Forschungssoftware so schwer zu ersetzen ist
Forschungssoftware ist oft zugleich Werkzeug und Methode. Ein Aligner für RNA-Sequenzdaten, ein Statistikpaket oder eine Pipeline zur Qualitätskontrolle verkörpert zahlreiche Annahmen: Welche Eingaben werden akzeptiert? Wie werden Grenzfälle behandelt? Welche Rundung ist zulässig? Wird ein solches Programm modernisiert, geht es nicht nur um lesbareren Code. Es geht darum, diese stillen Entscheidungen zu bewahren oder bewusst zu ändern.
Der OpenAI-Bericht beschreibt genau dieses Umfeld als eine Mischung aus technischem Schuldenstand und knapper dauerhafter Pflege. In einer Fallstudie wurde ein nicht mehr aktiv gepflegter RNA-Seq-Aligner mit mehr als 20.000 Zeilen C und C++ in Rust neu umgesetzt. Bei 10.000 Hefe-Reads stimmten die gemessenen Ergebnisse weitgehend mit dem Vorgänger überein. Das ist ein starkes Resultat, aber kein Freifahrtschein: Solche Übereinstimmung gilt immer nur für die gewählten Daten, Kennzahlen und Toleranzen.
Dass Software in der Wissenschaft selbst zum Flaschenhals werden kann, zeigt auch eine im Juni veröffentlichte Nature-Arbeit. Ihr System ERA erzeugte für klar bewertbare Aufgaben wissenschaftliche Software und erzielte in mehreren Bereichen starke Resultate. Der gemeinsame Nenner ist nicht magisches Programmieren, sondern ein messbares Qualitätsziel, gegen das Varianten geprüft werden können.
Tempo ist nur dann nützlich, wenn es prüfbar bleibt
Besonders eindrucksvoll ist RustQC. Die Fallstudie bündelte 15 Qualitätskontroll-Werkzeuge für RNA-Sequenzdaten in einem Programm und berichtete für einen großen Datensatz eine Beschleunigung um mehr als das 60-Fache. Neben der Zeit sank auch der gemeldete Datentransfer deutlich. Solche Verbesserungen sind in der Bioinformatik relevant, weil teure Rechenzeit und lange Warteschlangen ganze Forschungsabläufe ausbremsen können.
Die Zahl sollte trotzdem nicht als allgemeines Versprechen für KI-Agenten gelesen werden. Der Bericht sammelt frühe, unterschiedliche Projekte und lässt die Autorinnen und Autoren der Fallstudien für ihre Kennzahlen einstehen. Er reproduziert nicht jeden Benchmark unabhängig. Gerade diese Offenheit ist wertvoll: Sie trennt ein beobachtetes Projektergebnis von einer pauschalen Aussage wie „Agenten machen Forschung 60-mal schneller“.
Auch außerhalb dieser Fälle spricht die Forschung für eine nüchterne Lesart. Ein Bericht der University of California, Berkeley, beschreibt Testumgebungen, Compiler, Test-Suites und Programmanalysen als zentrale Rückkopplung für Coding-Agenten. Zugleich dokumentiert er typische Fehlmuster auf schwierigen Aufgaben, etwa Abkürzungen, die nur für einzelne Eingaben funktionieren. Wer die Diskussion um Benchmarks verfolgt hat, kennt die Grundidee bereits aus unserem Beitrag über die Grenzen eines einzelnen KI-Benchmarks: Ein hoher Wert ersetzt keine passende Prüfung.
Die neue Rolle der Forschenden: Prüfen, nicht nur prompten
In den meisten Fällen des Feldberichts lag die menschliche Arbeit nicht am Ende als formales Abhaken. Sie begann vorher. Teams legten Referenzdaten fest, bauten Test-Harnesses, verglichen Ausgaben und untersuchten Abweichungen. Bei größeren Umbauten reichen einfache Gleichheitstests oft nicht. Dann braucht es künstliche Daten mit bekanntem Ergebnis, realistische Arbeitslasten und Kriterien, die vor Beginn der Auswertung feststehen.
Das verschiebt die knappe Expertise. Statt jede Zeile selbst zu schreiben, müssen Forschende genauer formulieren, welches wissenschaftliche Verhalten erhalten bleiben soll. Sie müssen entscheiden, wann eine Abweichung ein Fehler, ein zulässiger Unterschied oder sogar eine Verbesserung ist. Ein Agent kann diese Entscheidung vorbereiten, aber nicht glaubwürdig aus seinem eigenen Erfolgssignal ableiten.
Für Forschungsteams folgt daraus eine praktische Reihenfolge: erst ein prüfbares Ziel und repräsentative Daten, dann kleine Änderungen, danach unabhängige Auswertung. Große Neuschreibungen sollten zusätzlich mit den ursprünglichen Maintainerinnen und Maintainern abgestimmt werden. Sonst entstehen schnell zwei ähnliche Werkzeuge, aber keine gemeinsame Verantwortung für Updates, Fehler und Nutzerinnen.
Ausblick: Der Engpass wandert von Code zu Vertrauen
KI-Agenten könnten endlich Kapazität für die lange vernachlässigte Wartung wissenschaftlicher Programme schaffen. Das wäre ein echter Gewinn, nicht nur für schnellere Rechner, sondern für nachvollziehbarere Forschung. Doch die Qualitätskontrolle wächst mit dem Umfang der Änderung. Je autonomer der Umbau, desto sorgfältiger müssen Vergleichsdaten, Akzeptanzkriterien und Verantwortlichkeiten sein.
Die interessante Zukunftsfrage lautet daher nicht, ob ein Agent einen alten Codebestand neu schreiben kann. Immer häufiger kann er das. Entscheidend ist, ob ein Team nachweisen kann, dass die neue Software unter realen Bedingungen das Richtige tut und dauerhaft gepflegt wird. Erst dann wird aus einer beeindruckenden Demo belastbare Forschungsinfrastruktur.