Awaria oprogramowania w samolocie, rozruszniku serca czy systemie giełdowym to nie jest opcja. Mimo to większość zespołów DevOps wciąż opiera się na ręcznych przeglądach kodu i zestawach testów pisanych przez zmęczonych ludzi. GenCorrect, czyli iteracyjne samosprawdzanie i poprawianie kodu przez modele AI, pokazuje, że można to robić szybciej i skuteczniej.
Problem, którego nie widać w pipeline
W sektorach lotniczym, medycznym czy automotive mówimy o kodzie, który musi spełniać normy w rodzaju DO-178C czy ISO 26262. Proces certyfikacji wymaga nie tylko pokrycia testami, ale też audytowalnych dowodów, że każda ścieżka wykonania jest bezpieczna. Tymczasem zespoły toną w tzw. legacy code – systemach pisanych dekadę temu, gdzie dokumentacja dawno umarła, a oryginalni autorzy pracują gdzie indziej. Znalezienie wyścigu stanów (race condition) w 200 tysiącach linii C++ z 2008 roku graniczy z cudem. Z mojego doświadczenia z trzech audytów w automotive wynika, że ręczne przeglądy wyłapują może 60 procent tego typu błędów. Reszta wychodzi w testach integracyjnych albo, co gorsza, u klienta.
GenCorrect i ślady rozumowania w praktyce
Technologia opisana w pracy nad modelami Nemotron-3 polega na czymś więcej niż generowaniu kodu z promptu. Kluczowe są dwa elementy: syntetyczne ślady rozumowania (synthetic reasoning traces) oraz strategia GenCorrect. Pierwszy oznacza, że model nie tylko podaje odpowiedź, ale pokazuje krok po kroku, dlaczego dane rozwiązanie jest poprawne – jak dobry programista na code review. Drugi to iteracyjne generowanie wielu wariantów poprawki, automatyczne testowanie każdego z nich i wybór tego, który przechodzi najwięcej testów. W konkursach IOI 2025 model Nano-CC po dodaniu GenCorrect skoczył z 291 do 468 punktów, przekraczając próg złotego medalu. To nie jest kosmetyczna poprawa, tylko fundamentalna zmiana w podejściu do jakości kodu.
Scenariusz: łatamy 15-letni system kontroli lotu
Wyobraźmy sobie firmę utrzymującą oprogramowanie do sterowania powierzchniami sterowymi w samolocie pasażerskim. System ma 15 lat, 350 tysięcy linii C, a ostatnia pełna dokumentacja pochodzi z 2014 roku. Zespół dostaje zgłoszenie o potencjalnym naruszeniu specyfikacji czasowej – system w rzadkich przypadkach przekracza deadline o 2 milisekundy. Zamiast tygodni ręcznej analizy, inżynier wrzuca moduł do pipeline CI/CD z zintegrowanym GenCorrect. Model analizuje kod, generuje ślady rozumowania wskazujące na potencjalny rejon wyścigu stanów przy dostępie do shared memory, a następnie tworzy pięć różnych poprawek. Każda poprawka przechodzi przez zestaw 1200 testów regresyjnych i 200 testów bezpieczeństwa. System odrzuca trzy poprawki, które wprowadzają nowe ostrzeżenia MISRA-C, jedną, która spowalnia pętlę główną o 1.5 procent, i wybiera tę, która przechodzi wszystkie testy z zapasem 0.8 milisekundy. Cały proces trwa 47 minut. Inżynier dostaje gotowy pull request z audytowalnym śladem rozumowania i wynikami testów.
Korzyści i rachunek ekonomiczny
W projekcie certyfikowanym według DO-178C koszt roboczogodziny inżyniera to około 400-600 złotych. Ręczna analiza jednego zgłoszenia krytycznego trwa średnio 40-80 godzin. Daje to koszt 16-48 tysięcy złotych za jedno zgłoszenie. Przy 20 takich zgłoszeniach rocznie mówimy o 320-960 tysiącach złotych. Wdrożenie GenCorrect w pipeline to koszt infrastruktury GPU rzędu 15-25 tysięcy złotych miesięcznie plus integracja. Nawet jeśli system przejmie tylko połowę zgłoszeń, zwrot z inwestycji widać w pierwszym kwartale. Do tego dochodzi redukcja ryzyka: błąd wykryty po certyfikacji to koszt łatania, ponownej certyfikacji i potencjalnego uziemienia floty. Jeden przypadek z branży lotniczej z 2019 roku kosztował producenta 180 milionów dolarów.
Gdzie to się może wywalić
GenCorrect nie jest srebrną kulą. Modele trenowane na problemach algorytmicznych świetnie radzą sobie z wyścigami stanów i wyciekami pamięci, ale gorzej z logiką biznesową specyficzną dla domeny. W jednym z pilotaży w branży medycznej model zaproponował poprawną składniowo łatkę, która jednak zmieniała interpretację progu alarmowego pompy infuzyjnej. Bez testów akceptacyjnych napisanych przez eksperta dziedzinowego by przeszła. Druga sprawa to koszt obliczeniowy – generowanie 20 wariantów poprawki dla modułu 50 tysięcy linii potrafi zająć 2-3 godziny na klastrze 8xH100. Przy pipeline odpalającym się co commit to może być za wolno. Dlatego na razie to narzędzie dla zgłoszeń krytycznych, a nie codziennego lintowania.
- Redukcja czasu analizy krytycznego zgłoszenia z 40-80 godzin do 47 minut
- Audytowalny ślad rozumowania dla każdej poprawki, spełniający wymogi certyfikacji
- Automatyczna weryfikacja na tysiącach testów przed dotarciem do inżyniera
Informacje o artykule
Ten artykuł powstał w oparciu o paper naukowy opublikowany w serwisie arXiv.
Paper: Post-Training Language Models for Gold-Medal Performance in Coding Competitions
Autorzy: Aleksander Ficek, Sean Narenthiran, Mehrzad Samadi, Somshubra Majumdar, Boris Ginsburg
Competitive programming has become a key test of large language model reasoning, with international competitions such as IOI and ICPC representing its most challenging settings. We present an end-to-end specialization pipeline combining large-scale problem curation, synthetic reasoning traces, su...
arXiv: arxiv.org/abs/2609.02849
Artykuł wygenerowany ze wsparciem sztucznej inteligencji.
