Kodas atpigo. Programinė įranga — nebūtinai.
Dirbtinis intelektas ir jo įrankiai stipriai keičia programuotojų darbą, tačiau pastaruoju metu teko girdėti daug radikalių nuomonių apie tai, kaip viskas klostysis ateityje: programuotojų nebereikės, viską (bet ką!) bus galima susiprogramuoti patiems vartotojams, programavimo paslaugos turėtų atpigti jei ne šimtais, tai bent dešimtimis kartų. Iš tiesų, tuo galima lengvai įtikėti: anksčiau techninių įgūdžių neturintis vadovas pats savo programos nebūtų sukūręs, o dabar pakanka atsidaryti Claude Code, dirbtiniam intelektui papasakoti savo norus, ir štai, po keleto minučių (o jeigu problema sudėtingesnė – po keleto valandų) turėsime gerai atrodantį ir veikiantį prototipą. Gali pasirodyti, kad sunkiausia dalis įveikta – dabar tik beliko jį perkelti „į produkciją“, ten, kur juo sėkmingai naudosis laimingi vartotojai. Anksčiau tokie projektai truko mėnesiais, o štai dabar lydekai paliepus man panorėjus per kelias valandas turime kažką veikiančio. Natūralu, kad ir noras mokėti didžiules sumas už programavimo paslaugas sumažėjęs.
Dažnai tokiais atvejais klientą sunkiai įtikina argumentas, kad gerai apgalvota, kruopščiai patikrinta ir kokybiškai suprogramuota sistema yra verta už ją mokamų pinigų. Taip, gal kokybė mažesnė, bet pastebėtas klaidas greitai pataisysime su tuo pačiu dirbtiniu intelektu. Galų gale jei matysime, kad klaidos vis dauginasi kaip tarakonai apleistoje palėpėje – imsime ir visą sistemą nugriovę perstatysime nuo nulio. Juk programavimas dabar beveik nieko nebekainuoja.
Čia slypi klasikinė klaida: kvaila tikėtis, kad gerai nesupratus verslo poreikių ir tiesiog bukai perrašius (nesvarbu, kad pigiai!) kreivą sistemą išspręsi problemą. Neužtenka paprašyti „perrašyk, bet kad nebūtų klaidų“ – reikia gerai suprasti, kodėl sistema kreiva ir neatitinka poreikių.
Iš tiesų, jei iki smulkiausių detalių žinai, kokią sistemą nori sukurti, šiandien ją suprogramuoti yra beveik juokų darbas. Na, ar bent jau juokų darbas gauti kažką panašaus į tai ko prašei. Turiu nuojautą, kad bendros programinės įrangos gyvavimo ciklo sąnaudos ne sumažėjo, o tiesiog persiskirstė. Atpigus programavimui — t. y. pačiam procesui, kai nusprendžiama, KAIP verslo poreikius išversti į kompiuterio kalbą — dar svarbesnė tapo verslo poreikių analizė, arba gebėjimas suprasti, KĄ iš tikrųjų reikia suprogramuoti. Kartu išaugo ir sistemų priežiūros kaštai: kuo pigiau kurti sistemas, tuo jos tampa sudėtingesnės ir mažiau suprantamos. Kodas dabar generuojamas greičiau, nei žmonės spėja jį suprasti, kaupiasi techninė skola. Prižiūrėti sistemą, kurios pats nekūrei ir iki galo nesupranti yra didelis iššūkis.
Pripažįstu, kad dėl savo patirties galiu būti šališkas. Labai dažnai geriausi mūsų klientai būdavo tie, kuriuos tekdavo gelbėti iš situacijų, kai jų pačių jėgomis sukurti sprendimai — Excel lentelės ar įvairūs no-code / low-code įrankiai — nebesusitvarkydavo su augančiais poreikiais. Pradžioje viskas atrodo paprasta ir veikia visai neblogai. Tačiau be apgalvotos sistemos architektūros anksčiau ar vėliau atsitrenkiama į sieną: pradeda piltis klaidos, sistema lūžinėja, jos rodomi skaičiai tampa nebepatikimi, o net paprasčiausių ataskaitų gamyba ima trukti absurdiškai ilgai. Prieš dešimtmetį panašią situaciją matėme su no-code ir low-code įrankiais, kurie taip pat žadėjo, kad verslas galės pats susikurti sistemas be programuotojų. Kurį laiką tai veikia, bent jau kol sistema maža. Tačiau sudėtingumui augant grįžtama prie tų pačių problemų: architektūros, duomenų modelio, integracijų ir techninės skolos. Ar tik šiandienos „vibe coding“ nėra tiesiog nauja tos pačios istorijos versija?
Aišku, galima būtų tikėtis, jog pakaks dirbtiniam intelektui pasakyti „perrašyk šią sistemą taip, kad nelūžinėtų“ ir ji susitvarkys, bet realybėje dar nesu to matęs. Tuo tarpu geras poreikių supratimas ir pagal tai apgalvota architektūra to padeda išvengti. Tačiau tai ateina tik su patirtimi.
Bet gal iš tikrųjų pakanka geros architektūros ir patyrusio analitiko, o visa kita galima patikėti dirbtiniam intelektui? Galbūt — jei analitikas puikiai supranta ir verslą, ir techninę pusę. Tačiau tai gana retas atvejis. Net ir tada AI sugeneruotą kodą reikia tikrinti beveik taip pat, kaip tikrintum naujoko darbą. Kol kas dirbtinis intelektas mato siaurą kontekstą ir dažnai daro iš pirmo žvilgsnio pagrįstas, bet konkrečiai situacijai netinkamas prielaidas. Dirbtinis intelektas dažnai optimizuoja lokalią problemą, bet nemato visumos. Jis gali pasiūlyti techniškai teisingą, bet praktiškai netinkamą sprendimą: funkciją, ignoruojančią jau egzistuojančius metodus; duomenų bazės migraciją, rašančią gryną SQL vietoje ORM; ar API užklausas, visiškai nepaisančias cache mechanizmų. Tokias klaidas dažniausiai pastebi tik patyręs programuotojas, atidžiai peržiūrėdamas kodą.
Yra nuomonių, kad kodo kokybę irgi pilnai galima atiduoti dirbtinio intelekto agentams: jie parašys testus, ir tai užtikrins sistemos teisingumą. Taip, testai padeda, jais galima daug ką automatizuoti. Taip pat daug problemų galima išvengti įprastais kokybės užtikrinimo įrankiais: kodo sintaksės analizatoriais, statine analize, skenuoti, ar sistema nenaudoja pasenusių bibliotekų ir pan. Tai žinomi įrankiai, kurie padeda ir žmogiškiems programuotojams. Bet per automatizuotus testus nepatikrinsi architektūros nuoseklumo, sistemos atitikimo verslo poreikiams (kurie dažnai būna sunkiai apibrėžti), sisteminės rizikos. Tam reikia gero supratimo, kaip sistema įsilieja į verslo procesus.
Kuo paprastesnis projektas, kur mažai vartotojų ir paprastas verslo procesų sudėtingumas – ten dirbtinis intelektas puikiai tinka. Kuo sistema sudėtingesnė, kuo daugiau vartotojų ją naudoja, kuo ilgiau ji turės gyvuoti – tuo reikia daugiau protingos priežiūros, patirties ir sisteminio mąstymo. Dirbtinį intelektą reikia stipriai laikyti už rankos. Pagrindiniai sistemų principai vis dar išlieka: paprasta yra geriau nei sudėtinga, perrašymas vien dėl perrašymo yra pavojingas, kuo mažiau kodo, tuo geriau.
Mūsų užduotis yra sudėtingumo chaoso valdymas. Atpigęs kodo rašymas vilioja pamesti per dešimtmečius išmoktas inžinierių pamokas ir lengvai nueiti chaoso didinimo keliu. Išmintis yra žinoti KĄ verta daryti: ne visko reikia vien dėl to, kad gali.