Navik OÜ juhataja, IT-nõustaja ning kunagi Klick Eesti poeketi käima pannud Veiko-Peeter Kargu avaldab oma senise IT-maailma kuldreegli: ära tee odavalt ja kiiresti seda, mis peab kestma kaua. Kiire lahendus on tehniline võlg — sa säästad täna ja maksad homme intressidega. Kuid paraku tunnistab ta siinses artiklis, et see reegel enam alati kindlalt ei kehti.
Olen seda kuldreeglit ise klientidele õpetanud, seda müünud, kaitsnud ja selle järgi suuri süsteeme ehitanud. Nüüd pean tunnistama, et ma ei ole enam kindel, kas see reegel alati kehtib.
See kahtlus ei tekkinud tühja koha pealt. Kirjutasin hiljuti LinkedInis välja ühe provokatiivse mõtte: kõige kallim viga, mida ettevõte täna teha saab, on tellida "raske" tarkvaraarendus sinna, kuhu oleks tegelikult piisanud hästi juhendatud AI-agendist.
Siis aga juhtus kommentaarides midagi huvitavamat kui postitus ise. Kolm kogenud IT-inimest esitasid mulle kolm erinevat vastuväidet. Ükski neist polnud rumal — vastupidi, igaüks tabas midagi olulist. Koos panid nad mind küsima: kas ma ise ikka usun seda, mida just kirjutasin?
Mida rohkem ma neile vastasin, seda selgemaks sai üks oluline asi. Need vastuväited ei käinud tegelikult minu postituse kohta. Need puudutasid palju fundamentaalsemat küsimust, mille ees seisab praegu iga ettevõtja, kes peab otsustama, kuhu oma digieelarve paigutada.
Toon need kolm arutelupunkti siin välja.
1. "Kiire lahendus on pikas plaanis ikkagi kallim"
Esimene argument kõlas nii: kui lased tehisaruagendil iga päev sama tööd uuesti teha, on see lõpuks puhtakujuline raha põletamine. Targem on lasta sel kirjutada üks kord üks korralik kood, mis edaspidi jookseb taustal ilma igakordse AI-arvutuseta. Kui sisendandmed muutuvad, tuleb niikuinii uus struktuur teha. Seega on kiired lahendused pikas plaanis ikkagi kulukamad.
Tehniliselt on see täiesti õige. Nii need asjad praktikas töötavadki.
Aga sõnapaaris "pikas plaanis" peitub üks hiiglaslik väljaütlemata eeldus: see lahendus peabki pikas plaanis elama.
Kogu meie senine arusaam tarkvarast tugineb mõttele, et kood on vara. See on asi, mida sa ehitad korra, hoiad alles, hooldad, kaitsed ja pärandad edasi. Tehniline võlg on selles maailmas patt, sest siis sa jätad järgmisele tiimile koristamata jama.
Tehniline võlg on aga ohtlik ainult siis, kui ajutine lahendus jääbki märkamatult püsima. Kui lahendus ongi algusest peale teadlikult ajutine — püsti pandud paari tunniga, kasutatud pool aastat ja siis rahulikult minema visatud, siis pole midagi pärandada ja pole kellelegi võlga jätta. Sa lihtsalt viskad ühekordse nõu ära ja võtad vajadusel uue.
See on harjumatu mõte, mis sunnib küsima: kui palju meie tarkvaratarkusest on tegelikult objektiivne tõde ja kui palju lihtsalt harjumus ajast, mil ehitamine oligi kallis, aeglane ja paratamatult kaua püsiv?
2. "Sa ei tea, kas see agent poole aasta pärast veel töötab"
Järgmine mure oli sõltuvus: täna sinu agent töötab, aga kas ka poole aasta pärast? Kui palju see siis maksab? Sa annad oma äriteadmise masinale üle ja jääd sõltuvaks kellegi teise platvormist (ja argumenteerija lisas sinna juurde peaaegu vabandavalt: see kehtib muidugi ka tavatarkvara kohta).
See viimane sulgudesse poetatud märkus on tegelikult kogu asja tuum.
Sõltuvus ei ole tehisintellekti leiutis. Me ei ole IT-s kunagi päriselt sõltumatud olnud. Sõltume arendajast, kes koodi kirjutas. Sõltume raamistikust, mis pidevalt vananeb, platvormist, mis tõstab hinda. Oleme sõltuvad ka inimesest, kes ühel päeval ettevõttest lahkub ja viib oma teadmised peas kaasa. Me lihtsalt valime iga kord, kelle või mille külge end kinnitame.
Siit koorub teine küsimus: kumb sõltuvus on tegelikult riskantsem?
Kas see, kus su äriloogika on kirjas lihtsas tekstifailis, inimkeeles, mille sa saad tarnija hinnatõusu korral paari nädalaga teise mudeli alla kolida? Või see, kus su ettevõtte vereringe on lukus kümne aasta vanuses programmi koodibaasis, millest keegi majas enam aru ei saa ja mille autor on ammu lahkunud?
Esimesest on sul ülevaade. Teisest ei pruugi keegi enam aru saada. Ja ometi peame me täna sageli esimest varianti riskantseks ja teist kindlaks, suuresti lihtsalt seetõttu, et viimane on vana ja tuttav.
3. "See muutub vaikselt turvariskiks"
Viimane vastuväide oli kõige teravam. Keegi teine omab kontrolli su tulemuste üle, inimesi pole enam võtta, oskusteave on majast kadunud. Ja sa ei tea tegelikult, mida AI sulle taustal kokku keerab. "Vaata haibist mööda ja mõtle," öeldi mulle.
Selle kriitikaga olen ma igati nõus ja tõmban koos temaga selge piiri.
Ärikriitilist selgroogu — süsteemi, mille seiskumine peatab pangamaksed, logistika või kogu ettevõtte tegevuse — ei tohi täna pimesi usaldada ühegi masina ega üksiku tarnija kätte. See ei ole koht eksperimentideks. Punkt.
Aga tasub märgata, mida see kriitika tegelikult kaitseb. See kaitseb põhjalikkust, kontrolli. See kaitseb arusaamist sellest, mis su majas tegelikult toimub. Need on õiged väärtused — ja need kehtivad täpselt sama palju traditsioonilise eritarkvara kohta, kuhu ettevõtted on end aastaid sisse ostnud, ühestki koodireast ise aru saamata.
Vahe ei ole tehisintellektis. Vahe on selles, kas sina juhina mõistad, mida sa oma majja tood — olgu selle autoriks siis inimene või masin.
Pöördepunkt on tulekul
Kui ma neid kolme argumenti kõrvutan, siis näen, et need kaitsevad kõik üht ja sama asja: põhjalikkust, kestlikkust, mõtteviisi "teeme ühe korra ja korralikult".
Terve oma karjääri jooksul olen ma seda lähenemist ise uskunud. Olen asutanud Klick Eesti, juhtinud projekte Eesti Raudteel ja tegelenud raskete ERP-süsteemidega. Olen ostnud IT-d miljonite eest ja jaganud sadadele klientidele soovitust: ärge tehke odavalt ja kiiresti, te maksate selle hiljem rängalt kinni.
See oli üks väheseid reegleid, mille peale sai päriselt kindel olla. Aga mida kauem ma olen seda mängu mänginud, seda selgemini näen, et mängulaud ise on muutunud. Minu isiklik kahtlus on vaid väike peegeldus millestki palju suuremast.
Maailmas käib sama vaidlus, lihtsalt palju valjemini
Tehnoloogiamaailm on praegu selgelt pooleks lõhenenud.
Ühel pool seisavad visionäärid nagu Andrej Karpathy (Tesla ja OpenAI endine AI-juht), kelle sõnum on radikaalne: loomulik inimkeel on muutumas uueks programmeerimisliideseks, sa ei kirjuta enam tingimata koodi, vaid kirjeldad masinale, mida tahad. Mõned pragmaatikud lähevad veelgi kaugemale ja väidavad, et kood ei olegi enam püsiväärtus, vaid kulumaterjal: kui probleem muutus, kustuta vana ja lase teha uus.
Teisel pool seisavad sama kaalukad hääled. Uuringud ja suuremahulised koodianalüüsid on näidanud, et AI-ga liiga kiirelt kokku pandud kood kogub tehnilist võlga, turvaaugud kasvavad ja koodi eluiga lüheneb. Puhta koodi pooldajad hoiatavad: kes laseb tootmisesse süsteemi, millest ta lõpuni aru ei saa, ostab endale eelseisva pankroti.
Mõlemal poolel on faktiliselt õigus.
Kuidas saavad mõlemad korraga õiged olla?
Saavad, sest tegelik valik ei ole enam ammu "kiire vs korralik". Küsimus on, kuhu suunas sa kumba rakendad.
Kiirustades kokku pandud AI-lahendus ettevõtte südames — süsteemis, millel seisab kogu äri, ongi viitsütikuga pomm. Seal on skeptikutel täielik õigus.
Sama kiire ja odav lahendus (ilma raske andmebaasi ja serveripargita) spetsiifilise või muutuva probleemi jaoks? Kampaanialeht, tootekataloog, sisemine andmeraport või igapäevane müügiabimees, mis töötab täna ja mille saab kuu aja pärast muretult asendada? See on täpselt õige tööriist.
Viga ei ole kiiruses ega põhjalikkuses. Viga on valada betoonvundamenti sinna, kuhu oleks piisanud telgist. Ja teisalt, püstitada telki sinna, kus tegelikult vajatakse betoonvundamenti.
Enamik halbu digiotsuseid, mida ma oma karjääri jooksul näinud olen, taandub lõpuks just sellele ühele eksimusele: vale suurus vale probleemi jaoks. Seni tehti seda viga peaaegu alati ühes suunas — ehitati liiga vähe sinna, kus oleks vaja rohkem. Nüüd teeb järjest rohkem inimesi viga teises suunas: ehitavad rasket ja kallist lahendust sinna, kuhu piisanuks kergest ja äravisatavast.
Mida keegi ei taha valjusti öelda?
Stabiilses maailmas oli "ehita korralikult ja ühe korra" alati õige strateegia. Selles pole kahtlust.
Aga me ei ela praegu stabiilses keskkonnas. Tehnoloogia muutub nii metsiku tempoga, et massiivne arendus jõuab vananeda juba enne, kui see valmis saab. Sa kulutad kuid ja kümneid tuhandeid eurosid kestliku süsteemi peale ning selle valmimise päevaks on ilmunud tööriistad, mis teeksid sama asja poole väiksema vaevaga.
Kestliku ja kalli süsteemi ehitamine keset tehnoloogilist kaost ei ole alati kvaliteedimärk. Tihti on see lihtsalt üks väga kallis viis luua midagi, mis on sündides iganenud.
Kui maailm on stabiilne, tasub pikalt investeerida. Kui maailm muutub kiiremini, kui sinu projekt valmib, ei jõua suur investeering end kunagi ära tasuda. Sama põhjus, miks me oleme AI suhtes ettevaatlikud — see pidev muutumine — teeb rasketest ja pikaajalistest arendustest nüüd suurima võimaliku riski.
Ma usun, et mingil hetkel arengukõver taas rahuneb. Uued standardid ja parimad praktikad settivad ning meil on aeg tagasi pöörduda raskete ja kestlike lahenduste juurde. See aeg tuleb.
Aga see hetk ei ole täna. Tormi ajal ei ehitata katedraali. Tormi ajal ehitatakse varjualune, mida saab kiiresti kohendada ja mis ei varise kokku, kui tuul suunda muudab.
Kuus küsimust enne, kui sa eelarve lukku lööd
Kõik see jääb pelgalt teooriaks, kui me ei muuda oma igapäevaseid otsuseid. Siin on raamistik, mida ma ise praegu kasutan. Enne, kui tellid järgmise digilahenduse, hinda oma probleemi läbi kuue filtri.
- Kas see protsess on ärikriitiline või toetav (kas selle seiskumine peatab ettevõtte või tekitab lihtsalt ebamugavust)?
- Kas see peab kestma aastaid või võib poole aasta pärast täiesti teistsugune välja näha?
- Kui suur on vea hind (kas valed andmed maksavad ränka raha ja mainet või piisab ühe rea parandamisest)?
- Kas lahendus peab sügavalt integreeruma su põhisüsteemidega või saab see elada omaette?
- Kas tegevus on peamiselt andmete lugemine, võrdlemine ja raporteerimine või midagi, mis nõuab keerukat andmearhitektuuri?
- Ja kõige tähtsam: kas seda saaks esmalt testida agendiga, enne kui üldse päris tarkvara ehitamise peale mõtleme?
Kui vastused kalduvad skaalal sinnapoole, et lahendus on toetav, muutuv, väikese vea hinnaga ja isoleeritud, siis on üsna tõenäoline, et sa plaanid hetkel ehitada katedraali sinna, kuhu tegelikult piisaks telgist.
Tarkus ei ole leeri valimine
See lugu pole kirjutatud selleks, et väita, nagu me ei peaks enam kunagi midagi korralikult ehitama. Tuleb päev, mil põhjalik vundament on taas ainuõige valik.
Enamik meist ei tee tähtsaid otsuseid enam üldse. Me lihtsalt kordame sisseharjunud mustreid. "Meil on mure, tellime korraliku süsteemi" on aastakümnete pikkune refleks. Kuid see refleks on otsus, mis tehakse ilma mõtlemata. Ja praegusel ajal on pimesi tegutsemine kõige kallim asi, mida üks ettevõte endale lubada saab.
Mõlemas suunas eksimine maksab. Üle-ehitamine on kallis. Ala-ehitamine sinna, kuhu on vaja tugevat alust, on samuti kallis — ja sageli ka ohtlik.
Tarkus ei seisne selles, kas pooldada AI-entusiaste või traditsionaliste. Tarkus on vaadata probleemile ausalt otsa ja valida lahendus, mis vastab täpselt selle ulatusele. Mõnikord vajad betooni, teinekord telki. Kõige kallim viga on need kaks lihtsalt omavahel sassi ajada.
Päeva lõpuks taandub kõik ühele küsimusele. Need kolm kogenud spetsialisti, kes minuga arutellu astusid, otsisid vastust küsimusele "Kuidas ehitada õigesti?". See on hea ja vajalik küsimus. Kuid tänasel päeval tuleb enne seda esitada üks palju olulisem: "Kas me oleme üldse kindlad, et me peame seda ehitama?"
