Sztuczna inteligencja a inżynieria oprogramowania: mapa drogowa do autonomicznego rozwoju

Wizja, w której sztuczna inteligencja (AI) samodzielnie przejmuje żmudne zadania związane z inżynierią oprogramowania – od refaktoryzacji kodu, przez migracje systemów, po wyszukiwanie błędów współbieżności – staje się coraz bardziej realna. Pozwoliłoby to inżynierom oprogramowania skupić się na architekturze, projektowaniu i rozwiązywaniu problemów, które wciąż wykraczają poza możliwości maszyn. Jednakże, jak wskazują najnowsze badania naukowców z Laboratorium Informatyki i Sztucznej Inteligencji MIT (CSAIL) oraz kilku innych instytucji, droga do tej przyszłości wymaga szczegółowego spojrzenia na obecne wyzwania.

Wizje kontra rzeczywistość: nie tylko generowanie kodu

Badania, opublikowane w pracy zatytułowanej „Challenges and Paths Towards AI for Software Engineering”, mapują szeroki zakres zadań inżynierii oprogramowania wykraczających poza samo generowanie kodu. Identyfikują także bieżące „wąskie gardła” i wskazują kierunki badań, które mają je przezwyciężyć. Celem jest umożliwienie ludziom koncentracji na projektowaniu wysokiego poziomu, podczas gdy rutynowe prace zostaną zautomatyzowane.

Armando Solar-Lezama, profesor elektrotechniki i informatyki MIT oraz główny badacz CSAIL, zauważa, że „wielu mówi o tym, że programiści przestaną być potrzebni, ze względu na dostępną automatyzację”. Podkreśla jednak, że choć postęp w tej dziedzinie jest ogromny, a dostępne narzędzia są bezprecedensowo potężne, „wciąż długa droga dzieli nas od pełnej obietnicy automatyzacji, której byśmy oczekiwali”.

Solar-Lezama krytykuje powszechne narracje sprowadzające inżynierię oprogramowania do „części programowania dla studentów pierwszego roku: ktoś daje ci specyfikację małej funkcji do zaimplementowania, albo rozwiązujesz zadania w stylu LeetCode”. W praktyce inżynieria oprogramowania jest znacznie szersza. Obejmuje codzienne refaktoryzacje poprawiające projekt, jak również szeroko zakrojone migracje milionów linii kodu z COBOL-a na Javę, co potrafi przekształcać całe przedsiębiorstwa. Wymaga ciągłego testowania i analizy – od fuzzingu, po testy oparte na właściwościach – aby wyłapać błędy współbieżności czy załatać zero-day exploity. To także utrzymanie i dokumentowanie kodu sprzed dziesięcioleci, podsumowywanie historii zmian dla nowych członków zespołu i przeglądanie pull requestów pod kątem stylu, wydajności i bezpieczeństwa.

Bariery w ocenie postępów i komunikacji człowiek-AI

Optymalizacja kodu na skalę przemysłową – jak np. ponowna regulacja jąder GPU czy wielowarstwowe udoskonalenia stojące za silnikiem Chrome’a V8 – pozostaje niezwykle trudna do oceny. Obecne mierniki wydajności zostały zaprojektowane do krótkich, samoistnych problemów. Choć testy wielokrotnego wyboru dominują w badaniach nad językiem naturalnym, nigdy nie były normą w dziedzinie AI dla kodu. Przemysłowym standardem stał się SWE-Bench, który polega na załataniu przez model problemu z GitHub Issues. Choć użyteczny, nadal przypomina „ćwiczenie programistyczne dla studenta”. Dotyczy zaledwie kilkuset linii kodu, niesie ryzyko wycieku danych z publicznych repozytoriów i ignoruje inne konteksty świata rzeczywistego – takie jak refaktoryzacja wspomagana AI, programowanie w parach człowiek-AI czy krytyczne dla wydajności przepisania milionów linii kodu. Dopóki benchmarki nie zostaną rozszerzone o te bardziej wymagające scenariusze, pomiar postępu – a tym samym jego przyspieszanie – pozostanie otwartym wyzwaniem.

Jeśli pomiar jest jedną przeszkodą, komunikacja człowiek-maszyna jest kolejną. Alex Gu, student MIT i pierwszy autor pracy, opisuje obecną interakcję jako „cienka linię komunikacji”. Kiedy prosi system o wygenerowanie kodu, często otrzymuje duży, nieustrukturyzowany plik, a nawet zestaw testów jednostkowych, które jednak są powierzchowne. Ta luka rozciąga się na zdolność AI do skutecznego wykorzystania szerszego zestawu narzędzi inżynierii oprogramowania, od debuggerów po statyczne analizatory, na których polegają ludzie w celu precyzyjnej kontroli i głębszego zrozumienia. „Naprawdę nie mam zbyt dużej kontroli nad tym, co model pisze,” mówi Gu. „Bez kanału, przez który AI mogłaby wyrazić swoją pewność – 'ta część jest poprawna… tę część, może sprawdź ponownie’ – deweloperzy ryzykują ślepe zaufanie do halucynowanych logik, które kompilują się, ale załamują się w produkcji. Kolejnym krytycznym aspektem jest to, aby AI wiedziała, kiedy odwołać się do użytkownika w celu wyjaśnienia.”

Bariery skalowalności i „halucynacje” modeli

Skala problemów potęguje te trudności. Obecne modele AI zmagają się z obsługą dużych baz kodu, często obejmujących miliony linii. Modele fundacyjne uczą się na podstawie publicznych repozytoriów GitHub, ale „baza kodu każdej firmy jest w pewnym sensie inna i unikalna”, jak zauważa Gu. Oznacza to, że zastrzeżone konwencje kodowania i wymagania specyfikacji są fundamentalnie poza rozkładem danych, na których trenowano modele. Rezultatem jest kod, który wygląda wiarygodnie, ale wywołuje nieistniejące funkcje, narusza wewnętrzne zasady stylu lub zawodzi w potokach ciągłej integracji.

Często prowadzi to do generowanego przez AI kodu, który „halucynuje”, co oznacza, że tworzy treści, które wyglądają wiarygodnie, ale nie są zgodne ze specyficznymi wewnętrznymi konwencjami, funkcjami pomocniczymi lub wzorcami architektonicznymi danej firmy. Modele często również niepoprawnie wyszukują, ponieważ pobierają kod o podobnej nazwie (składni), a nie funkcjonalności i logice – co jest potrzebne modelowi, aby wiedzieć, jak napisać funkcję. „Standardowe techniki wyszukiwania są bardzo ŁATWO OSZUKANE przez fragmenty kodu, które robią to samo, ale wyglądają inaczej,” mówi Solar-Lezama.

Droga naprzód: wspólne wysiłki i amplifikacja ludzkich możliwości

Autorzy sugerują, że ponieważ nie ma „srebrnej kuli” na te problemy, konieczne są wspólne wysiłki społeczności: bogatsze dane, które uchwycą proces pisania kodu przez deweloperów (np. który kod deweloperzy zachowują, a który odrzucają, jak kod jest refaktoryzowany z czasem), wspólne zestawy ocen mierzące postępy w jakości refaktoryzacji, długowieczności poprawek błędów i poprawności migracji. Ważne są także przejrzyste narzędzia, które pozwolą modelom ujawniać niepewność i zapraszać do ludzkiego sterowania, zamiast biernej akceptacji.

Gu określa agendę jako „wezwanie do działania” na rzecz większych, otwartych współprac, których żadne pojedyncze laboratorium nie byłoby w stanie podjąć samodzielnie. Solar-Lezama przewiduje stopniowe postępy – „wyniki badań 'uszczypujące’ każde z tych wyzwań osobno” – które zasilą narzędzia komercyjne i stopniowo przesuną AI od roli asystenta autouzupełniania do prawdziwego partnera inżynieryjnego.

„Dlaczego to wszystko ma znaczenie? Oprogramowanie już dziś stanowi podstawę finansów, transportu, opieki zdrowotnej i codziennego życia, a ludzki wysiłek wymagany do jego bezpiecznego budowania i utrzymania staje się wąskim gardłem. AI, która mogłaby przejąć żmudną pracę – i robić to bez wprowadzania ukrytych błędów – uwolniłaby deweloperów, aby mogli skupić się na kreatywności, strategii i etyce,” mówi Gu. „Ale ta przyszłość zależy od uznania, że uzupełnianie kodu to łatwa część; trudna część to wszystko inne. Naszym celem nie jest zastępowanie programistów. To ich wzmacnianie. Kiedy AI będzie mogła zająć się tym, co żmudne i przerażające, ludzcy inżynierowie będą wreszcie mogli poświęcić swój czas na to, co potrafią tylko ludzie.”

Baptiste Rozière, naukowiec AI w Mistral AI, który nie był zaangażowany w tworzenie tej pracy, podkreśla, że „przy tak wielu nowych pracach pojawiających się w AI dla kodowania, i społeczności często ścigającej najnowsze trendy, może być trudno cofnąć się i zastanowić, które problemy są najważniejsze do rozwiązania. Cieszyłem się z czytania tej pracy, ponieważ oferuje ona jasny przegląd kluczowych zadań i wyzwań w AI dla inżynierii oprogramowania. Przedstawia również obiecujące kierunki dla przyszłych badań w tej dziedzinie.”

Gu i Solar-Lezama napisali tę pracę wspólnie z profesorem Koushikiem Senem i doktorantami Namanem Jainem i Manishiem Shetty z University of California w Berkeley, asystentem profesorem Kevinem Ellisem i doktorantem Wen-Dingiem Li z Cornell University, asystentem profesorem Diyi Yangiem i doktorantem Yijia Shao ze Stanford University oraz przyszłym asystentem profesorem Ziyangiem Li z Johns Hopkins University. Ich praca została częściowo sfinansowana przez National Science Foundation (NSF), sponsorów przemysłowych i stowarzyszonych SKY Lab, Intel Corp. poprzez grant NSF oraz Office of Naval Research. Badacze przedstawiają swoją pracę na Międzynarodowej Konferencji Uczenia Maszynowego (ICML).