Ma soovin jagada oma viimaste aastate, aga eelkõige just viimaste kuude, üht kõige ägedamat kogemust – tehisintellekti abil veebirakenduste loomist ehk vaibkoodimisest. Küll ei saa öelda, et kõik on siiani vaid libedalt ja valutult läinud, seda mitte. Kuid elamusi ja õppetunde on olnud väga palju.

Üks olulisemaid minu jaoks on olnud see, et kui kohutavalt mõnus on hommikul ärgata selle tundega, et täna ma saan jälle midagi ägedat teha. Ja õhtul magama minnes ei jõua hommikut ära oodata. Ma vist isegi ütlesin kellelegi vaibkoodimisest rääkides, et olen leidnud omale unistuste töö.

Aga nüüd kogemuse ja õppetundide juurde. Vaibkoodimise põgusa karjääri jooksul olen aru saanud, et töötava, turvalise ja päriselt toimiva rakenduse tegemine ei sõltu ainult heast promptimisest, vaid süsteemsest mõtlemisest. Tegelikult olen seda ikka varem ka teadnud aga nüüd saan seda tõesti rakendada ja end nö välja elada.

Allpool kirjeldan, kuidas ma olen vaibkoodimisega veebirakendusi ehitanud ja millise tööprotsessi endale kujundanud. Ma kasutan peamise vaibkoodimise keskkonnana Lovable rakendust.

Enne arendusega alustamist mõtlen kogu skoobi läbi

Ma ei hakka kunagi kohe ehitama. Ma teen endale vähemalt sellise minimaalse lähteülesande:

  • Mis on rakenduse eesmärk?
  • Kes on kasutaja?
  • Mida kasutaja samm-sammult teeb, milline on tema teekond ja põhiprotsess?
  • Mis on MVP ja mis jääb hilisemaks?
  • Milliseid andmeid ma kogun?
  • Millised on rollid ja õigused?
  • Kas on vaja integratsioone?
  • Kas mobiil peab olema täielikult toetatud?
  • Millised on turvanõuded?

Selle kirjelduse panen ma tavaliselt ka projekti knowledge väljale, et see oleks kogu aeg arenduse juures olemas.

Alustan alati läbimõeldud nö initial promptist

Minu jaoks on kõige olulisem see esimene prompt. Ma ei kirjuta sinna lihtsalt ideed, vaid põhimõttelise raamistiku, mis sisuliselt kirjeldabki ära eelmises punktis toodud nõuded.

Näiteks:

  • Kui ma teen lihtsat üheleheküljelist kodulehte, siis ütlen seda kohe. Sest üks veebileht on üks veebileht ja ta ei vaja näiteks kasutajate autentimist, erinevaid rolle või ka makselahendust.
  • Kui ma teen rakendust, kus on maandumisleht, kasutajakontod, rollipõhine ligipääs ja admin-vaade, siis kirjeldan selle kõik kohe alguses ära. Mitte nüüd kõikides detailides kuid olulisemad nõuded.

Olen õppinud, et kui ma seda ei tee, ehitab AI mulle liiga lihtsa või vale arhitektuuriga lahenduse. Hiljem ümbertegemine on alati keerulisem ja lõpuks ka mulle endale kallim, kui alguses läbimõeldud ülesanne.

Projekti alguses kirjeldan alati ära disaini ja tunde

Olen aru saanud, et AI ei vaja ainult tehnilist kirjeldust, vaid ka emotsionaalset suunda. Kui see on talle antud, siis teeb ta kujunduslahendusi täitsa rahuldavalt.

Näiteks kirjutan:

  • keskkond peab olema soe ja toetav
  • või professionaalne ja konkreetne B2B-le
  • või minimalistlik ja süsteemne
  • selged joondused, raamid, lihtne navigatsioon

Kui ma annan ainult funktsioonid, tuleb tehniliselt korrektne, aga visuaalselt juhuslik lahendus. Kui ma annan ka tunde ja stiili, tuleb ühtlasem kasutajakogemus.

Näiteks Lovables olen kogenud nii häid kui väga puudulikke UI tulemusi. Mõnikord olen isegi lähenenud nii, et Google Stitch rakenduses olen esmase disaini koos html koodiga valmis teinud ja selle siis selgete juhistega Lovablele andnud. Toimis väga hästi.

Arendades (vaibkoodides) annan väga konkreetsed ülesanded

Jällegi, läbi kogemuste olen õppinud, et kui ma ise ei tea täpselt, mida tahan, siis AI hakkab tegema midagi „loogilist“, aga mitte tingimata seda, mida mina mõtlesin. Selles mõttes ei erine inim-arendajaga töötamine mitte kuidagi AI-arendjast. Mõlemal on vaja selget sisendit.

Seetõttu ma:

  • kirjeldan täpselt, mida funktsioon peab sisaldama
  • kirjeldan, millele tuleb eriti tähelepanu pöörata
  • ütlen, mis ei kuulu selle ülesande alla

Parandamine on alati ressurssinõudvam kui täpne lähteülesanne. Kuigi, ega parandamisest nagunii ei pääse. Küsimus on lihtsalt paranduste mahus.

Parandamise puhul olen näinud ka seda, et isegi AI-l võib teinekord üldpilt eest kaduda ja ta hakkab tegema nö “quick fix” `e. Ja see on juba väga halb praktika.

Kasutan erinevaid AI-sid eri etappides

Minu tüüpiline töövoog näeb välja nii:

  1. Idee struktureerimine

Kuna mul on pea igasuguseid ideid ja mõtteid pidevalt töis ja olen pigem rääkija kui kirjutaja, siis ma tavaliselt räägin oma idee sisse ChatGPT-le. ChatGPT transkribeerib.

Seejärel palun tal:

  • esitada täpsustavaid küsimusi
  • tuua välja puudused või riskid
  • teha sellest struktureeritud lähteülesanne.

Olen ka küsinud innovaatilisi ideid kuid need pole osutunud kuigi innovaatilisteks.

  1. Tehniline spetsifikatsioon

Seejärel annan selle lähteülesande Claude’ile.

Palun tal:

  • korrastada see tehniliseks dokumendiks
  • pakkuda arhitektuur toetudes lähteülesande loogikale
  • luua andmebaasi struktuur
  • kirjeldada tabelite seosed
  • vajadusel lisada valemid
  • kirjutada kasutajatestid
  • teha esmane UI spetsifikatsioon

Claude on väga põhjalik ja analüüsiv. Väljundid on väga kvaliteetsed.

  1. Planeerimisrežiim arenduskeskkonnas

Laadin kõik dokumendid üles ja annan planeerimisrežiimis ülesande:

  • analüüsi kogu materjal
  • koosta detailne plaan

Ma ei lase kunagi kohe ehitama hakata. Ma vaatan alati plaani üle, parandan ja alles siis kinnitan.

Panen mobiili- ja turvanõuded sisse pigem alguses

Annan koos arenduse ülesandega tavaliselt ka sellised juhised:

  • kõik vaated peavad olema mobiilis kasutatavad
  • rollipõhised ligipääsud peavad olema vastavad nõuetele
  • päringud peavad olema turvalised (RLS poliitikad)
  • andmetabelid peavad olema piiratud ligipääsuga
  • isikuandmed peavad olema vajadusel krüpteeritud
  • GDPR põhimõtteid tuleb arvestada kõikie andmete osas.

Kui seda mitte teha alguses, tähendab see hiljem päris suurt täiendamist, ümbertegemist ja paraku ka lisanduvaid erroreid.

Ma ei usalda kunagi ainult AI kinnitust ja seepärast testin ise

Üks oluline õppetund: AI kipub mõnikord liiga entusiastlikult kinnitama, et kõik töötab. Ta vaatab koodi ja seal justkui on kõik korras. Kood võib ju korras olla, funkstioon aga ei pruugi töötada selliselt, nagu see mõeldud oli.

Seetõttu ma testin kõik funktsioonid ise läbi, ma kontrollin ka arvutused käsitsi üle – isegi lihtsamad liitmised ja lahutamised, testin erinevaid rolle ja proovin mittekohaseid kasutaja-olukordi tekitada (tühjad väljad, valed sisendid jne).

Olen lasknud ehitada ka regulaarseid automaatteste, mis kontrollivad kas arvutused annavad õige tulemuse, kas andmevood toimivad ja kas rollipiirangud kehtivad. See on eriti oluline, kui tegemist on finantsandmete või KPI-arvutustega.

Turustamine ja välisturule liikumine

Kui kavatsen rakendust pakkuda erinevates riikides, siis ma tean, et andmete säilitamise nõuded võivad riigiti ja piirkonniti erineda. Näiteks mõnes riigis peab kodanike andmeid säilitama selle riigi territooriumil.

  • Andmete füüsilise asukoha nõuded võivad erineda
  • säilitustähtajad võivad erineda
  • sektoripõhised reeglid võivad erineda.

Ma olen kasutanud AI-d ka selleks, et teha regulatiivne audit, hinnata riske ja tuvastada puudujäägid. Sest lõplik vastutus jääb alati mulle kui teenuse pakkujale. Ja sellesse vastutusse ei tasu suhtuda hooletult.

Tavaliselt teen maandumislehe kõige viimasena

Kui rakenduse põhitegevus toimub sisse logitud kasutajatel kinnises keskkonnas, siis ma ei tee maandumislehte kohe alguses.

Ma ehitan keskkonna valmis, testin, parandan ja alles siis lasen AI-l luua maandumislehe. Muidugi annan ma talle ette maandumislehe struktuuri, juhised disaini osas, mõnikord ka mõne sobiva visuaalse näidise, plokkide paigutused jne.

Kuid ka AI suudab väga hästi juba valmis rakendusest välja võtta:

  • väärtuspakkumise
  • funktsioonide loogika
  • kasuteguri

Ja niimoodi lähenemisi kombineerides on tulemus oluliselt parem.

SEO ja AIO

On olulised mõisted ja ka iga vaibkoodija, kui ta kavatseb oma kätetööd pakkuda teistele kasutamiseks või ka ärilisel eesmärgil, peaks olema teadlik, kuidas sinu teenuseid üles on võimalik leida.

Mitte et ma ise oleksin kõva käsi nendes teemades, aga ka juba esmane teadlikkus aitab AI-le esitada asjakohaseid küsimusi, suunata teda ja paluda luua lehele SEO vastavus, robotitele loetavaks tegemine, märksõnade esiletulemine, schemad, FAQ ja muud sellised teemad, mille tähtsusest enamus väga teadlik ei olegi.

Ma usun, et tooteomaniku mõtteviis on suurim eelis

Ma ei ole ise programmeerija, kuid olen programmeerimise aluseid veidi õppinud ja muidugi üle 10 aasta IT tootearenduses osalenud. Seega ma mõistan,  kuidas tarkvara on üles ehitatud,  kuidas andmebaasid töötavad,  kui olulised on protsessid ja teekonnad ja kasutuslood, kui oluline on süsteemne loogika.

AI loob küll andmetabelid, kirjutab päringud, seob andmed ja genereerib koodi. Kuid äriloogika tuleb minult, prioriteedid tulevad minult ja süsteemi tervikpilt tuleb alati minu poolt.

Olen tõdemusel, et parimaid tööriistu ehitavad need, kes mõistavad tarkvaraarenduse köögipoolt, isegi kui nad ise ei programmeeri.

Kokkuvõtteks

Minu kogemus ütleb, et vaibkoodimine ei ole lihtsalt „kirjuta prompt ja valmis“.

See on:

  • süsteemne planeerimine
  • läbimõeldud lähteülesanne
  • teadlik arhitektuur
  • regulaarne testimine
  • turvalisuse ja regulatsioonide teadlikkus
  • tooteomaniku vastutus

Tehisintellekt on väga võimas tööriist. Aga toimiva, loogilise ja turvalise süsteemi loob endiselt inimene, kes mõtleb süsteemselt ja vastutab terviku eest.

Kõik see, millest ma eelpool kirjutasin, ei ole pelgalt teoreetiline arutelu. Olen seda lähenemist rakendanud päris arenduses ja loonud lahendusi, mis on keerukad, andmepõhised ja mitmekihilise rollistruktuuriga.

Üks tööriistade kogum, veebirakendus, mille esimese versiooni me lõime SinuLabis juba 6 aastat tagasi, on MyPlan. Seda rakendust kasutab igapäevaselt praegu pea 300 eestimaalast, kuid tasapisi on kogunenud päris palju kasutajakogemusi ning küpsenud soov luua uus versioon. Sisuliselt oli tegemist refaktoreerimise ja mitme uue lahenduse loomisega.

____________________

MyPlan Performance

MyPlan ei ole lihtsalt eesmärkide seadmise tööriist. Selle arendamisel pidin ma väga täpselt läbi mõtlema kogu uuendatud loogika, sobitama uued moodulid ja funktsioonid olemasolevasse süsteemi. Mõtlema kasutajamugavuse ja uute võimaluste peale nagu häälkäsklused ja transkribeerimine, andmete lugemine failist või pildilt, tehisintellekti roll personaalse arengu toetamisel – kas see on juhendamine, soovitamine või peegeldamine, mida on eetiline kasutajatele pakkuda.

Keerukus ei seisnenud mitte kasutajaliideses, vaid loogikas – millised seosed tekivad eesmärkide, tegevuste, mõõdikute ja ajaliste perioodide vahel. Sellise süsteemi puhul ei saa loota ainult sellele, et “AI teeb ära”. Ärireeglid peavad olema väga selgelt läbi mõeldud.

MyPlan uusversioon on tegelikult juba valmis ja kel huvi, siis saab lähemalt lugeda siin: https://myplanperformance.lovable.app

___________________

Teine idee, mida olen ka juba aastaid endas kandnud, on abimees juhtidele – kuidas oma Leadership oskusi ja võimekusi arendada siis, kui koolitustel käimine ei toimi või kui pole tahmist või usku omale personaalne coach võtta. Aga teatud peegeldust ja sparringupartnerit oleks nagu vaja – piisavalt privaatset ja sellist, kelle ees ei pea piinlikkust tundma, miis võimaldab liikuda omas tempos.

Juhid ju teatavasti õpivad autonoomselt ja eelkõige kogemuspõhiselt igapäevatööd tehes. Kuidas seda kõike toetada ja suunata, et juhtimine muutuks nauditavaks nii endale kui teistele.

MirrorMyLeadership

MirrorMyLeadership on veel samm edasi loogikapõhises arenduses. See ei ole lihtsalt andmekogu, vaid peegeldusmudel, mis:

  • seob juhtimiskäitumise konkreetsete mõõdetavate dimensioonidega
  • arvutab tulemusi eri tasanditel
  • aitab juhil mõista tema Leadership profiili ja seda arendada, suunata
  • kuvab mustreid ja riske
  • loob võrdluspunkte, aitab nihutada mõtteviisi

Selle arenduse suurim väljakutse oli mudeli loogiline puhtus, et arvutused, kaalud ja seosed annaksid sisuliselt usaldusväärse tulemuse. Hea näide sellest, kuidas tehniline teostus on tegelikult ainult üks osa – kõige keerulisem on mõtlemise selgus mudeli taga.

MirrorMyLeadership on valmimisel ja üsna varsti ka piloteerimiseks saadaval. Kel huvi, andke märku.

___________________

Juhi aastane planeerija

Juhi aastane planeerija tundub esmapilgul lihtne, aga tegelikult on see süsteemne ajaloogika tööriist. Selle juures pidin ma läbi mõtlema eelkõige, kuidas hoida  strateegilised eesmärgid aastases tsüklis nähtaval, kuidas luua järjepidevuse tunnet üheainsa tööriistaga, kuidas vältida seda, et planeerimine muutub lihtsalt nimekirjaks ning kuidas kuvada fookusteemasid nii, et see toetaks distsipliini ja järjepidevust.

Kel huvi proovida ja uudistada, siis tööriist on täiesti TASUTA ja leiab siit: https://lead-year-hub.lovable.app

Sobib kasutamiseks nii personaalse fookuse seadmiseks, perele oluliste perioodide märgutamiseks ning kindlasti tööalaselt meeekonnas, organisatsioonis või oma valdkonna ülevaate kommunikeerimiseks ja plaanimiseks.

____________________

Näide sellest, kuidas ma kasutasin erinevaid AI-sid MyPlan eesmärkide mooduli arendamisel:

1. IDEE (ChatGPT voice):
Ma rääkisin sisse põhjaliku loogika ja kirjelduse, kuidas kasutaja saab luua strateegilisi eesmärke, lühemaid eesmärke, seada neile mõõdikuid, jälgida progressi ning analüüsida tulemusi.

2. STRUKTUREERIMINE (ChatGPT):
ChatGPT koostas sellest kokkuvõtte ja struktureeris mõtted. Pärast mõningaid minupoolseid täiendusi ja detailide lisamist, sai sellest esmane lähteülesanne.

3. TEHNILINE SPETSIFIKATSIOON (Claude):
– Andmebaasi struktuuri (strategic_goals, objectives, key_results)
– Tabelite seosed (FK constraints, cascade rules)
– Arvutusvalemid (progress%, completion status)
– 15 kasutajatesti (TC-001: Loo eesmärk, TC-002: Kustuta eesmärk…)
– UI spetsifikatsiooni (dashboard, detail view, edit flow)

4. IMPLEMENTATSIOON (Lovable):
Laadin Claude’i dokumendi Lovable’i, planeerimisrežiimi ja lasen koostada 8-sammuline plaani. Selle vaatasin põhjalikult üle, tegin mõned korrigeerimised ja täpsustused ning andsin töösse. Lovable ehitab sellised lahendused valmis 3-5 minutiga.

5. TESTIMINE (Mina):
– Kas progress% arvutus on õige
– Kas hierarhia töötab (alam-eesmärgid, summeerimine, perioodid)
– RLS policies
– Kas mobiilis on kasutatav

6. MÕNINGAD PARANDUSED (Mina ja Lovable)

TULEMUS: Eesmärkide moodul valmis 0,3 päevaga, funktsioneerib 300+ kasutajal tõrgeteta.