„Visada spėliojama, kaip generatyvus dirbtinis intelektas (AI) galėtų paveikti įvairių profesijų ateitį. Programinės įrangos inžinerija nėra išimtis.
2024 m. vasario 21 d. šiame laikraštyje skaitėme antraštę, kad „programuotojai turėjo savo dieną“, nors, tiesą sakant, straipsnis turi visiškai kitokią esmę. Balandžio 5 d. skaitėme apie „Programėlių kūrėjus be programavimo žinių“ apie tai, kaip technologijas mylintis tėvas, neturintis jokių specialių žinių, sukūrė programėlę savo „iWatch“, kurią galėjo naudoti teisėjavimo rezultatams įrašyti.
Nebuvo paminėta, kad panašios programėlės ir jų šaltinio kodas jau yra internete, todėl naudojamos AI kūrybinės veiklos apibendrinimas yra bent jau abejotinas. Tokios antraštės ir straipsniai palieka įspūdį, kad programinės įrangos inžineriją vidutinės trukmės laikotarpiu gali atlikti mašinos ir kad augantis kvalifikuotų darbuotojų trūkumas pagrindinėje skaitmeninės transformacijos srityje gali išsispręsti savaime.
Yra priešingai. Šiame įraše apmąstome programinės įrangos inžinerijos esmę, kad pabrėžtume žmogaus poreikį „vairuotojo vietoje“. Mes nenorime tik pakartoti truizmo, kuris dažnai skelbiamas kitoms profesijoms, kurioms dirbtinis intelektas padės, bet nepakeis. Vietoj to norime konkrečiai atsakyti į klausimą, kodėl taip yra. Įtariame, kad pagrindinės šio straipsnio idėjos gali būti perkeltos ir į kitas profesijas.
Programinės įrangos inžinerija
Programinės įrangos inžinieriai kuria programinės įrangos sistemas. Intelektualus ir kūrybinis pasiekimas yra poreikių atpažinimas ir supratimas ir jų pavertimas programinės įrangos sistema, kuri tenkina šį poreikį. Realaus fizinio pasaulio reiškiniai, struktūros ir iššūkiai paverčiami virtualiomis techninėmis programinės įrangos struktūromis.
Šiam procesui būtinas gebėjimas atpažinti poreikį, techninės srities supratimas, taip pat specifinis taikymo kontekstas ir žinios apie programinės įrangos techninę sritį. Programinės įrangos inžinieriai taip pat turi sugebėti suprasti ir tiksliai suformuluoti sudėtingus ryšius taip, kad juos būtų galima pritaikyti programinės įrangos inžinerijai. Tai paprastai vadinama gebėjimu modeliuoti arba abstrahuoti techninėse srityse.
Žingsnis nuo poreikio iki IT sistemos paprastai yra per didelis, kad jį būtų galima žengti iškart. Štai kodėl programinės įrangos inžinerija nustatė tarpinius žingsnius, bent jau konceptualiai. Šie tarpiniai žingsniai gali būti suprantami, kaip perėjimai nuo faktinių poreikių prie rašytinių vartotojo reikalavimų, kaip perėjimai nuo vartotojo prie sistemos reikalavimų, kaip perėjimai nuo sistemos reikalavimų prie sistemos projektų ir, galiausiai, kaip perėjimai nuo projektų prie vykdomojo kodo. Patirtis parodė, kad atliekant visus šiuos perėjimus dažnai pasitaiko klaidų.
Neteisingai suprastas poreikis greitai sukelia netinkamus vartotojo reikalavimus ir, galiausiai, programinės įrangos sistemą, kuri išsprendžia neteisingą problemą. Didelis skirtumas, ar realus poreikis yra patekti į prekybos centrą be automobilio (viena išeitis: dviratis), ar maisto produktus iš prekybos centro nugabenti į namus (kitas sprendimas – pristatymo paslauga). Panašiai vartotojo reikalavimai gali būti lengvai paverčiami netinkamais sistemos reikalavimais. Pavyzdžiui, reikalavimas leisti tūkstančiams studentų užduočių sprendimus pateikti elektroniniu būdu, gali paskatinti manyti, kad sistema su pertekliniais serveriais yra būtina. Tačiau lengvesnis sprendimas – terminą nustatyti sekmadienio rytą trečią valandą, kad būtų išvengta perkrovų. Ir taip toliau: Sistemos reikalavimai gali sukelti dizainą, kuris vėliau nebus keičiamas arba sukelti saugumo problemų. Šių dizainų įgyvendinimas kode taip pat gali sukelti klaidų.
Nuo techninės srities ir pasirinkto programinės įrangos kūrimo proceso priklauso, ar minėti artefaktai apskritai yra sukuriami. Pavyzdžiui, kuriant judrią (angl., agile) programinę įrangą, daugelis minėtų veiklų yra sujungiamos. Nepriklausomai nuo kūrimo proceso, programinės įrangos kūrimas susideda iš daugybės sprendimų ir pasirinkimo tarp galimų variantų, kurie taip pat apima prieštaringų tikslų nustatymą ir sprendimą.
Šį procesą apsunkina tai, kad jis vyksta dinamiškoje aplinkoje. Poreikiai, rinkos sąlygos, konkurencinė aplinka, reglamentai ir techninė infrastruktūra nuolat kinta. Priešingai, nei aparatinė įranga, programinė įranga leidžia tokius nuolatinius koregavimus dėl savo neapčiuopiamos prigimties, dėl kurios ji yra pagrindinė naujovių varomoji jėga. Todėl programinės įrangos kūrimas nėra linijinis procesas be kita ko, paaiškina judrių kūrimo metodų patrauklumą.
Kūrimo procese yra pasikartojančių elementų. Daugelis poproblemų ir jų sprendimų jau žinomi tiek verslo, tiek technikos srityse. Šios žinios pasireiškia empirinėmis žiniomis, programinės įrangos struktūriniais modeliais, specializuotomis programavimo kalbomis ar bibliotekomis, kurios leidžia pakartotinai panaudoti funkcijas. Tačiau visada yra tikras pavojus supainioti esamą problemą su panašia, bet ne identiška problema, o tai gali lemti netinkamą sprendimą. Programinės įrangos kūrimas labai priklauso nuo konteksto, todėl pakartotinis problemų aprašymų ir sprendimų naudojimas ne visada akivaizdus.
Be gebėjimo kurti modelius, labai svarbūs ir kiti programinės įrangos inžinerijos įgūdžiai: bendravimas, prieštaraujančių tikslų atpažinimas ir jų sprendimas, pasikartojančių problemų ir sprendimo komponentų išmanymas bei suvokimas, kada šie komponentai neatitinka esamo konteksto. Be to, abstraktūs modeliai konvertuojami į techninį kodą. Šis įgyvendinimas dar reikalauja algoritminio mąstymo, t. y. gebėjimo suskaidyti norimą funkcionalumą į keletą atskirų veiksmų, kuriuos galima efektyviai atlikti mašinoje. Galiausiai programinės įrangos inžinieriai turi sugebėti suprasti ir įvertinti esamus reikalavimų dokumentus, architektūrą ar kodą, jei jų darbas yra išlaikyti ir toliau tobulinti esamą kodą, kai kurios dalys iš šio kodo yra dešimtmečių senumo.
Generatyvus AI
Taip sakant, atrodo akivaizdu, kad daugelio aprašytų užduočių dirbtinis intelektas iš esmės negali atlikti. Taip yra todėl, kad šios užduotys reikalauja sprendimų, kuriuos galima priimti tik giliai suvokus konkrečius poreikius ir galimų sprendimų skirtumus. Pagrindinis mūsų argumentas yra tas, kad AI negali „atspėti“ šių poreikių. Vietoj to labai svarbu, kad žmogus palaipsniui daugiau sužinotų apie iš tikrųjų pageidaujamą kuriamos sistemos funkcionalumą ir suprastų tikslų konfliktus kartotiniame procese, kaip tai praktikuojama, kuriant judrią programinę įrangą. Galiausiai kažkas turi sugebėti išreikšti, ko tiksliai nori vartotojai, tokia forma, kurią būtų galima naudoti programinės įrangos technologijoje. Kaip AI turėtų sugebėti tai padaryti ex nihilo?
Daugelis iš mūsų susiduria su sunkumais diktuodami el. laišką. Vietoj to pradedame rašyti, taisyti, užsirašinėti, pastebėti savo samprotavimo trūkumus ir keisti toną. Rašydami mąstome taip, kaip Kleistas aprašė savo esė „Laipsniškas minčių kūrimas kalbant“. Kodo kūrimas vyksta panašiu procesu, kaip ir kitų programinės įrangos inžinerijos artefaktų kūrimas. Šis iteracinis procesas veikia būtent dėl to, kad jis yra lėtas ir todėl, kad galime tiesiogiai patikrinti, kas ką tik parašyta/pasakyta/užkoduota/nurodyta, ir prireikus tai pataisyti: judame link priimtinos būsenos.
Idėja, kad galėtume iki galo, nuosekliai ir tiesiai pasakyti, koks jos pageidaujamas funkcionalumas net ir paprastai sistemai, pasirodė nereali. Toks vienkartinis kodo generavimas daugeliu atvejų atrodo neįmanomas. Tai tiesa ne tiek dėl to, kad jo vertimas į kodą gali būti techniškai neįmanomas, kiek dėl to, kad įvestis paprastai yra pernelyg bloga generuojamajam AI.
Šis neadekvatumas atsiranda dėl neišsamumo, neapibrėžtumo, nenuoseklumo ir tikrojo poreikio nesupratimo. Neužbaigtumą galima statistiškai pataisyti tiek problemos aprašymo, t.y. specifikacijos, arba generatyvinio AI atveju, užuominos, tiek sugeneruoto kodo lygmeniu: AI užpildo spragas greičiausiai, t.y. dažnai pasitaikančia informacija, pagrįsta treniruočių duomenimis. Tai gali būti tinkama, jei problema iš tikrųjų yra standartinė tos srities problema. Tačiau tai taip pat gali būti visiškai netinkama.
Vienas iš argumentų šiame kontekste yra tas, kad programuotojų vaidmenyje dirbantys programinės įrangos inžinieriai šiandien dažnai nesielgia kitaip, net ir be AI: sprendimai, siūlomi internete tokiuose forumuose kaip „Stack Overflow“, dažnai perkeliami į savo kodą. Tačiau žinome, kad, pavyzdžiui, saugos požiūriu svarbių programinės įrangos komponentų srityje tai dažnai sukelia nesaugų kodą, be to naudojimo kontekstas šiek tiek skiriasi ir nukopijuoto kodo subtilybės nėra suprantamos.
Neaiškumas dažnai yra kalbinio pobūdžio, bet kartais ir konceptualus. Taip dažnai būna, kai žinios apie techninę sritį paliekamos numanomos arba suformuluotas neteisingai. Viena iš didžiausių generatyvaus AI privalumų yra tai, kad šios kontekstinės žinios yra netiesiogiai prieinamos. Tačiau ar šios kontekstinės žinios visada yra teisingos, išsamios ir adekvačios nagrinėjamam prašymui, galima atsakyti tik statistiškai: tipiškiausiu atveju, galbūt!
Todėl neišsamumo ir neapibrėžtumo sprendimas gali atsirasti tiesiogiai, kai sukuriamas artefaktas, jei generatyvinis AI tiesiog pasirenka „tipiškesnį“ atvejį. Tačiau sprendimas taip pat gali vykti kaip kitos darbo eigos dalis: AI atkreipia dėmesį į įtariamą neapibrėžtumą ir neišsamumą ir siūlo patobulinimus, remdamasi mokymo duomenimis. Čia matome tikrąjį generatyvaus AI naudojimo programinės įrangos inžinerijoje potencialą.
Bet kuriuo atveju, programinės įrangos inžinierius turės patikrinti ir įvertinti, ar generatyvinio AI sukurtas artefaktas yra profesionaliai ir techniškai tinkamas. Paprastai tai sukels kartotinį kūrimo ir peržiūros procesą, kaip ir be AI. Tada kyla klausimas, ar ekonomiškai naudingiau kodą ar specifikaciją parašyti tiesiogiai patiems, be AI pagalbos. Tai priklauso nuo: esant sudėtingiems, specifiniams reikalavimams, rankinis kūrimas gali būti efektyvesnis, o dirbtinis intelektas gali generuoti standartinį kodą labai tiksliai. Tas pats pasakytina apie paprastus ir sudėtingesnius el. laiškus.
Tai gali būti esminis skirtumas tarp programinės įrangos inžinerijos ir kitų profesijų ar gyvenimo sričių. Matyt, kuriant kartu su generuojamuoju AI mums reikia sudėtingo orakulo – žmogaus, kuris galėtų spręsti apie sukurto artefakto – teisingumą, išsamumą ir tinkamumą. Meilės laiškams, sveikinimams, tekstams socialinėje žiniasklaidoje, katalogų modelių vaizdams ir reklaminiams vaizdo įrašams orakulo užduotis yra palyginti paprasta: dažnai iš karto galite pamatyti, ar artefaktas atitinka paprastai numanomus reikalavimus. Dėl sudėtingesnių artefaktų, tokių, kaip problemų, kurios dar nebuvo išspręstos šimtus kartų, kodo, atrodo įmanoma ir net tikėtina, kad pastangos, susijusios su kartotiniu kūrimu ir, svarbiausia, peržiūra, tampa pernelyg didelės arba tiesiog nėra pakankamai malonios.
Pabaiga
Galiausiai trys svarstymai.
Pirma, mūsų perspektyva nesiekiama sudaryti įspūdžio, kad generuojantis AI nėra naudingas programinės įrangos inžinerijoje. Priešingai, matome didelį tam tikrų programavimo kalbų ir užduočių potencialą, pavyzdžiui, kodo paaiškinimą, komentarų kūrimą, tinkamų bibliotekos funkcijų radimą ir standartinio kodo kūrimą. Mes ir toliau manome, kad generatyvinis AI žymiai pagerins reikalavimų inžinerijos procesą, t. y. tas veiklas, kuriose atsižvelgiama į poreikius ir reikalavimus. Tačiau mes bandėme išsiaiškinti, kur yra pagrindinės generatyvaus AI ribos programinės įrangos inžinerijoje apskritai – tai nereiškia, kad negali būti puikių galimybių programinei įrangai sukurti, naudojant generatyvųjį AI labai specifiniams, gerai suprantamiems ir galiausiai nekritiškiems kontekstams.
Antra, turėtume išlaikyti realius lūkesčius dėl generatyvaus AI programinės įrangos inžinerijoje. Kiekvienas, kuris tikisi, kad AI visada sukurs teisingą, išsamią ir tinkamą programinę įrangą, nusivils. Kaip ir kitose profesijose, čia dirba įvairių įgūdžių turintys programinės įrangos inžinieriai. Šiame rašinyje neskyrėme patyrusių programinės įrangos inžinierių ir pradedančiųjų. Net ir šiandien mažiau kvalifikuotų ar patyrusių inžinierių gaminiai kartais yra programinės įrangos sistemos, kurios ne visada siūlo funkcionalumą ir patikimumą, kokio turėtų. Logiškas tolesnis klausimas yra, ar generuojantis AI gali būti toks pat geras kaip blogi programinės įrangos inžinieriai. Gal, jis gali.
Mūsų pagrindinis argumentas pabrėžia sunkumus suformuluoti raginimą, apimantį tinkamą specifikaciją, ir lieka nepakitęs.
Trečia, turime pagalvoti, ar ir kaip turėtume pritaikyti programinės įrangos inžinierių išsilavinimą. Autorius laikosi nuomonės, kad stebėtina, kad esminių pokyčių baziniuose mokymuose nebūtina: kad galėtumėte įvertinti programinės įrangos inžinerijos artefaktus, pirmiausia turite mokėti juos kurti patys. Galbūt, tai irgi skiriasi nuo kitų disciplinų. Taigi, jei pradiniame mokyme šiek tiek sustiprinsime gebėjimą vertinti kodą (testavimo, skaitymo metodus) ir toliau treniruosime aptartus modelio kūrimo įgūdžius, rytojaus programinės įrangos inžinieriai galės įveikti rytojaus iššūkius su AI pagalba. Sudėliojus pagrindus, galima ir reikia išmokyti programinės įrangos raginimų kūrimo. Bet mums atrodo, kad per ankstyvas AI asistentų naudojimas kodams generuoti kenkia sprendimų priėmimo sugebėjimui." [1]
1. KI wird Softwareingenieure nicht ersetzen! Frankfurter Allgemeine Zeitung (online) Frankfurter Allgemeine Zeitung GmbH. Sep 11, 2024. Von Alexander Pretschner
Komentarų nėra:
Rašyti komentarą