DOCUMENT_ID // AI w programowaniu: Realna wydajność czy wielka iluzja prędkości?

AI obiecuje 45% wzrostu wydajności, ale rzeczywistość bywa brutalna. Niezależne testy dowodzą, że generowany kod często wymaga kosztownych poprawek i wydłuża czas pracy. Czy warto ryzykować jakość projektu dla pozornej oszczędności?

AI w programowaniu: Realna wydajność czy wielka iluzja prędkości?

Jeśli przejrzymy posty na LinkedIn, pochwalne artykuły w prasie branżowej czy prezentowane głównie przez dostawców analizy odpowiedź wydaje się oczywista.

W 2024 roku SoftServe przeprowadził eksperyment obejmujący aż 1000 programistów z 7 krajów obejmujący 1500 zadań realizowanych zarówno z pomocą generatywnej sztucznej inteligencji (GPT-3.5/4.0) jak i bez niej. Mierzono między innymi czas realizacji tych zadań, liczbę błędów, jakość dokumentacji oraz subiektywną ocenę uczestników. Przedstawione wyniki były imponujące - ogólny wzrost wydajności na poziomie 45% (w tym największy w obszarze QA - 62%), zwiększenie kompletności i spójności dokumentacji o 30% i ogólny zachwyt samych uczestników (zarówno w obszarach samego developmentu, zapewnienia jakości, architektury jak i zbierania wymagań).

JetBrains w zeszłym roku przeprowadził ankiety wśród ponad 23 tysięcy programistów, z których zdecydowana większość (96%) uznała, że korzystanie z narzędzi AI oszczędza ich czas, niemal jedna czwarta uznała, że generowany kod jest lepszy, a ponad połowa że zastosowanie automatycznych narzędzi spowodowało wzrost produktywności.

Z kolei Stanford University w 2025 w ramach analizy AI Index Report wspomaganej przez badania eksperymentalne na 100 tysiącach programistów z 500 firm na ogólnym poziomie zgodził się z komercyjnymi odpowiednikami, że AI istotnie zwiększa produktywność, choć już nie tak drastycznie - w przypadku Polski (4000 programistów) o 18.8%, w przypadku USA 19.3% a w Szwecji 20.6%. Tutaj jednak badacze zwrócili uwagę na inny aspekt - jakości kodu, który wymagał poprawek w aż 22%, podczas gdy średnia europejska dla rozwiązań budowanych tradycyjnie wynosi niewiele ponad połowę tego (12.5%).

Ciekawym "kamyczkiem do ogródka" generatywnego kodowania jest niedawno opublikowane przez METR (Model Evaluation and Transparency Research) - niezależną organizację badawczą zajmującą się oceną możliwości modeli AI. Co w kontekście dzisiejszego, opartego o ekonomię świata istotne, organizacja ta nie jest powiązana z producentami narzędzi AI czy też firmami wdrażającymi tego rodzaju rozwiązania (jak chociażby wcześniej wspomniany SoftServe), co może dawać przekonanie o niezależności prezentowanych wniosków i prowadzonych analiz.

Badanie, przeprowadzone na grupie zdecydowanie mniejszej, bo tylko 16 doświadczonych (min. 5 lat doświadczenia i praca nad repozytoriami o min. milionie lini kody, 22 tys. gwiazdek na GitHub) programistów open-source wykazało rezultaty zdecydowanie odmienne od wcześniej przytaczanych.

Programiści pracowali nad 246 rzeczywistymi problemami technicznymi - usuwaniem błędów, refaktoryzacją czy ulepszeniami funkcji losowo wykorzystując lub nie narzędzia generatywne (głównie Cursor Pro z modelami Claude 3.5 i 3.7). Wyniki interpretowane były na podstawie pomiaru czasu, analizy pull requestów (jakość) jak i subiektywnej oceny samych uczestników. W podsumowaniu okazało się, że korzystanie z AI zwiększa czas pracy o 19%, pomimo że programiści deklarowali, że ich wzrost wydajności był na poziomie około 20%. Co jeszcze ciekawsze, ale częściowo pokrywające się z badaniami Stanforda, jedynie 44% wygenerowanego przez AI kodu nadawała się do użycia - głównie z uwagi na jego jakość nieprzystającą do standardów projektu.

Wnioski ogólne wynikające z ostatniego opisanego badania wydają się zdecydowanie bardziej realistyczne, aniżeli statystyki i wyniki badań publikowane przez firmy powiązane z samymi narzędziami (czy to ich twórców, czy firmy wdrażające). Mówią one bowiem o bardzo istotnych kwestiach:

Subiektywne oceny przydatności AI wcale nie pokrywają się z wynikami analitycznymi

AI (jeszcze przynajmniej na tym etapie) nie radzi sobie z generowaniem kodu spełniającego wysokie standardy jakościowe - co z kolei może generować duży narzut na code-review czy bugfixing, które niekoniecznie są ujmowane w danych z innych badań. Kodowanie za pomocą AI wydaje się "przyjemniejsze", jednak czas spędzony na odpowiednim przygotowaniu promptów niejednokrotnie jest zdecydowanie większy, aniżeli jak jest postrzegany. Ponadto często doprowadza do rozproszenia uwagi, które jest pierwszym krokiem do prokrastynacji czy też niemal nieskończonych prób generowania "perfekcyjnego" rozwiązania.

Oczywiście z twierdzeniem, że AI nie jest przydatne w rozwoju oprogramowania należy się jeszcze wstrzymać - zarówno z uwagi na porównywalnie małą grupę testową, na której badanie MERT zostało przeprowadzone, ale również uwzględniając specyfikę zadań. W przypadku firm komercyjnych mieliśmy do czynienia z zadaniami "biznesowymi", badając grupę programistów open-source patrzymy na pasjonatów, których priorytetem niekoniecznie jest wykonanie określonego zadania w sposób najbardziej opłacalny ekonomicznie, a najlepszy czy też najwydajniejszy z algorytmicznego punktu widzenia.

Wydaje mi się, że dobrym porównaniem tutaj byłoby wprowadzanie narzędzi typu RAD (Rapid Application Development) jeszcze w latach 80 i 90 poprzedniego wieku. Narzędzia te znacząco zwiększały efektywność budowania aplikacji, kosztem jednak kontroli nad samą algorytmiką. Zwłaszcza że rozwiązania te (Borland Delphi, MS Visual Basic, PowerBuilder i inne) tak naprawdę również generowały kod, choć naturalnie za pomocą skrajnie innych sposobów, aniżeli to robią obecne rozwiązania do vibe-codingu.

Czy niegdyś RAD, później Low-Code/No-Code a obecnie AI nadaje się do dowolnych zastosowań?

Między innymi na to właśnie pytanie według mnie odpowiada porównanie powyższych badań.

Wspieranie się generatywną sztuczną inteligencją przy kodowaniu pozwala na zwiększenie produktywności, jednak kosztem jakości kodu. Problem ten można naturalnie rozwiązać poprzez większy nacisk na działania QA (w tym również code-review), jednak wtedy o wartościach na poziomie 45% czy nawet 25% według mnie możemy zapomnieć.

Możemy również założyć, że wygenerowany kod będzie spełniał niższe standardy jakościowe - jednak wtedy wzrost wydajności (i, co za tym idzie, efektywności ekonomicznej) będzie krótkotrwały, gdyż czas poświęcony na serwis takiego oprogramowania będzie zdecydowanie większy, aniżeli w przypadku kody wytworzonego przez człowieka. Oczywiście, w szczególności jeśli chodzi o dostawców oprogramowania, pytaniem otwartym jest kto za to zapłaci? Jako odpowiedź mogę przytoczyć sytuację, w której stosunkowo niedawno opiniowałem odpowiedzi kilku wielkich firm konsultingowych na RFP związane z budową rozwiązania. Znamiennym było, że wszyscy oferenci bardzo promowali wykorzystanie AI, a jednocześnie dawali stosunkowo krótki (pomiędzy 1 a 2 miesiące) okres serwisu gwarancyjnego na dostarczone rozwiązanie. Jeden z oferentów nawet zaproponował wariantową wycenę - z i bez wykorzystania akceleratorów AI, gdzie różnica w cenie sięgała 20%.

Czy warto się skusić na taki rabat? To pozostawiam czytelnikowi do oceny.

Autor wpisu

O AUTORZE

Autor thrillerów z elementami science-fiction oraz powieści z nurtu military hard SF. Na blogu analizuje punkty styku technologii, współczesnej obronności i warsztatu literackiego, stawiając na realizm operacyjny i logikę w każdym aspekcie twórczości.