OpenAI opublikowało w 2025 roku raport dokumentujący osiem projektów obliczeniowych, w których agenty kodujące skróciły czas działania programów nawet o 31 procent — bez zmiany wyników obliczeń. To nie jest historia o zastępowaniu naukowców; to historia o tym, że dekady zaległości technicznych w akademickim oprogramowaniu mogą być spłacone przez model językowy w czasie, na który żaden grant badawczy nie przewiduje budżetu. Redakcja IWD Partner patrzy na ten raport z mieszaniną uznania i ostrożności: dane są obiecujące, ale pochodzą od producenta testowanego narzędzia.
Czym jest dług techniczny w oprogramowaniu naukowym?
Dług techniczny to nagromadzone zaległości w jakości kodu — przestarzałe zależności, nieoprawione błędy wydajnościowe, porzucone systemy budowania — które powstają, gdy oprogramowanie rośnie szybciej niż zasoby przeznaczone na jego utrzymanie. W środowisku akademickim problem ten jest szczególnie dotkliwy: narzędzie budowane przez doktoranta na potrzeby jednej publikacji rzadko kiedy trafia później pod opiekę dedykowanego inżyniera.
Raport OpenAI z 2025 roku precyzyjnie opisuje tę patologię. Narzędzia genomiczne, statystyczne czy immunologiczne pisane są przez specjalistów dziedzinowych — biologów, statystyków, bioinformatyków — którzy dysponują głęboką wiedzą merytoryczną, ale często ograniczonymi zasobami inżynieryjnymi. Efektem jest kod, który działa, lecz nie jest optymalizowany, a z każdym rokiem staje się trudniejszy do utrzymania.
Skala tego zjawiska jest trudna do oszacowania liczbowo, jednak badania takie jak te dokumentowane przez Software Sustainability Institute w Wielkiej Brytanii wskazują, że zdecydowana większość oprogramowania naukowego nie posiada żadnego planu długoterminowego utrzymania. Raport OpenAI próbuje odpowiedzieć na pytanie, czy agenty AI mogą stać się tym brakującym zasobem inżynieryjnym.
Jak działały agenty kodujące w projektach naukowych?
Agenty kodujące — w tym przypadku przede wszystkim Codex oraz, w trzech na osiem projektów, kombinacja Codex z Claude Code firmy Anthropic — wykonywały zadania z trzech głównych kategorii: porządkowanie systemów pakowania i budowania, optymalizacja wydajności istniejącego kodu oraz pełne przepisanie komponentów do nowego języka lub frameworka.
Optymalizacja wydajności: HI.SIM i Hifiasm
Najbardziej mierzalne efekty odnotowano w projektach genomicznych. HI.SIM — symulator odczytów sekwencjonowania DNA — przeszedł dwa autonomiczne przejścia optymalizacyjne wykonane przez modele GPT-5.2 i GPT-5.6. Contributor Andrew Ho poinformował, że runtime skrócił się o 31 procent na reprezentatywnym zestawie testowym bez żadnej zmiany w wynikach obliczeń. Ho, który otwarcie przyznał, że nie jest ani specjalistą od genomiki, ani programistą C, nazwał efekt „niczym innym jak magicznym” z perspektywy użytkownika końcowego.
Hifiasm, narzędzie do składania genomów z odczytów PacBio HiFi, uzyskało 25-procentowe skrócenie czasu działania na docelowym zadaniu optymalizacyjnym i około 15 procent na osobnym zestawie danych sekwencjonowania ludzkiego. Contributor Suyash Shringarpure opisał agenta jako zdolnego do samodzielnego ustawiania infrastruktury benchmarkingowej i proponowania kandydatów optymalizacyjnych — zaznaczył jednak, że dostarczanie wyników profilowania i korygowanie modelu, gdy wpadał w pętle błędów, pozostawało pracą wykonywaną wyłącznie przez człowieka.
Migracja frameworków: MHCflurry
MHCflurry to narzędzie do przewidywania fragmentów białkowych prezentowanych limfocytom T, kluczowe w badaniach immunologicznych. Jego backend oparty na TensorFlow i Keras został przeniesiony do PyTorch przy zachowaniu kompatybilności z wcześniej opublikowanymi wagami modelu. Contributorzy Alex Rubinsteyn, Sergej Feldman i Timothy O’Donnell określili ten rodzaj pracy jako „nieglamurowe, pracochłonne utrzymanie”, które decyduje o tym, czy projekt open-source przeżywa, czy powoli obumiera.
Porządkowanie systemu budowania: cyvcf2
Biblioteka Pythona cyvcf2, służąca do odczytu plików wariantów genomicznych, miała przestarzały system budowania zastąpiony nowocześniejszym, ujednoliconym procesem. Contributor Brent Pedersen sformułował ważne zastrzeżenie: szybkość z agentami jest jedną sprawą, ale dalsze postępy w nauce wymagają „eksperckiego prowadzenia, rozumienia, smaku i staranności”. To zdanie warto zapamiętać jako ramę interpretacyjną dla całego raportu.
Redakcja IWD Partner: Patrzymy na te wyniki jak na pierwszy rozdział historii, której zakończenie jest jeszcze nieznane. Analogia, która przychodzi nam do głowy, to pojawienie się kompilatorów optymalizujących w latach 80. — nikt nie twierdził wtedy, że zastąpią architektów systemów, ale każdy przyznawał, że zmieniają proporcje między myśleniem a kodowaniem. Pytanie, które raport OpenAI pozostawia bez odpowiedzi, brzmi: co stanie się z kompetencjami inżynieryjnymi w środowiskach badawczych, jeśli przez dekadę te zadania będą delegowane do modeli? Czy naukowcy utrzymają zdolność do oceny, kiedy agent po prostu się myli?
Co mówią liczby o granicach automatyzacji?
Raport OpenAI dokumentuje nie tylko sukcesy, ale i strukturalne ograniczenia widoczne w każdym z ośmiu przypadków. Żaden z projektów nie działał w pełni autonomicznie — każdy wymagał aktywnego nadzoru człowieka na co najmniej jednym krytycznym etapie. Szringarpure przy Hifiasm musiał kierować modelem z dala od powtarzających się trybów awarii; Ho przy HI.SIM był odpowiedzialny za walidację, że wyniki obliczeń pozostają niezmienione.
Projekt bayesm-rs — port statystycznych modeli Bayesowskich z pakietu R bayesm do języka Rust — osiągnął wyniki zgodne z oryginalnym oprogramowaniem w ramach z góry ustalonych tolerancji i uruchamiał się 2,3 do 2,7 razy szybciej. Rust jest językiem znacznie bardziej wymagającym systemu typów i zarządzania pamięcią niż Python czy R, co sprawia, że poprawność tego portu jest trudniejsza do zweryfikowania automatycznie — i tym bardziej wymaga eksperta dziedzinowego do oceny.
Warto podkreślić metodologiczne ograniczenie całego raportu: jest to dokument opublikowany przez OpenAI, oparty na studiach przypadku przygotowanych przez samych contributorów projektów. Brak niezależnej weryfikacji wyników nie dyskredytuje opisanych wzorców, ale nakazuje traktować konkretne liczby jako wstępne dane, a nie udowodnione benchmarki.
Dlaczego agenty kodujące w nauce mają znaczenie?
Opisane przypadki dotyczą narzędzi używanych w genomice, immunologii i statystyce bayesowskiej — dziedzinach, gdzie opóźnienia obliczeniowe bezpośrednio przekładają się na czas potrzebny do przeprowadzenia eksperymentów i publikacji wyników. 31-procentowe skrócenie runtime’u symulatora sekwencjonowania to nie abstrakcja: to konkretne godziny lub dni zaoszczędzone przy każdym uruchomieniu pipeline’u analitycznego.
Instytucje finansujące badania, takie jak National Institutes of Health (NIH) w Stanach Zjednoczonych czy European Research Council (ERC), przeznaczają środki na nowe odkrycia, nie na modernizację infrastruktury kodu. Jeśli według wstępnych danych z 2025 roku agenty AI mogą wykonywać tę pracę w ułamku czasu i przy minimalnym nadzorze człowieka, zmienia to równanie kosztowe dla całego sektora akademickiego.
Migracja MHCflurry z TensorFlow do PyTorch ma znaczenie wykraczające poza jeden projekt: PyTorch stał się dominującym frameworkiem w badaniach nad uczeniem maszynowym, a narzędzia oparte na starszych bibliotekach stopniowo tracą kompatybilność z nowymi ekosystemami. Tego rodzaju „nieglamurowa” praca utrzymuje żywotność projektów open-source, które inaczej zostałyby porzucone, choć ich algorytmy pozostają wartościowe.
Powiązane pojęcia z AI i uczenia maszynowego
- Agent kodujący — system AI zdolny do autonomicznego pisania, modyfikowania i testowania kodu źródłowego w celu realizacji zadanego celu inżynieryjnego.
- Dług techniczny — skumulowane koszty skrótów i kompromisów podjętych podczas tworzenia oprogramowania, które muszą zostać spłacone przez późniejsze refaktoryzacje lub powodują rosnące problemy z utrzymaniem.
- Profiling kodu — proces pomiaru, które fragmenty programu zużywają najwięcej czasu lub zasobów obliczeniowych, służący jako podstawa optymalizacji wydajności.
- Port językowy — przepisanie programu z jednego języka programowania do drugiego przy zachowaniu identycznej funkcjonalności i wyników obliczeń.
- Benchmark — standaryzowany test lub zestaw danych używany do porównywania wydajności różnych implementacji algorytmu lub wersji oprogramowania.
Na podstawie materiałów źródłowych.
