Tyrimas rodo, kad kodo rašymo efektyvumo padidėjimą „sugeria“ žmonių atliekamos peržiūros „butelio kaklelis“.
Kiekvienas, kas nors kiek susiję su programavimu, žino, kad šiuolaikiniai dirbtinio intelekto (DI) programavimo asistentai ir agentai gali itin efektyviai generuoti didžiulius kiekius veikiančio kodo. Tačiau šias priemones naudojantys programuotojai taip pat žino, kad pernelyg pasitikėti to kodo tikslumu nederėtų, todėl bet kokį DI sugeneruotą rezultatą tenka daug laiko skirti peržiūrėti.
Neseniai atliktas tyrimas, apėmęs realią programavimo praktiką šimtuose įmonių, parodė, kad žmonių atliekama kodo peržiūra yra reikšmingas DI programavimo įrankių bendro efektyvumo „butelio kaklelis“, todėl „mažai įrodymų, jog įmonės, naudodamos šiuos įrankius, padidina programinės įrangos kiekį ar sumažina darbuotojų skaičių“. Tyrimo autorių teigimu, bet koks efektyvumo padidėjimas pačioje kodo rašymo stadijoje yra „suger; jį absorbuoja tolesni gamybos proceso apribojimai“: „kodo peržiūros procesas gerokai pailgėja, pull request’us dažniau tenka taisyti, o peržiūrėtojai palieka daugiau komentarų“.
Septynis kartus matuok, vieną kartą kirpk
Šioms išvadoms pasiekti Harvardo universiteto mokslininkai Fiona Chen ir Jamesas Strattonas panaudojo apibendrintus analitikos duomenis iš Jellyfish – įrankio, matuojančio inžinierių komandų veiklos rezultatus smulkiai. Duomenys apima 300 milijonų atskirų „darbo įvykių“ (pavyzdžiui, commit’ų ir pull request’ų) bei užduočių valdymo programinės įrangos duomenis, susijusius su daugiau nei 700 000 darbuotojų daugiau nei 700 atitinkamų programinės įrangos kūrimo įmonių nuo 2021 m. iki 2026 m. kovo.
Siekdami įvertinti DI įrankių poveikį šioms įmonėms, tyrėjai derino tiesiogiai matuojamą DI naudojimą su „GitHub“ veiklos analize, kad nustatytų, kada kiekviena įmonė pradėjo į savo darbo procesus diegti DI programavimo asistentus (kurie padeda automatiškai užbaigti kodą, daugiausia parašytą žmonių) ir (arba) DI programavimo agentus (kurie pagal nurodymus daugiausia patys savarankiškai rašo ir pateikia kodą). Tada tyrėjai atliko sudėtingus skaičiavimus, kad nustatytų „skirtumų skirtumo“ (difference of differences) regresiją pagrindiniams kintamiesiems tiek prieš, tiek po šių įrankių įdiegimo skirtingu metu skirtingose organizacijose.
Kalbant apie pagaminamo kodo kiekį, rezultatai aiškūs ir ryškūs. Tyrėjų teigimu, DI programavimo agentų įdiegimas įmonėje vidutiniškai lemia 30 procentų išaugusį sugeneruotų kodo eilučių skaičių, 20 procentų didesnį commit’ų skaičių ir 23 procentais daugiau pull request’ų. Tačiau visas šis papildomas kodas tiesiogiai nevirsta didesne programinės įrangos produkcija įmonės lygmeniu. Priešingai, tokiais įrankiais kaip Jira sekamų užduočių (Issues) ir epų (Epics, t. y. ištisų programinės įrangos funkcijų) įgyvendinimo rodiklis po DI įrankių įdiegimo statistiškai reikšmingai nepasikeitė (tyrėjai taip pat nerado jokio „sudėties poslinkio“ šių Jira sekamų užduočių dydyje ar sudėtingume po DI įdiegimo).
Šio neatitikimo priežastį galima įžvelgti tiesiogiai kodo peržiūros procese, kuris po DI programavimo agentų įdiegimo vidutiniškai trunka gerokai ilgiau. Apskritai vidutinė „peržiūros proceso“ trukmė nuo pull request’o pateikimo iki jo sujungimo su kodo baze po DI agentų įdiegimo išauga vidutiniškai 49 procentais. Tai matyti ir iš detalesnių duomenų: tyrėjų teigimu, po perėjimo prie DI agentų „pull request’ų, kuriems prašoma atlikti pakeitimų, dalis išaugo beveik dvigubai, o komentarų, tenkančių vienam pull request’ui, skaičius padidėjo 35 %“.
Reaguodamos į šį pokytį, įmonės po DI agentų įdiegimo 14 procentų padidino kodo peržiūras atliekančių darbuotojų dalį. Tyrėjai taip pat rašo, kad „negali priskirti reikšmingų užimtumo pokyčių DI poveikiui“, išanalizavę bendrą aktyvių darbuotojų skaičių Jellyfish duomenyse ir palyginę jį su šių įmonių „LinkedIn“ duomenimis.
Nors teoriškai DI galėtų padėti ir peržiūros procese, tyrėjai nustatė, kad kol kas šis poveikis yra menkas. Nors iki 2026 m. kovo 80 procentų tirtų įmonių naudojo tam tikrą DI atliekamą kodo peržiūrą, DI agentai buvo atsakingi tik už 23,3 procento visų peržiūros komentarų ir 10,8 procento visų pull request’ų, o tai rodo, kad didžiąją šio darbo dalį vis dar atliko žmonės.
Be abejo, DI agentai vis dar yra palyginti nauja programavimo pasaulio dalis, o jų rezultatai buvo gerokai atnaujinti ir patobulinti net jau po šio tyrimo duomenų pabaigos 2026 m. kovą. Nors šiuo metu 95 procentai tyrime dalyvavusių įmonių yra įdiegusios DI programavimo agentus, daugelis jų, be abejo, vis dar mokosi, kada ir kaip geriausia juos naudoti. Tokie „kodo rašymo laiko ir peržiūros laiko“ kompromisai galėtų sumažėti, kai programinės įrangos inžinierių komandos įgis daugiau patirties, vertindamos, kokie yra DI agento „paleidimo“ ant konkrečių programavimo problemų pliusai ir minusai.
Tačiau kol kas leisti DI rašyti kodą atrodo kaip dviašmenis kardas: kodo rašymo greičio padidėjimą atsveria panašus žmonių atliekamos kodo peržiūros laiko ir pastangų padidėjimas. Dėl tokio rezultato kyla klausimas, ar nemaža laiko ir lėšų investicija, reikalinga DI programavimo agentams paleisti, tikrai atsiperka daugumai įmonių.
Paaiškinimas: Pull request’as – tai programuotojo pateiktas prašymas sujungti jo parašytus kodo pakeitimus su pagrindine projekto kodo baze; prieš tai kiti komandos nariai paprastai peržiūri pakeitimus ir palieka pastabų.
