AI kodavimo įrankių pažadas paprastas: programuotojas parašo mažiau rankomis, todėl per tą patį laiką gali padaryti daugiau. Praktikoje pirmoji šio sakinio dalis dažnai pasitvirtina. Antroji – gerokai mažiau nuspėjama.
2025–2026 m. tyrimai piešia gana nuoseklų vaizdą. AI gali labai pagreitinti konkretaus kodo fragmento generavimą, tačiau programinės įrangos kūrimas nesibaigia tuo momentu, kai ekrane atsiranda veikiantis kodas. Jį dar reikia suprasti, integruoti, ištestuoti, peržiūrėti, apsaugoti nuo pažeidžiamumų ir vėliau prižiūrėti.
Todėl svarbiausias klausimas jau nėra „ar AI moka rašyti kodą?“. Moka. Daug naudingesnis klausimas – kokiose užduotyse sutaupytas rašymo laikas išlieka iki pat galutinio produkto, o kokiose jis tiesiog persikelia į kitą kūrimo proceso etapą.
Esmė
Esmė
AI leidžia kodą generuoti greičiau, tačiau reali nauda priklauso nuo testavimo, peržiūros ir užduoties. Ką rodo 2025–2026 m. tyrimai.
- Daugiau kodo nėra tas pats, kas daugiau pristatyto produkto DX daugiau kaip 400 įmonių analizėje AI naudojimas padidėjo 65%, o medianinis užbaigtų „pull request“ srautas vienam programuotojui – tik 7,76%. Tai rodo, kad kodo generavimas yra tik viena ilgesnio kūrimo proceso dalis.
- AI labiausiai padeda tada, kai rezultatą lengva patikrinti Boilerplate kodas, testų ruošiniai, dokumentacija, nedidelės transformacijos ar aiškiai apibrėžtos funkcijos gali būti atliekamos greičiau. Sudėtingame, programuotojui gerai pažįstamame kode AI kartais net sulėtina darbą.
- Butelio kaklelis gali persikelti į peržiūrą GitClear ir Veracode tyrimai rodo palaikomumo bei saugumo rizikas. Jei sugeneruojama daugiau kodo, bet testavimo ir peržiūros pajėgumai nesikeičia, sutaupytas rašymo laikas gali būti išleistas tikrinimui ir taisymui.
Daugiau sugeneruoto kodo dar nereiškia tiek pat daugiau rezultato
GitClear 2026 m. analizėje intensyviausi AI įrankių naudotojai tam tikromis savaitėmis sukurdavo 4–10 kartų daugiau išliekančio kodo nei programuotojai, kurių AI naudojimas nebuvo fiksuojamas. Tačiau pats tyrimas perspėja šio skirtumo nelaikyti grynu AI efektu: daug AI naudoję programuotojai ir anksčiau buvo produktyvesni.
Lyginant tuos pačius žmones su jų pačių ankstesniu darbu, GitClear nustatė maždaug 25% kodo generavimo našumo prieaugį. Tai vis dar reikšminga, bet labai toli nuo įspūdžio, kad AI automatiškai leidžia vienam programuotojui atlikti keturių ar dešimties žmonių darbą. GitClear tyrimo autoriai kartu pastebi, kad didesnis sugeneruoto kodo kiekis siejasi ir su didesniu jo perrašymu bei dubliavimu.
Dar aiškiau skirtumas tarp „parašyti“ ir „pristatyti“ matomas DX duomenyse. Bendrovė analizavo daugiau kaip 400 organizacijų nuo 2024 m. lapkričio iki 2026 m. vasario. AI įrankių naudojimas jose padidėjo vidutiniškai 65%, tačiau medianinis užbaigtų „pull request“ skaičius vienam programuotojui išaugo tik 7,76%.
DX vertinimu, daugelyje realių organizacijų maždaug 5–15% pristatymo srauto pagerėjimas šiandien yra realesnis lūkestis nei kelis kartus didesnio našumo pažadai.
Kada AI iš tiesų taupo laiką
AI pranašumas didžiausias tada, kai užduotis yra aiškiai apibrėžta, jos rezultatas lengvai patikrinamas, o klaidos kaina nedidelė. Tokiu atveju programuotojas gali labai greitai gauti pirmą veikiančią versiją ir beveik iš karto įsitikinti, ar ji teisinga.
- standartinis arba pasikartojantis „boilerplate“ kodas;
- vienetiniai testai ir jų ruošiniai;
- duomenų formatų konvertavimas;
- nedidelės, aiškiai apibrėžtos funkcijos;
- API naudojimo pavyzdžiai;
- dokumentacijos ir komentarų juodraščiai;
- pažįstamo kodo paaiškinimas ar nesudėtingas refaktorizavimas.
Tokiose situacijose žmogus neperduoda AI atsakomybės už sistemą. Modelis veikiau tampa itin greitu pirmojo juodraščio generatoriumi. Jei rezultatą galima patikrinti testais arba per kelias minutes perskaityti, sutaupytas laikas dažniausiai nėra suvalgomas vėliau.
Google DORA tyrimai rodo panašią kryptį. AI naudojimas siejamas su geresne dokumentacija, greitesne kodo peržiūra ir kai kuriose komandose didesniu pristatymo srautu. Tačiau rezultatai labai priklauso nuo pačios organizacijos: geri testai, greitas grįžtamasis ryšys ir aiški architektūra AI naudą sustiprina, o silpni procesai gali padidinti problemas. DORA šią tendenciją apibūdina kaip AI gebėjimą sustiprinti jau egzistuojančią komandos būklę.
Kada sutaupytas laikas persikelia į tikrinimą
Kuo užduotis labiau priklauso nuo didelės egzistuojančios sistemos, istorinio konteksto ir sunkiai formalizuojamų reikalavimų, tuo AI rezultato patikrinimas tampa brangesnis.
Čia svarbus 2025 m. METR eksperimentas. Tyrėjai paprašė 16 patyrusių atvirojo kodo programuotojų atlikti 246 realias užduotis projektuose, kuriuos jie gerai pažinojo. Dalį užduočių buvo leidžiama atlikti su Cursor ir Claude, dalį – be AI.
Rezultatas buvo netikėtas: su AI programuotojai užduotis atliko vidutiniškai 19% lėčiau. Dar įdomiau, kad patys dalyviai manė, jog AI juos pagreitino maždaug 20%. METR eksperimente daug laiko buvo prarandama formuluojant užklausas, laukiant atsakymų ir tikrinant sprendimus, kurie iš pirmo žvilgsnio atrodė tinkami, bet nevisiškai atitiko sudėtingo projekto kontekstą.
Šio rezultato negalima taikyti visiems programuotojams ir visiems dabartiniams modeliams. 2026 m. pats METR nurodė, kad naujesni įrankiai greičiausiai jau naudingesni, nors tiksliai išmatuoti efektą tapo sunkiau, nes dalis programuotojų nebenori dalyvauti eksperimentuose, kuriuose jiems tenka dirbti be AI. Naujesnis METR atnaujinimas todėl nepateikia tokio pat tvirto vieno skaičiaus.
Kodo kokybė tampa svarbesnė už jo generavimo greitį
Kai kodo generavimas atpinga, santykinai brangesnis tampa gebėjimas nuspręsti, ar tas kodas apskritai turėtų patekti į sistemą.
GitClear 2025 m. tyrimas, apėmęs 211 mln. pakeistų kodo eilučių nuo 2020 iki 2024 m., fiksavo mažėjantį refaktorizavimą ir augantį kopijuojamo kodo kiekį. 2026 m. analizė jau apėmė 623 mln. pakeitimų ir vėl rodė didesnį dubliavimą bei trumpalaikį kodo perrašymą tarp intensyvesnių AI naudotojų.
Šių duomenų nereikėtų interpretuoti kaip įrodymo, kad AI automatiškai gamina blogą kodą. Tai stebėjimo duomenys: AI dažniau naudoja ir tie programuotojai, kurie apskritai parašo gerokai daugiau kodo. Tačiau praktinė problema lieka ta pati – sugeneruoti papildomą tūkstantį eilučių dabar daug lengviau nei patikimai įrodyti, kad jų visų reikia.
Veikiantis kodas nebūtinai yra saugus kodas
Saugumo srityje skirtumas tarp sintaksiškai teisingo ir produkcijai tinkamo kodo ypač ryškus. Veracode išbandė daugiau nei 100 didžiųjų kalbos modelių, pateikdama jiems 80 programavimo užduočių keturiomis kalbomis.
45% generavimo užduočių nepraėjo bent vieno saugumo testo ir įtraukė žinomą pažeidžiamumą. Java užduotyse nesėkmių dalis siekė 72%, Python – 38%, JavaScript – 43%, C# – 45%. Veracode rezultatai taip pat parodė, kad modelio gebėjimas parašyti veikiantį kodą augo greičiau nei gebėjimas nuosekliai išvengti saugumo klaidų.
45% skaičius nereiškia, kad beveik pusė viso realiai naudojamo AI kodo turi pažeidžiamumų. Tai specialiai sudaryto etalono rezultatas. Tačiau jis gerai iliustruoja, kodėl žmogaus peržiūra ir automatiniai saugumo testai negali būti išmetami vien dėl to, kad modelis labai greitai pateikė veikiantį sprendimą.
AI dažnai nepašalina butelio kaklelio – jis jį perkelia
Tradiciniame kūrimo procese dalis laiko buvo skiriama pačiam kodo rašymui. AI šią dalį gali smarkiai sutrumpinti. Tačiau bendras procesas turi ir kitus etapus: reikalavimų supratimą, architektūrą, kodo peržiūrą, testavimą, integraciją, saugumą, diegimą bei priežiūrą.
Jei viena grandis staiga pradeda veikti kelis kartus greičiau, o visos kitos lieka tokios pačios, bendras našumas kelis kartus nepadidėja. Į peržiūros eilę tiesiog patenka daugiau kodo.
| Situacija | Ką daro AI | Kur atsiranda nauda arba sąnaudos |
|---|---|---|
| Aiški, maža užduotis | Greitai sukuria pirmą sprendimą | Dažnai realiai sutaupo laiką |
| Rezultatą dengia geri automatiniai testai | Generuoja ir iteruoja | Klaidos aptinkamos pigiai ir anksti |
| Didelis senas kodynas | Turi suprasti daug nematomo konteksto | Daugiau laiko gali prireikti tikrinimui |
| Silpna testų bazė | Padidina kodo srautą | Rizika perkeliama į peržiūrą ir produkciją |
| Saugumui jautri sistema | Pateikia greitą sprendimą | Reikia papildomos žmogaus ir automatizuotos patikros |
| Programuotojas nepažįsta srities | Gali pateikti įtikinamai atrodantį kodą | Sunku atskirti gerą sprendimą nuo subtilios klaidos |
Ką tai reiškia jaunesniems programuotojams
AI poveikis darbo rinkai jau matomas, nors jį sunku atskirti nuo po pandemijos prasidėjusio technologijų sektoriaus taupymo. SignalFire 2026 m. duomenimis, naujų absolventų ir pradinio lygio darbuotojų samdymas didžiosiose technologijų bendrovėse buvo maždaug 65% mažesnis nei 2019 m., o ankstyvos stadijos startuoliuose – apie 76% mažesnis.
SignalFire ataskaita kartu rodo, kad AI nėra vienintelis paaiškinimas. Bendras technologijų samdymas taip pat tebėra žemiau ankstesnių lygių, įmonės po pandemijos mažino per greitai išaugusias komandas, o organizacinės struktūros tapo plokštesnės.
Vis dėlto AI keičia būtent tas užduotis, kurios tradiciškai padėdavo pradedančiajam kaupti patirtį: paprastas funkcijas, testus, smulkius pataisymus ir standartinį kodą. Jei tokių darbų žmonėms liks mažiau, bendrovėms teks sąmoningiau spręsti, kaip paruošti būsimus vidutinio ir aukšto lygio inžinierius.
Todėl vadinamoji „juniorų mirties spiralė“ kol kas yra rizikos scenarijus, o ne jau įvykęs faktas. Nėra patikimų duomenų, leidžiančių teigti, kad po dvejų ar trejų metų technologijų sektorių būtinai ištiks didelis patyrusių specialistų trūkumas.
Paprasta taisyklė: kuo pigiau patikrinti, tuo daugiau AI sutaupo
Skirtingi tyrimai atrodo prieštaringi tik tol, kol AI vertinamas kaip vienas universalus produktyvumo mygtukas. DX mato kuklų organizacinio srauto pagerėjimą. GitClear – labai didelį kodo kiekio augimą, bet ir daugiau palaikomumo signalų. METR sudėtingame pažįstamame kode fiksavo sulėtėjimą. DORA randa naudą komandose, turinčiose gerus procesus.
Visus šiuos rezultatus galima sujungti gana paprastai. AI labiausiai taupo laiką tada, kai žmogus greitai ir pigiai gali patikrinti jo rezultatą. Kuo daugiau sistemos konteksto reikia suprasti, kuo sunkiau automatizuoti testavimą ir kuo brangesnė klaida, tuo didesnė tikimybė, kad sutaupytas rašymo laikas grįš kaip peržiūros, integravimo ar taisymo darbas.
Programuotojo vertė todėl ne nyksta, o keičiasi. Pats kodo surinkimas iš sintaksės tampa pigesnis. Daugiau vertės persikelia į problemos formulavimą, architektūrą, sprendimų vertinimą, testų kūrimą, saugumą ir gebėjimą suprasti, ar sugeneruotas kodas iš tiesų priklauso konkrečiai sistemai.
AI gali būti labai geras greitintuvas. Tačiau greitintuvas nepašalina stabdžių, posūkių ir kelio ženklų. Jei organizacija geba greitai tikrinti tai, ką modelis pagamina, produktyvumo prieaugis gali būti realus. Jei ne, daugiau kodo tiesiog reiškia daugiau kodo, kurį kažkam vis tiek reikės perskaityti.
Komentarai