Kuidas ma ehitan tarkvara ilma arendusmeeskonnata

Minult küsitakse peaaegu igal kohtumisel, kuidas on võimalik üksi arendada ja käigus hoida platvormi, millel on keerukas andmemudel, mitmekeelne kasutajaliides, maksed, integratsioonid, turvanõuded ja andmekaitse. Vastus ei ole maagia ja see ei ole tasuta. Investeering ei kadunud kuhugi, ta lihtsalt kolis palgalehelt riistvarasse, arvutusvõimsusse, tarkvarasse ja otsustusvõimesse. Siin on aus kirjeldus sellest, kuidas see minu laua taga päriselt käib, koos kohtadega, kus see läheb valesti.

Kui keegi küsib, mitu arendajat mul on, vastan ausalt, et mitte ühtegi. Tavaliselt järgneb paus. Ja pärast pausi tuleb teine küsimus, mis on esimesest palju parem: kes siis vastutab?

See ongi tegelik küsimus. Tarkvara ei ole kunagi olnud ainult koodiridade probleem. Tarkvara on vastutuse probleem.

Keegi peab otsustama, mida ehitada ja mida mitte. Keegi peab mõistma, millist kasutaja probleemi lahendatakse, hoidma tervikpilti, määrama arhitektuuri, kontrollima riske ja ütlema lõpuks, et see lahendus on piisavalt hea, et päris inimeste ette minna. Mul ei ole püsivat palgalist arendusmeeskonda, aga see ei tähenda, et arenduse rollid oleksid kadunud. Tootejuhtimine, ärianalüüs, arhitektuur, programmeerimine, turvakontroll, testimine, disainikriitika ja dokumenteerimine on endiselt vajalikud. Need funktsioonid on lihtsalt jaotunud teisiti: osa tööst teevad eri keelemudelid, osa automatiseeritud agendid, osa kohalik infrastruktuur, osa välised eksperdid. Kõige kriitilisem osa jääb mulle. Mina vastutan selle eest, et kõik need osad moodustaksid ühe süsteemi.

Olen tehnoloogia sees olnud alates 1994. aastast, kui panin kokku oma esimese arvuti. Tehisintellektiga olen tegelenud sisuliselt iga päev alates 2022. aasta lõpust. Selle ajaga ei ole muutunud ainult tööriist. Muutunud on töö enda kuju.

Investeering ei kadunud. Ta muutis kuju

Alustan sellest, millest AI-teemalistes edulugudes sageli üle libisetakse: odav see mudel ei ole.

Mul on mitu võimekat arvutit, millel on tugevad protsessorid, palju mälu ja võimsad videokaardid. Videokaarte ei ole vaja mängimiseks, vaid selleks, et osa keelemudeleid ja agente saaks töötada kohapeal minu enda masinates. Just see annab võimaluse hoida tundlikumaid töövooge enda kontrolli all: mõni koodiosa, kliendi andmestruktuur, äriloogika või juriidiline mustand ei pea kunagi jõudma välise teenusepakkuja süsteemi.

Siin on aus täpsustus, mille ma varem oleksin vahele jätnud. Kohaliku mudeli kasutamine ei tähenda automaatselt privaatsust ega turvalisust. Kui ligipääsuõigused on valed, varukoopiad kaitsmata, logid kontrollimata või võtmed laiali eri masinates, ei päästa sind see, et mudel töötab sinu enda toas. Kohalik mudel on üks kaitsekiht, mitte kogu turvastrateegia.

Kolm minu masinatest töötavad Ubuntu peal, sest avatud lähtekoodiga keskkonnas on automatiseerimist, agentide tööd ja süsteemide omavahelist ühendamist lihtsam juhtida. Neljas on Apple'i arvuti, mille ülesanne on teha seda, mida Apple'i ökosüsteem nõuab: kompileerida, allkirjastada ja testida rakendusi ning valmistada neid ette App Store'i jaoks. Ta ei ole eraldi töökoht, mille taga keegi päev läbi istub. Ta on osa tervikust: teised masinad valmistavad töö ette, tema teeb oma osa ja tulemus liigub tagasi ühisesse arendusvoogu.

Masinate vahel peab olema kiire ja usaldusväärne võrk. See kõlab igava tehnilise detailina ja just selliste detailide peal süsteemid kas töötavad või ei tööta. Kui masinad ei saa kiiresti vahetada konteksti, faile, tööülesandeid ja tulemusi, ei ole sul hajutatud arenduskeskkonda. Sul on lihtsalt neli arvutit.

Veel olulisem kui masinate arv on ühine töökorraldus: ühine versioonihaldus, dokumenteeritud arhitektuur, jälgitavad muudatused, eraldatud arenduskeskkonnad, automaatsed testid, õiguste haldus ja võimalus vigane versioon kiiresti tagasi pöörata. Ilma nendeta ei ole neli masinat võimekus. Need on neli uut kohta, kus midagi võib valesti minna.

Mida see kulude keeles tähendab. Traditsioonilises mudelis maksab ettevõte eelkõige inimeste tööaja eest. Palgale lisanduvad maksud, puhkused, haiguspäevad, värbamine, sisseelamine, juhtimine ja risk, et oluline teadmine lahkub koos inimesega. Minu mudelis jagunevad kulud teisiti: riistvara, elekter, tarkvaralitsentsid, mudelite kasutus, pilveteenused, varundus, monitooring ja vajaduse korral välised eksperdid. Tugevad mudelitellimused ja arvutusvõimsus maksavad suurema arendusmahu puhul sadu kuni tuhandeid eurosid kuus. Riistvara amortiseerub, vajab hooldust ja vananeb.

Seetõttu oleks vale väita, et püsikulu kadus. Täpsem on öelda, et osa jäigast püsikulust muutus juhitavaks kasutuskuluks, mida saab suurendada või vähendada vastavalt sellele, kui intensiivne on parasjagu arendus. Juhi jaoks tähendab see, et arendusvõimekus ei ole enam ainult kord aastas tehtav personalieelarve otsus. Osa sellest on muutunud kraaniks. Kraan töötab muidugi ainult siis, kui torustik on juba ehitatud.

Ja üks piir, mille ma ütlen kohe välja. Kui sul on vaja ühte maandumislehte ja kahte kontaktivormi, ei ole sul vaja nelja masinat ega agentide süsteemi. Ühekordse projekti puhul on mõistlikum tellida konkreetne töö ja minna eluga edasi. Selline infrastruktuur hakkab end õigustama alles siis, kui arendus ei lõpe käivitamisega: kui sul on pidev arendusvoog, mitu toodet, regulaarne hooldus, palju integratsioone ja vajadus kiiresti katsetada, parandada ja ümber ehitada.

Kõige väärtuslikum töö toimub enne esimest koodirida

Kogu protsess algab ideest ja lõpeb teostusega. Nende kahe vahele jääb osa, mida ma pean kogu süsteemi kõige väärtuslikumaks.

Enne kui midagi ehitatakse, pean ma oma idee läbi vaidlema. Agendid küsivad küsimusi, otsivad vastuolusid, pakuvad alternatiive ja sunnivad mind oma eeldusi põhjendama. Ma pean selgitama, kelle probleemi lahendatakse, miks olemasolev lahendus ei sobi, milline on minimaalne vajalik tulemus ja millist riski ma olen valmis võtma. Alles pärast seda sünnib teostusplaan.

Olen elus liiga palju kordi näinud, kuidas tugev meeskond ehitab kiiresti valmis vale asja. See ei juhtu tavaliselt sellepärast, et inimesed oleksid ebapädevad. See juhtub sellepärast, et ebamugavad küsimused jäid õigel ajal küsimata. Keegi ei tahtnud hoogu peatada, keegi ei soovinud kahtluse alla seada juba tehtud otsust, keegi ei öelnud, et lähteülesanne on udune.

Keelemudelil ei ole minuga suhet, mida ta peab hoidma. Samas ei muutu ta iseenesest heaks kriitikuks. Kui ma palun tal olla toetav ja ideed edasi arendada, teeb ta täpselt seda. Kui ma tahan tegelikku vastuvaidlust, pean andma talle selle rolli, nõudma vastuväiteid ja laskma tal otsida põhjuseid, miks minu plaan võib ebaõnnestuda.

AI väärtus ei seisne selles, et tal oleks alati õigus. Väärtus seisneb selles, et ta võimaldab tekitada odava vaidluse enne kallist ehitamist. Kui vastuolu avastatakse enne koodi, maksab parandamine mõne tunni. Kui sama vastuolu leitakse pärast andmemudeli, kasutajaliidese ja integratsioonide valmimist, tähendab see nädalaid ümberehitust. Koodi kirjutamise kiirus on seetõttu vähem oluline kui otsustamise kvaliteet enne koodi.

Kuidas üks arendustsükkel päriselt välja näeb

Agentne arendus ei tähenda, et ma kirjutan vestlusaknasse ühe lause ja hommikuks on valmis ettevõte. Töö käib etappide kaupa.

1. Probleem. Kõigepealt sõnastan mina probleemi. Mitte funktsiooni, vaid probleemi. „Lisa kustutamisnupp" on funktsioon. „Inimesel peab olema võimalik oma andmete kasutamine lõpetada nii, et andmed eemaldatakse, kustutamine on jälgitav ja sama profiili ei impordita järgmisel nädalal automaatselt tagasi" on probleem. Need kaks lähteülesannet toodavad täiesti eri tarkvara.

2. Vaidlus. Seejärel lasen eri mudelitel lähteülesande lahti võtta. Millised on varjatud eeldused? Millised andmed on seotud teiste tabelitega? Kas kustutamine tähendab füüsilist kustutamist, anonüümimist või ligipääsu lõpetamist? Milline osa tuleb säilitada raamatupidamise või vaidluste lahendamise tõttu? Mis juhtub aktiivsete broneeringute, maksete ja logidega? Selles etapis ei tohi mudel veel koodi kirjutama hakata. Ta peab kõigepealt mõistma, mida üldse ehitatakse.

3. Teostusplaan. Enne plaani tuleb audit. Agent ei hakka kohe ehitama, vaid kaardistab kõigepealt olemasoleva: millised komponendid seda kohta juba puudutavad, milline loogika seal praegu kehtib ja mida ei tohi lõhkuda. Alles auditi peale koostab üks mudel tehnilise plaani: millised komponendid muutuvad, kuidas andmed liiguvad, milliseid migratsioone on vaja, millised testid tuleb lisada ja kuidas saab muudatuse tagasi pöörata. Teine mudel kontrollib plaani arhitektuuri vaatenurgast, kolmas vaatab andmekaitset ja turvalisust. Kui nad jõuavad eri järeldusteni, ei otsusta enamus. Mina otsustan, milline kompromiss vastab paremini toote eesmärgile, riskitasemele ja süsteemi pikaajalisele loogikale.

4. Ehitus. Peamine arendusmudel teeb muudatuse eraldatud harus. Ta ei saa automaatselt õigust tootmiskeskkonda midagi paigaldada. Ja tal on veel üks piirang, mille tähtsust ma alguses alahindasin: ta tohib muuta ainult seda, mida ülesanne käsib. Agent kipub ülesande kõrval märkama ja „parandama" ka asju, mida keegi ei palunud, ja iga selline heast kavatsusest tehtud kõrvalparandus on kontrollimata muudatus süsteemis. Seetõttu lukustatakse skoop enne ehitust. Kõik, mis jääb sellest välja, dokumenteeritakse eraldi leiuna ja muutub eraldi ülesandeks. Agent kirjutab koodi, testid, andmemigratsioonid ja dokumentatsiooni.

5. Sõltumatu retsensioon. Teised mudelid püüavad lahenduse katki teha. Üks otsib loogikavigu, teine vaatab õigusi ja turvariske, kolmas kontrollib, kas lahendus kordab juba olemasolevat loogikat, neljas vaatab, kas sama tulemust saaks saavutada lihtsamalt. Nende ülesanne ei ole öelda, et töö on hea. Nende ülesanne on leida põhjus, miks seda ei tohiks veel vastu võtta.

6. Testimine. Automaatsed testid kontrollivad nii üksikuid funktsioone kui ka kogu kasutajateekonda. Brauseriagent avab rakenduse, logib sisse, teeb tegevused läbi ja kontrollib, kas tulemus vastab vastuvõtukriteeriumidele. Siin kehtib minu jaoks üks raudne reegel: agent ei tohi väita, et asi töötab. Ta peab seda tõendama. Sõnaline kinnitus „kõik on korras" ei maksa midagi, sest mudel kipub oma tööd usaldama rohkem, kui see väärt on. Tõendus on ekraanipilt, testiraport või logi, mida saab sõltumatult kontrollida. Väide ilma tõenduseta loeb tegemata tööks.

7. Inimese ülevaatus. Mina vaatan üle selle, mida testid ei näe. Kas lahendus käitub kasutaja jaoks loogiliselt? Kas tekst ütleb seda, mida me arvame, et ta ütleb? Kas muudatus sobib ülejäänud tootega? Kas ma olen valmis selle otsuse eest vastutama?

8. Väljalase ja jälgimine. Alles pärast seda liigub muudatus tootmiskeskkonda. Ka siis ei ole töö läbi: süsteem jälgib vigu, jõudlust ja ootamatut käitumist. Kui midagi läheb valesti, peab olema võimalik aru saada, mis muutus, ning taastada kiiresti eelmine töötav versioon.

See ongi tegelik agentne arendus. Mitte üks maagiline käsk, vaid järjestikused vastutuskihid.

Üks ehitab, teised püüavad katki teha

Kasutan ühe arendustsükli jooksul tavaliselt nelja kuni viit eri keelemudelit. Osa neist on suured välised mudelid, osa töötavad kohapeal minu enda masinates. Nad ei tee kõik sama tööd: üks on peamine ehitaja, teised tegutsevad arhitektuurilise retsensendi, turvakontrolli, testija, kriitiku või alternatiivse lahenduse pakkujana.

Miks eri mudelid ja eri tootjad? Sest süsteem kipub enda loodud lahendust kaitsma. Kui sama mudel kirjutab koodi ja hindab seda seejärel ise, võib tulemuseks olla enesekindlus ilma tegeliku sõltumatu kontrollita. Eri mudelitel on eri tugevused, treeningandmed ja pimealad. Üks märkab arhitektuurilist vastuolu, mida teine ei näe. Teine leiab turvariski, mille esimene oma lahenduse sees normaliseeris.

Siin tuleb üks aus piir. Mudelite erimeelsus ei tõesta viga ja nende üksmeel ei tõesta kvaliteeti. Viis mudelit võivad kõik nõustuda ja kõik eksida. Mitme mudeli kasutamine ei ole demokraatia, kus enamus otsustab, mis on tõde. See on kontrollmehhanism, mis suurendab tõenäosust, et nõrk koht tuleb nähtavale enne tootmiskeskkonda jõudmist.

Masin ei maga ja ta võib eksida väga järjekindlalt. Kui ülesanne on selge ja turvaliselt piiritletud, saab agent jätkata analüüsimist, testimist ja parandamist ka siis, kui mina parasjagu ei tööta. See on tohutu võimekus. See on ühtlasi tohutu risk. Masin võib rakendada vale eeldust kümnetes failides, genereerida sadu teste, mis kinnitavad valet käitumist, või optimeerida süsteemi eesmärgi suhtes, mida poleks tohtinud talle üldse anda.

Kiirus ilma väravata ei ole kiirus. See on kontrollimatu tootmisvõimsus.

Seetõttu peab igal ülesandel olema vastuvõtukriteerium. Mis peab muutuma? Mis ei tohi muutuda? Millised testid peavad läbima? Kuidas saab selle tagasi pöörata? Milline mõõdik näitab, et muudatus päriselt töötas? Ilma nende küsimusteta toodab masin ühe ööga rohkem tehnilist võlga, kui inimmeeskond jõuaks nädalaga.

Konkreetne näide: kustutamisnupp ei ole andmekaitse

Võtame olukorra, mis puudutab igat platvormi, mis töötab avalikest allikatest pärit andmetega. Inimest tuleb teavitada, tal peab olema võimalik oma andmeid parandada või nõuda nende eemaldamist.

Esmapilgul tundub kustutamisõigus lihtne funktsioon. Lisame nupu, kustutame kirje ja asi on tehtud. Tegelikult ei ole.

Kui kirje kustutatakse põhiloendist, aga sama inimene on seotud otsinguindeksi, tõlgete, piltide, logide, soovitussüsteemi, statistika või impordijärjekorraga, ei ole küsimus enam ühes andmebaasireas. Ja veel olulisem: kui süsteem impordib avalikke allikaid regulaarselt, võib kustutatud kirje järgmise impordi ajal automaatselt tagasi tekkida. Kasutaja vaates on see selge usalduse rikkumine. Inimene palus enda eemaldada, süsteem kinnitas seda ja mõni päev hiljem on ta jälle nähtav.

Seetõttu ei piisa kustutamisest. Vaja on kustutamise sündmus salvestada, eemaldada seotud andmed vastavalt nende liigile, uuendada otsinguindeksit, katkestada avalik kuvamine ja luua kordusimpordi tõkestus. Samal ajal peab säilima piisav jälg, et hiljem tõendada, mida süsteem tegi ja millal.

Sellise funktsiooni juures ei saa üks mudel lihtsalt kirjutada kustutuskäsku ja kuulutada tööd lõpetatuks. Üks agent analüüsib andmesuhteid, teine kontrollib säilitamiskohustusi, kolmas vaatab, kas sama inimene võib eri allikates esineda eri nimekujuga, neljas proovib süsteemi üle kavaldada ja kirjet uuesti importida. Mina otsustan lõpuks, milline lahendus vastab kasutaja ootusele, äriloogikale ja juriidilisele raamile.

See näide võtab kokku kogu artikli mõtte. Koodi genereerimine oli selle probleemi juures lihtne osa. Raske osa oli otsustada, mida „kustutamine" tegelikult tähendab.

Agent vajab mälu ja viga peab muutuma reegliks

Üks agentse arenduse kõige vähem räägitud probleeme on kontekst.

Inimene, kes on töötanud ettevõttes kolm aastat, mäletab, miks mõni kummaline otsus kunagi tehti. Ta teab, milline klient midagi nõudis, millist integratsiooni ei tohi lõhkuda ja millise näiliselt lihtsa lahenduse proovimine lõppes eelmisel korral halvasti. Agent ei tea seda, kui seda ei ole talle antud. Kui kontekst on laiali vestlustes, inimeste peas ja vanades dokumentides, hakkab iga agent sisuliselt tööle eri ettevõttes.

Just seetõttu on dokumentatsioon agentse arenduse juures tähtsam kui varem, mitte vähem tähtis. Arhitektuuriotsused, andmestruktuurid, API-lepingud, turvanõuded, varasemad vead ja vastuvõtukriteeriumid peavad olema masinloetavad ja versioonihaldusega seotud. Agent peab teadma nii seda, mida süsteem teeb, kui ka seda, miks ta seda just nii teeb. Kui põhjendus puudub, võib järgmine mudel täiesti heauskselt „parandada" ära midagi, mis oli tegelikult teadlik kompromiss.

Aga dokumentatsioon ei ole arhiiv, kaust, kuhu asjad kirja pannakse ja kus nad vaikselt vananevad. Minu süsteemis on ta käivitatav tööjuhis, mida agendid loevad enne igat tööd, ja just sellepärast peab ta olema elus.

See töötab lihtsa tsüklina. Olulisemad korduvad protsessid on kirja pandud tööjuhistena: kuidas me ehitame, kuidas me testime, kuidas me kirjutame, milliseid reegleid me järgime ja milliseid vigu ei tohi korrata. Kui agent alustab tööd, loeb ta kõigepealt vastava juhise ja alles siis hakkab tegema. Ja kui töö käigus tuleb välja viga või parem tööviis, siis ma ei paranda ainult seda konkreetset viga. Ma täiendan juhist, et sama viga ei saaks enam korduda. Viga muutub reegliks. Järgmine töötsükkel alustab juba kõrgemalt tasemelt kui eelmine.

Just see on koht, kus üksiku inimese süsteem hakkab käituma nagu organisatsioon. Inimmeeskonnas elab õppetund tavaliselt selle inimese peas, kes vea tegi, ja lahkub koos temaga. Minu süsteemis elab õppetund kirjas ja versioonihalduses ning teda loeb iga järgmine töötsükkel automaatselt.

Teine pool sellest on ühendused. Agendid ei tööta kopeeri-ja-kleebi kaudu, vaid on standardliideste abil ühendatud otse töövahenditega: kalender, e-post, dokumendid, disainikeskkonnad, arendusvood. Kui agent vajab konteksti, võtab ta selle ise talle lubatud allikatest ja konkreetse ülesande jaoks antud õiguste piires. Kui ta loob tulemuse, paneb ta selle kokkulepitud töövoos õigesse kohta. Iga käsitsi vahelüli, mille ma süsteemist eemaldan, on üks koht vähem, kus info kaob või vananeb.

Ja kolmas pool: seal, kus valmislahendus ei tee täpselt seda, mida vaja, ehitame oma. Loovuse ja produktiivsuse tööriistad, mis jooksevad minu enda riistvara peal ja kasutavad ära just selle tugevusi, mille eest ma olen juba maksnud. Renderdamine, analüüs ja pikad taustatööd, mille jaoks välise teenuse ostmine oleks kallis ja aeglane, käivad kohapeal.

Kokku annab see süsteemi, mis on igal kuul parem kui eelmisel. Mitte sellepärast, et mudelid muutuvad paremaks, kuigi ka see juhtub, vaid sellepärast, et minu enda reeglid, juhised ja mälu kasvavad iga tsükliga. See on sama liitintressi loogika, mida ma olen alati usaldanud raha juures. Siin töötab ta teadmiste peal.

Kood on muutunud odavaks. Organisatsiooniline mälu ei ole.

Arhitekt ei kadunud kuhugi

Kõige ohtlikum eksiarvamus on, et tugev mudel omandab automaatselt kogu süsteemi arhitektuuri.

Agent kirjutab korrektse komponendi, parandab vea või loob toimiva integratsiooni. Samas ei pruugi ta näha, kuidas sama lahendus mõjutab süsteemi kolme kuu pärast, kui kasutajaid on kümme korda rohkem, andmemudel muutub või lisandub uus regulatiivne nõue. Kohalikult hea lahendus võib olla terviku jaoks halb lahendus.

Just siin jääb inimesele roll, mida ei saa delegeerida parema käsuga: terviku omamine. Keegi peab teadma, kus asuvad kriitilised sõltuvused, mida võib kiiresti muuta ja millist osa ei tohi puudutada ilma migratsiooniplaanita. Keegi peab otsustama, millal lisada uus tehnoloogia ja millal keelduda järjekordsest ahvatlevast tööriistast. Kui seda inimest ei ole, ei teki arhitektuuri iseenesest. Tekib heade üksiklahenduste hunnik, mis aja jooksul enam omavahel ei kõnele.

Agentide kasutamine ei kaota arhitekti rolli. See muudab arhitekti töö veel olulisemaks.

Viimane kvaliteedikiht on inimene

Masin võib kinnitada, et nupp töötab. Inimene märkab, et nupu tekst tekitab vale ootuse. Masin võib mõõta, et leht avaneb kiiresti. Inimene näeb, et kasutaja ei saa aru, mida temalt küsitakse.

Eriti kehtib see keele kohta. Inglise keeles on mudelite väljund juba väga tugev. Eesti keelega tuleb olla tunduvalt tähelepanelikum, sest väiksema keele puhul ei pruugi viga olla grammatikas. Viga võib olla toonis, tähendusvarjundis või selles, et tehniliselt korrektne lause ei kõla nii, nagu ükski eestlane päriselt räägiks. See on väikese keele hind ja see on odav hind.

Seetõttu loeb inimene lõpuni üle. Mina loen.

Turvalisus on tööviis, mitte tööpakett

Turvalisusega tehakse sageli sama viga mis andmekaitsega: teda käsitletakse eraldi tööpaketina, mis lisatakse lõpus. Tegelikult peab turvalisus olema süsteemi tööviis: vähima vajaliku õiguse põhimõte, eraldatud keskkonnad, turvaline võtmete haldus, sõltuvuste kontroll, logimine, varukoopiad ja taastamisplaan.

Kõige olulisem turvaelement ei ole see, et süsteem ei tee kunagi viga. Sellist süsteemi ei ole olemas. Kõige olulisem on see, et viga oleks kiiresti nähtav, piiratud ja tagasipööratav.

Agent ei tohiks saada rohkem ligipääsu, kui tal konkreetse ülesande jaoks vaja on. Arendusagent ei pea teadma tootmiskeskkonna maksevõtmeid, teksti analüüsiv mudel ei vaja ligipääsu kogu kliendiandmebaasile, testimisagent ei pea saama muuta arhitektuuri. Mida võimekamaks mudelid muutuvad, seda olulisemaks muutub õiguste piiramine. Väga võimekas agent, kellel on liiga palju õigusi, ei ole lihtsalt hea töötaja. Ta on süsteemne risk.

Õiguste kõrval on mul veel üks kiht, mida ma nimetan punase joone väravateks. Teatud klassi muudatused nõuavad alati inimese eraldi luba, ükskõik kui kindel agent oma lahenduses on: andmebaasi struktuuri muutmine, massuuendused, kustutamised ja kõik, mis puudutab makseid või isikuandmeid. Agent võib sellise muudatuse ette valmistada, põhjendada ja testida, aga käivitada ta seda ei saa. Nupp on minu käes. See ei ole umbusaldus masina vastu. See on sama loogika, mille järgi pangas ei tee suurt ülekannet kunagi üks inimene üksi.

Juriidika ja koht, kus sa maksad kaks korda

Needsamad mudelid ei tegele ainult koodiga. Nad aitavad luua turundusmaterjale, analüüsida lepinguid, struktureerida nõudeid ja valmistada ette juriidilisi dokumente. Õigesti kasutatuna teevad nad ära suure osa eeltööst: koguvad materjale, võrdlevad versioone, tuvastavad vastuolusid ja struktureerivad mustandi.

On suur vahe, kas jurist alustab tühjalt lehelt või saab enda ette dokumendi, milles äriline eesmärk, faktid, osapooled ja riskikohad on juba selgelt kirjeldatud.

Siin on tingimus, mida ei tohi vahele jätta: algmaterjal peab olema tõesti hea. Kui sa annad juristile halva mustandi, puudulikud faktid või dokumendi, mille loogika ei pea, kirjutab ta selle ümber oma keele ja käekirja järgi. Siis maksad sa kaks korda: esmalt oma aja eest mustandi tegemisel ja seejärel juristi aja eest, kes alustab sisuliselt nullist.

AI ei muuda juristi üleliigseks. Ta võimaldab juristil alustada kõrgemalt tasemelt ja keskenduda sellele, mille pärast teda päriselt palgati: tõlgendusele, riskile, vastutusele ja professionaalsele hinnangule. Mudel võib ette valmistada suurema osa dokumendist. Viimane osa sisaldab ikkagi suurema osa vastutusest.

Neli kohta, kus see mudel läbi kukub

Ma ei taha, et see tekst kõlaks reklaamina. Olen näinud ka seda, kuidas sama lähenemine toodab kiiresti palju halba tarkvara.

Keegi ei oma tervikpilti. Agent lahendab talle antud ülesande, aga ei kanna vastutust kogu süsteemi eest. Kui inimene ei hoia arhitektuuri, toote eesmärki ja riske koos, ei teki tervikut. Tekib funktsioonide kogum.

Süsteem retsenseerib iseennast. Kui ehitus ja kontroll tulevad samast mõttemustrist, jääb vigane eeldus vaidlustamata. Retsensioon peab tulema piisavalt sõltumatust kohast ja lõppema päris testidega.

Kontekst laguneb. Kui otsused, nõuded ja varasemad õppetunnid pole dokumenteeritud, alustab iga agent tööd eri ettekujutusega sellest, millist süsteemi ehitatakse. Tulemuseks on vastuolud, dubleerimine ja aeglane arhitektuuriline lagunemine.

Andmekaitse ja turvalisus jäetakse lõppu. GDPR ei ole funktsioon, mille sa lisad nädal enne käivitamist. Kui andmemudel ei ole algusest ehitatud nõusoleku, teavituse, kustutamise ja jälitatavuse peale, ei paranda seda hiljem hea käsuga. Siis ehitad süsteemi ümber. See on kõige kallim viga, mida ma selles valdkonnas näinud olen.

Ja üks aus tunnistus lõppu. Igas süsteemis on koht, kus riski on rohkem, kui ma tahaksin. Minu töö ei ole teeselda, et seda kohta pole olemas. Minu töö on hoida see nähtaval, mõõdetaval ja kontrolli all ning mitte teha seal ühtegi liigutust ilma teadliku otsuseta.

Süütunne ja sõit Tallinnast Tartusse

Olen kuulnud, et paljud inimesed, kes on agentse arendusega alustanud, tunnevad ennast millegipärast süüdi. Eriti need, kellel puudub klassikaline tarkvaraarenduse taust. Nad ei tea täpselt, kuidas iga koodirida sündis. Neile tundub, et midagi sai valmis liiga kiiresti või peaaegu nagu maagia. Sellest kasvab kummaline tunne, nagu ei oleks tulemus päriselt nende oma.

Ma väidan vastupidist.

Kui sa sõidad Tallinnast Tartusse, pead sa teadma, kust sa alustad ja kuhu sa tahad jõuda. Sinu jaoks on oluline, et sa jõuaksid kohale turvaliselt, mõistliku ajaga ja sinna, kuhu sa tegelikult minna kavatsesid. Sa ei pea sõidu ajal mõtlema, kuidas iga silinder töötab, kui palju õli mootoris liigub või kuidas väntvõll jõu ratasteni kannab. Sa ei pea olema mootoriehitaja, et autot juhtida.

Aga sa pead tundma liiklusmärke. Sa pead teadma, kummal teepoolel sõita, millal pidurdada, millal teed anda ja mida teha, kui armatuurlaual süttib punane tuli. Ja sa pead aru saama, millal sul endal on piisavalt pädevust ja millal tuleb auto spetsialisti juurde viia.

Täpselt sama kehtib agentse arenduse kohta. Sa ei pea teadma iga koodirea sünnilugu. Sa pead teadma, kuhu süsteem liigub, millistele nõuetele ta peab vastama ja millised piirid ei ole läbiräägitavad.

Andmekaitse on liiklusmärk. Turvalisus on liiklusmärk. Arhitektuur on tee kvaliteet. Testid on armatuurlaud. Logid on must kast. Varukoopia on võimalus pärast õnnetust üldse taastuda.

Kui sa neid asju ei tunne, ei ole sa vaba juht. Sa oled lihtsalt inimene, kes ei tea, et ta sõidab punase tulega.

Süütunne ei ole probleem. Liiklusmärkide mittetundmine on.

Mida juht sellest tegelikult ostab

Kui kogu see süsteem ärikeelde tõlkida, on tulemuseks viis asja.

Kiirus. Arendusvõimekus ei sõltu enam tööpäeva pikkusest ega sellest, millal kõik vajalikud inimesed ühise koosolekuaja leiavad.

Paindlikum kulustruktuur. Osa püsikulust saab muuta vastavalt kasutusele juhitavaks arvutus- ja teenusekuluks.

Kontroll. Tundlikumaid töövooge saab hoida enda infrastruktuuris ja otsustada täpsemalt, millised andmed välisesse teenusesse liiguvad.

Järjepidevus. Hästi dokumenteeritud süsteemis ei kao teadmine ühe inimese või ühe vestlusakna kadumisega. Ja kuna iga õppetund muutub reegliks, on süsteem igal kuul parem kui eelmisel.

Selge vastutus. Otsust ei saa peita hajusa meeskonna, lõputu koosoleku ega tarnija selja taha. Keegi peab lõpuks ütlema, et see lahendus läheb tootmisse ja tema vastutab.

Viimane neist on kõige väärtuslikum. AI võib muuta arenduse odavamaks ja kiiremaks, aga ta ei tohi muuta vastutust kollektiivseks uduks. Vastupidi: mida rohkem tööd masin teeb, seda selgemalt peab olema näha, milline inimene teeb otsuse.

Evoluna kui kontrollitav näide

Evoluna on selle tööviisi kõige ausam tõestus, mida mul on võimalik näidata.

See on kuues keeles töötav heaolu- ja arenguplatvorm, mille all on ligi 95 andmebaasimudelit ja sadu API-otspunkte. Platvormil on kasutajate, spetsialistide ja organisatsioonide loogika, mitmekeelsus, otsing, soovitused, autentimine, maksed Stripe Connecti kaudu ja mitu õiguste tasandit. Andmekaitse ei ole lisatud hiljem eraldi dokumendina, vaid seotud süsteemi käitumisega: teavitus, kustutamissoovi täitmine, andmete päritolu jälgitavus ja kordusimpordi tõkestus.

Mina olen selle süsteemi ainus igapäevane operaator. See ei tähenda, et kõik otsused sünnivad vaakumis. Jurist kontrollib juriidikat, valdkonnaekspert kontrollib sisu, vajaduse korral vaatab sõltumatu tehniline spetsialist üle arhitektuuri. Aga nende töö algab konkreetsest küsimusest. Nad ei pea kulutama nädalaid selleks, et aru saada, mida ma üldse ehitada tahtsin.

Ma ei too Evolunat näiteks kiitlemiseks. Toon ta näiteks sellepärast, et see on reaalne, töötav ja kontrollitav süsteem. Ärivestluses maksab lõpuks ainult kontrollitav väide.

Mida agentse arenduse puhul mitte teha

• Ära alusta koodist. Alusta probleemist ja vaidlusest, sest enne ehitamist on viga kõige odavam.

• Ära lase ühel mudelil enda tööd lõplikult hinnata. Kontroll peab tulema teisest vaatenurgast ja lõppema päris testidega.

• Ära eelda, et kohalik mudel tähendab automaatselt andmekaitset. Kontrolli kogu andmete teekonda, mitte ainult mudeli asukohta.

• Ära lase agendil parandada asju, mida keegi ei palunud. Lukusta skoop enne ehitust ja tee kõrvaleiust eraldi ülesanne.

• Ära usu sõnalist kinnitust, et asi töötab. Nõua tõendust: ekraanipilti, testiraportit või logi.

• Ära anna agentidele rohkem ligipääsu, kui neil konkreetse ülesande jaoks vaja on.

• Ära jäta arhitektuuri ühe vestluse või ühe inimese mälu sisse. Otsused ja nende põhjused peavad olema dokumenteeritud.

• Ära jäta andmekaitset ja turvalisust viimaseks tööpaketiks. Neid ei õmmelda hiljem süsteemile külge.

• Ära osta kallist riistvara enne, kui sul on tegelik ja pidev arendusvoog.

• Ära anna juristile halba mustandit. Ta alustab siis uuesti ja sina maksad kaks korda.

• Ära usalda eestikeelset väljundit ilma inimese lugemiseta.

• Ära mõõda arenduskiirust koodiridade järgi. Mõõda seda, mis jõudis tootmisse, lahendas kasutaja probleemi ja jäi sinna püsima.

Põhilist millega arvestada...

AI ei asenda arendusmeeskonda nii, et vastutus kaob. Ta muudab seda, kus töö toimub, kuidas rollid jaotuvad ja millise hinnaga saab tarkvara luua. Koodi kirjutamine on muutunud odavamaks, analüüs ja retsensioon toimuvad pidevalt. Üks inimene saab kasutada võimekust, milleks varem oli vaja tervet osakonda.

Otsus ei ole odavamaks muutunud. Keegi peab endiselt otsustama, mida ehitada. Keegi peab hoidma arhitektuuri. Keegi peab tundma liiklusmärke. Keegi peab teadma, millal masinale mitte järjekordset käsku anda.

Kood on muutunud odavaks. Vastutus ei ole.

Enne kui edasi lähed

1. Kes omab sinu ettevõttes tervikpilti siis, kui suure osa koodist kirjutab masin?

2. Kust tuleb sõltumatu retsensioon ja kas sellel on päriselt teistsugused pimealad kui ehitajal?

3. Kus asub sinu süsteemi organisatsiooniline mälu ja kas järgmine agent saab aru, miks varasemad otsused tehti?

4. Kui sinu meeskonnas tehakse viga, siis kuhu see õppetund läheb: inimese pähe või süsteemi, mida järgmine tegija automaatselt loeb?

5. Millised andmed ei tohiks kunagi sinu kontrolli alt lahkuda ja kas sa tead, kus need praegu liiguvad?

6. Milliste õigustega sinu agendid töötavad ja kas mõni neist pääseb ligi rohkemale, kui tal vaja on?

7. Kui palju maksab üks arenduskuu ja kui suur osa sellest on püsikulu, mida sa kuu jooksul muuta ei saa?

8. Kuidas sa saad aru, et muudatus töötab, ja kuidas sa pöörad ta tagasi, kui ta ei tööta?

9. Kas sa mõõdad arenduse kiirust selle järgi, mis valmis sai, või selle järgi, mis jäi tootmisse püsima ja lõi tegelikku väärtust?

Maailm on muutunud rohkem, kui enamik organisatsioone tunnistada tahab, ja see muutus ei oota, kuni ametijuhendid, eelarveprotsessid ja juhtimismudelid talle järele jõuavad. Selle pärast ei ole vaja paanikasse sattuda. Selle sees tuleb hakata otsustama. Masin oskab ehitada peaaegu kõike. Ta ei tea, millist maailma sina selle abil ehitada tahad.

Pert Lomp on Evoluna asutaja, Fontese juhtimismentorluse programmi vilistlane ja EMCC sertifitseeritud mentor. Evoluna on heaolu- ja arenguplatvorm, mis aitab inimesel leida tema vajadusele sobiva spetsialisti, teenuse või järgmise sammu: evoluna.app