Ar dirbtinis intelektas pakeis programuotojus?

DI nepakeis programuotojų - jis suteiks pranašumą DI naudotojams

Dirbtinio intelekto (DI) įrankiai programavime keičia programinės įrangos kūrimą, bet ne taip, kaip daugelis mano. Esmė paprasta - DI nepakeis programuotojų, pranašumą įgys tie, kurie moka juo efektyviai naudotis. Dirbdami su daugybe projektų, matėme, kaip tai veikia realybėje. Panika dėl darbo vietų praradimo dažnai neatspindi tikros situacijos.

Prisiminkime „Excel“ ir buhalteriją. „Excel“ skaičiuoklės nepakeitė buhalterių - jos palengvino buhalterių darbą ir leido daugiau laiko skirti didesnės vertės analizei. Tie, kurie nesimokė dirbti su skaičiuoklėmis, neišėjo iš darbo dėl pačio „Excel“ atsiradimo - jie pralaimėjo kolegoms, kurie jį įvaldė.

Programuotojų komandos patiria tą patį su DI įrankiais. DI nepakeičia programuotojų – jis pakeičia tuos, kurie nesinaudoja DI, tais, kurie moka jį naudoti.

Taip pat verta suprasti, kuo DI gali padėti, o kur jis dar stringa. Tie, kurie žino šias ribas, su DI dirba sėkmingai, kiti lieka užnugaryje su gražiais, bet neveiksmingais rezultatais.

Kur DI kodavimo įrankiai stringa

Iššūkiai realiame pasaulyje

DI programavimo įrankiai, tokie kaip GitHub Copilot, Cursor ir ChatGPT, nėra stebukladariai. Jie veikia greitai ir padeda, tačiau realybėje susiduriame su painiomis sistemomis - senos integracijos, dalinė dokumentacija ir verslo taisyklės, kurias žino tik darbuotojai.

Praėjusį ketvirtį perėmėme 2012-ųjų logistikos platformą - painų kodą, pusiau dokumentuotus API ir sandėlio taisykles, kurios nebeatitiko realių operacijų. DI pagreitino paprastų funkcijų perrašymą, bet nepastebėjo niuansų: pavyzdžiui, kaip keitėsi prekių kelias tarp sandėlių, kodėl sekmadieniais gerokai išauga siuntų srautas. Šie įrankiai sprendžia atskiras užduotis, tačiau nesupranta skubaus 18 val. skambučio iš operacijų skyriaus.

DI kodavimo įrankiai sprendžia atskirus uždavinius. Kai atsiranda painių reikalavimų ar senų sistemų, tik žmogus atskiria svarbiausius dalykus.

2025m. METR atliktas tyrimas (opens in new tab) atskleidė, kad patyrę programuotojai, naudodamiesi DI programavimo asistentais, pažįstamose kodo bazėse iš tikrųjų dirbo 19% lėčiau, daug laiko skirdami DI generuotų sprendimų taisymui ir tobulinimui, nors patys manė, kad dirba greičiau. Tai parodo realias DI programavimo įrankių ribas brandžiuose, sudėtinguose projektuose ir pabrėžia žmonių ekspertizės svarbą peržiūrint bei integruojant DI sukurtą kodą.

Nemaloni tiesa: DI generuoto kodo klaidų taisymas dažnai reikalauja daugiau patirties nei jo rašymas. Kai DI pateikia „teisingai atrodančius“ sprendimus, tačiau jie greitai lūžta apkrovos metu, tik gilios sistemos žinios atskleidžia klaidas. Galutiniai darbai - kraštutiniai atvejai, paruošimas gamybai, integracijos - vis dar reikalauja vyresnio lygio specialistų įsikišimo.

Žmogaus sprendimai

Mašininis mokymasis geba aptikti dėsningumus, tačiau nesprendžia verslo uždavinių. DI kodavimo įrankiai prognozuoja tikėtiną sekantį žingsnį - jie nesprendžia rizikų, politikos ar kompromisų. Todėl žmogaus sprendimai išlieka nepakeičiami.

DI gali greitai sugeneruoti kodą, tačiau žmonės privalo kiekvieną eilutę kruopščiai peržiūrėti - patikrinti, ar jis veiks realiomis sąlygomis, ar apima svarbiausius atvejus. „Atrodo gerai" - dar nereiškia „veikia produkcijoje".

Iš pirmo žvilgsnio teisingas kodas nebūtinai yra saugus, atitinkantis reikalavimus ar išlieka stabilus apkrovos metu. Žmonės vertina kaštus, sudėtingumą, pasirenka, ką automatizuoti, kokį paslaugų lygio susitarimą (SLA) taikyti ir kada „pakankamai gerai" jau yra per didelė rizika.

„Salesforce" inžineriniai tyrimai rodo: DI įrankiai greitai generuoja kodą, tačiau galutinį sprendimą - ar jis tinkamas paleidimui - priima žmogus. Jis gali nustatyti ribas, interpretuoti kontekstą, įvertinti riziką remdamasis ilgamete patirtimi.

Ar DI tikrai supranta jūsų verslo uždavinį? Kol kas - ne. O gal ir niekada pilnai nesupras. Nes kontekstą sudaro ne tik duomenys, bet ir santykiai, istorija, organizacijos rizikos tolerancija ir daug metų kaupta patirtis.

Sudėtingumo skirtumas yra tikras. Jį suvaldyti gali tik patyrę žmonės, kurie naudojasi DI kaip pagalbininku, o ne kaip savęs pakeitimu.

Kada DI padeda

Išbandę Copilot, Cursor ir kitus DI programavimo asistentus įvairiuose projektuose, veiklą suskirstėme taip:

• 70 % DI darbas: pasikartojantis kodas, validacijos, struktūrų paruošimas, dokumentacija
• 20 % žmogaus korekcijos: klaidų taisymas, išskirtinių atvejų atpažinimas, verslo taisyklių pritaikymas
• 10 % žmogaus strategija: architektūra, dizainas, mentorystė, kompromisai

Atvejo analizė - Sąskaitų automatizavimas

Ketvirtadienis, 16:30 val. Finansų komanda laukia, kol bus apdorota šimtai sąskaitų. Anksčiau trims žmonėms tai užtrukdavo apie tris dienas - o vis tiek sumos dažnai nesutapdavo.

Mes panaudojome DI kodavimo asistentą pasikartojančioms užduotims - paruošti endpointus, duomenų modelius, validacijas, pagrindinę dokumentaciją. Kartu su kodu sugeneruota aiški dokumentacija, įskaitant API gaires. Šią patirtį pritaikėme ir MYGOM Invoice (opens in new tab) projekte.

Toliau sekė sudėtingesni uždaviniai: senų sąskaitų apdorojimas. Pirmasis procesas pareikalavo korekcijų - pridėjome konkrečių pavyzdžių ir apribojimų, leisdami asistentui atnaujinti tik būtiną dalį.

Penktadienį vidurdienį pirmoji pilna automatizavimo veikla jau vyko: sąskaitos paimtos iš el. pašto ir bendrų aplankų, išanalizuotos pagrindinių laukų atžvilgiu, suderintos su banko mokėjimais (iki 95% tikslumu), o kraštutiniai atvejai patikrinti žmonių.

Rezultatai: 40% trumpesnis apdorojimo laikas, 30% mažesnės išlaidos programinei įrangai, vienas darbuotojas gali apdoroti 10x daugiau sąskaitų.

Tai nėra situacija, kai DI pakeičia žmones. Tai DI, kuris nuima pasikartojantį darbą, kad žmonės galėtų sutelkti dėmesį į tikslumą, pinigų srautų analizę ir atitikimą reikalavimams.

Kaip DI keičia programuotojų vaidmenis

Ši programinės įrangos kūrimo automatizacija ne tik pagreitino darbą, bet ir apvertė komandos vaidmenis aukštyn kojomis. Paprasti darbai - šablonai, baziniai endpointai, pasikartojantys sprendimai - dabar yra automatizuoti. Mūsų jaunesnieji programuotojai per pirmus pusę metų jau dirba su integracijomis, peržiūri DI darbą. Vidutinės patirties kolegos sprendžia klausimus, kuriuos anksčiau palikdavome tik sernior programuotojams. Vyresnieji programuotojai gali daugiau laiko skirti architektūrai, mentorystei, svarbiems verslo sprendimams.

Prieš AI (2022)

• Juniors: 80 % pasikartojantis kodas, 20 % architektūros mokymasis
• Mid-level: 60 % įgyvendinimas, 40 % projektavimas
• Seniors: 40 % kodavimas, 30 % architektūra, 30 % mentorystė

Po AI (2025)

• Juniors: 30 % AI rezultatų tikrinimas, 70 % sudėtingesnių problemų sprendimas
• Mid-level: 20 % įgyvendinimas, 80 % sistemų dizainas ir integracija
• Seniors: 10 % įgyvendinimas, 40 % architektūra, 50 % strategija ir mentorystė

Prototipavimas dabar

Anksčiau naujų funkcijų kūrimui reikėdavo ilgų pasiruošimo dienų. Dabar vyresnysis programuotojas su DI pagalba per kelias valandas sudėlioja duomenų modelius, testinius duomenis ir kartu su produkto komanda planuoti srautus. Idėjos tampa veikiančiomis demonstracinėmis versijomis per kelias valandas, o ne dienas.

Rezultatai, kuriuos matome

• Projekto pristatymo laikas sutrumpėjo 35–40 %
• Dokumentacijos užbaigimas padidėjo nuo 60 % iki 95 %
• Padidėjęs programuotojų pasitenkinimas (mažiau nuobodaus darbo)

Kritikai sako, kad DI padeda tik paprastoms užduotims. Iš tiesų DI pašalina monotoniją, leidžiančią žmonėms daugiau dėmesio skirti dizainui, kokybei ir kūrybiškumui.

Kaip įdiegti DI programavimo įrankius

1. Kaip tiksliai formuluoti užduotis DI

Daugelis komandų žiūri į DI kodavimo įrankius kaip į automatus - įvedi užklausą ir tikiesi tobulų sprendimų. Tai klaidinga nuostata. Sėkmė ateina sugebėjimu užduoti tinkamus klausimus, įvertinti atsakymus ir greitai iteruoti.

Pirmasis DI kodo asistentų pateiktas sprendimas atrodė solidžiai, tačiau darė klaidingas prielaidas, kurios mūsų sistemai netiko - pavyzdžiui, numatė kasdienį prisijungimą ir naudojo laukų pavadinimus, kurių neturime. Todėl pridėjome tikrus duomenų laukų pavadinimus, aiškiai apibrėžėme kraštutinius atvejus ir verslo taisykles, kelis kartus testavome, tikrinome ir tobulinome sprendimą. Šis procesas: užklausa → vertinimas → korekcija → testas. Greitį užtikrina būtent šio ciklo išmanymas, o ne šuoliai per etapus.

Ko reikia šiandieniniams programuotojams

• Rašyti tikslias užklausas su tikrais duomenimis ir pavyzdžiais
• Vertinti, ką DI praleido „tarp eilučių"
• Taisyti ne tik sintaksę, bet ir logiką
• Žinoti, kada stabdyti DI ir rašyti pačiam
• Pastebėti pavojingas prielaidas dar prieš paleidžiant kodą

2. Sistemų dizainas svarbiau už sintaksę

DI puikiai susidoroja su sintakse ir šablonais, tačiau jis nesirenka sistemos architektūros, neplanuoja klaidų valdymo ir kompromisų.

Kas iš tiesų svarbu:

• Užtikrinti, kad duomenų srautai būtų aiškiai sužymėti tarp skirtingų paslaugų ir komandų
• Nuspėti integracijos rizikas dar kelis sprintus į priekį
• Braižyti diagramas, kurios atitiktų tikrą verslo veiklos modelį
• Klausimai „Kaip tai gali sugesti?“ prieš „Ar tai kompiliuojasi?“
• Nuo pat pradžių atsižvelgti į vėlavimą, kaštus, atsparumą klaidoms ir privatumo aspektus

Šiandien sisteminis mąstymas - pagrindinis programuotojo įgūdis.

Įdiegimas be chaoso

1 žingsnis: auditavimas

Sekite savaitės darbo apimtį pagal kategorijas:

• A: pasikartojantis kodas (API taškai, formos, konfigūracija)
• B: sudėtinga logika (algoritmai, integracijos, architektūra)
• C: komunikacija (dokumentacija, susitikimai, peržiūros)
  Jei A sudaro daugiau nei 40%, radote savo DI integracijos galimybę.

2 žingsnis: pradėkite nuo vienos problemos

Geri pirmieji tikslai – API dokumentacija, šiuolaikinės sistemos, testų generavimas, dokumentacijos komentarai.

Iš pradžių venkite pagrindinės verslo logikos, saugumo, tiesioginių duomenų bazių.

Atlikite 30 dienų pilotinį projektą ir matuokite sutaupytą laiką bei klaidų dažnumą.

3 žingsnis: lavinkite peržiūros įgūdžius

DI nepakeičia kodo peržiūros – jis kelia kartelę. Mokykite komandas atpažinti klaidingas API interpretacijas, spręsti, kada pakanka turimo sprendimo, iteruoti užklausas ir suvokti, kada atsisakyti DI ir rašyti kodą pačiam.

Pasiruošę ar ne - ateitis jau čia

Programinės įrangos kūrimo automatizavimas su DI nėra skirtas pakeisti žmones – jis skatina patyrusių programuotojų galimybes. Teisingai pritaikius, darbai, kurie anksčiau užimdavo dienas, dabar užtrunka valandas – o žmonės rūpinasi patikromis ir sprendimais. Programuotojai mažiau laiko praleidžia ties rutina, daugiau - ties kokybe, architektūra ir verslo rezultatais.

DI nepakeis programuotojų. Laimės tie, kurie derins AI automatizavimą su patirtimi, aiškiomis taisyklėmis, peržiūromis.

Ateitis nelaukia. Komandos, pradėjusios naudoti DI, jau dabar kuria greičiau, išsamiau dokumentuoja ir mažiau pervargsta. Tie, kurie delsia, lieka su monotonišku darbu.

Jei susiduriate su senomis sistemomis arba siekiate daugiau nei dabartinis pajėgumas leidžia, pradėkite mažais žingsniais: pasirinkite vieną darbo srautą, vykdykite 30 dienų pilotą ir mokykitės efektyviai atlikti kodo peržiūrą. Jei norite pagalbos kuriant pilotą, susisiekite su mumis (opens in new tab).