KI-Agenten erledigen zunehmend Wartung und Neuimplementierung in Forschungssoftware – Prüf- und Pflegeaufwand steigt.
In Kürze
- Agenten portieren, optimieren und schreiben Tools neu.
- Subtile Fehler erfordern umfangreiche Tests.
- Langfristige Verantwortung und Pflege bleiben ungelöst.
KI-Agenten übernehmen in Laborrechnern immer öfter eintönige Programmierarbeit — und verschieben den Engpass: weg vom Coden, hin zu Prüfen, Validieren und langfristiger Pflege.
Was genau passiert?
Wissenschaftliche Software ist häufig Nebenprodukt einzelner Papers: kleine Repositoires, dürftig getestet, aber zentral für Experimente. Ein Feldbericht von OpenAI und akademischen Partnern fasst acht Fallstudien (vorwiegend aus der Biologie) zusammen, in denen Coding‑Agenten wie Codex, Claude Code oder neuere GPT‑Modelle Wartung, Optimierungen und komplette Neuimplementierungen übernahmen.
Konkrete Fälle
- cyvcf2 (Python‑Bibliothek zum Lesen genetischer Daten): GPT‑5.5 ersetzte eine veraltete Build‑/Install‑Routine durch ein moderneres Verfahren.
- MHCflurry (Immunforschung): Zwei Agenten agierten abwechselnd als Entwickler und Prüfer und portierten rund 10.000 Codezeilen von TensorFlow auf PyTorch.
- rustar‑aligner: Das 20.000‑Zeilen‑Tool STAR (C/C++) wurde komplett in Rust neu geschrieben; Tests mit 10.000 kurzen Hefezell‑Abschnitten zeigten eine Übereinstimmung von 99,815 % bzw. 99,883 % mit dem Original.
- RustQC: 15 einzelne Qualitätskontrollen wurden zu einem Programm zusammengefasst; die Laufzeit auf einem großen Datensatz sank von 15 Stunden 34 Minuten auf 14 Minuten 54 Sekunden — also mehr als 60‑mal schneller.
- HelixForge: Ein herkömmliches Werkzeug wurde durch eine GPU‑basierte Version ersetzt; bei einem Test mit einem 10‑Millionen‑Basen‑Abschnitt war die neue Version insgesamt 59,6‑mal schneller, der reine Rechenschritt sogar 98,6‑mal.
Schnell, aber nicht perfekt
Agenten erledigen klar abgegrenzte Aufgaben sehr schnell, treten dabei oft selbstsicher auf und können subtile Fehler einbauen, deren wissenschaftliche Relevanz sie nicht selbst bewerten können. Beispiele aus dem Bericht: Bei der Rust‑Neuimplementierung des Statistikpakets bayesm waren zwei erweiterte Verfahren zunächst fehlerhaft — etwa weil eine Steuergröße als Kehrwert benutzt oder Berechnungsabläufe falsch umgesetzt wurden. Solche Probleme traten erst bei aufwändigen Tests mit vielen synthetischen Datensätzen zutage. Frühe Versuche, etwa eine erste MHCflurry‑Portierung Anfang 2025, scheiterten teilweise, weil die damals eingesetzten Modelle schlicht noch nicht zuverlässig genug generierten.
Neue Arbeitsteilung zwischen Mensch und Agent
Die Studienautoren beobachten ein Muster: Menschen setzen Ziele, definieren Erfolgskriterien und bauen Prüfverfahren auf; Agenten implementieren. Für hifiasm etwa baute ein Forschender einen separaten Testaufbau, auf dessen Grundlage GPT‑5.5 Verbesserungen fand, die die Laufzeit an realen Daten um circa 15 % reduzierten. Bei HI.SIM senkte ein Agent die Laufzeit um etwa 31 % bei gleichbleibendem Ergebnis. Manche Projekte benötigten dabei kaum menschliches Eingreifen, andere intensive Kontrolle.
Ökonomische und organisatorische Fragen
Die Autoren kalkulieren Einsparpotenziale: Helfen Agenten bei 25–50 % der Installationsprobleme, könnten 100 Paket‑Modernisierungen zwischen rund 600.000 und knapp 5 Millionen US‑Dollar an Forschungszeit einsparen. Für NumPy schätzen sie etwa 650 Wartungsstunden pro Jahr. Offene Fragen bleiben: Wer trägt die langfristige Pflege? Billig neuemodellierte Werkzeuge können Nutzergruppen spalten und erfahrene Betreuer weiter ausdünnen.
Wie Projekte damit umgehen
Die Praxis war unterschiedlich: Manche Änderungen fanden ihren Weg in die Originalprojekte; rustar‑aligner wurde zu scverse übernommen, weil das Original unbetreut war. Beim FastQC‑Fall lehnte der ursprüngliche Autor eine Ersatzversion ab; die Verbesserungen flossen stattdessen in die bestehende Java‑Version. Andere Projekte sahen sich mit einer Flut unbrauchbarer Bugmeldungen konfrontiert — das curl‑Projekt meldete viele nutzlose KI‑Hinweise und stellte sein Bug‑Bounty‑Programm ein.
Einschränkungen des Berichts
Der Bericht basiert retrospektiv auf Selbstauskünften und ist nicht repräsentativ. Dennoch zeichnet er ein klares Muster: Der Engpass verschiebt sich von reiner Implementierung hin zu Validierung, wissenschaftlicher Prüfung und Verantwortlichkeit für langfristige Pflege. Das korrespondiert mit anderen Untersuchungen (etwa METR), wonach viele Lösungen, die Benchmarks bestehen, von Projektverantwortlichen trotzdem abgelehnt würden; Entwicklerteams berichten häufig, dass eingesparte Entwicklungszeit als zusätzliche Prüfzeit zurückkommt.
OpenAI‑Kontext
Der Bericht ist Teil einer größeren Wissenschaftsstrategie: OpenAI baut Teams für Biowissenschaften auf, veröffentlichte das Modell GPT‑Rosalind und ein Life‑Sciences‑Plugin für Codex, das Zugriff auf über 50 öffentliche Datenbanken und Werkzeuge bietet. OpenAI erwartet, dass 2026 für die Wissenschaft eine ähnliche Rolle spielen könnte wie 2025 für die Softwareentwicklung.
Quellen
- Quelle: OpenAI
- Der ursprüngliche Artikel wurde hier veröffentlicht
- Dieser Artikel wurde im Podcast KI-Briefing-Daily behandelt. Die Folge kannst du hier anhören.
