Skip to main content

Feedback

2025-2026 Spring​

Lõpuraport​

Mul on tunne, et see aine õpetas hästi palju – olgugi et ma ei olnud ei sihtgrupp ning võimalik, et seda, mis ma õppisin, ei olnud õppekavasse disainitud. Midagi on selles toores halastamatus aususes, millega õppejõud seda ainet luges ja mis teeb keeruliseks lihtsalt ainest läbi libiseda ilma, et midagi külge jääks või mõtlema paneks. Selleks, et olla passivne, tuleb justkui teadlik valik teha, sest see miskipärast pole enam vaikimisi saadaval. Ja isegi kui mul ei olnud teinekord neid eelteadmisi, mille külge uut infot haakida, siis selles aines oli kuidagi hästi palju ehedust. Ja see ehedus oli kergesti kättesaadav, mitte mattunud tavapärasesse akadeemilisse kastmesse, kus powerpoint on taltechi värvides ja vormi on rohkem kui sisu.

MIS MA SIIS PÄRISELT ÕPPISIN

  • Et AI-ga arendamine ei ole nii lihtne kui ma arvasin (reaalsuskontroll – keerulisemate ülesannete puhul peab ikkagi oskama küsida ja minimaalsel määral valideerida), samas ka mitte tehtamatu (saab ka mitte-arendajana täitsa korraliku asja kui esmasest meeleheitest üle saada ja teada, mis tööriistu millal kasutada);
  • et kõige paremini toimib see, kui AI arendus matkib võimalikult palju seda kuidas see päris elus käib: kõigepealt plaan, siis specid, siis taskid, alamtaskid, testimine, iteratiivne specide parandamine jne. Kas või see, et korraga ei saa liiga suurt ülesannet anda, sest kontekst saab otsa – sama nagu päris inimestegagi, et mida konkreetsem ülesanne ja ootused, seda parem resultaat. "Tee mulle äpp" lihtsalt Claude vestlusaknas ei tööta, aga kui sama kirjutada VS Code Claude Code aknasse koos /opsx:propose modega, siis on tulemus kordades etem, sest tööle hakkab väike projektijuht.
  • Isegi Claude Code opusega võib ootamatult uhuud ajama hakata. Näiteks vastas ta mulle ülima enesekindlusega, et kooli proxy ei toeta resposes APIt, aga sai tegelikult ilusti hakkama pärast seda kui ma ütlesin, et teistel küll töötab. "Don't worry about it — the teacher's own proxy doesn't support it, so they can't expect you to demo it through it." – ?!??
  • Kui AI saab valmis midagi keerulisemat (nt. chat), aga mul pole õrna aimugi, kuidas, siis sellega kaasneb veider (õõnes?) tunne; pean selle üle pikemalt järele mõtlema, et kas see on uus tunne millega AI-ajastul harjuda või on see märk millestki muust. Ehk on asi selles, et ülesanne tegelt nõudis iga koodirea seletamist, mis ma tegelikult ei oska ja seni ongi imposteri tunne. Kui laiemalt vaadata, siis olen ju ülikoolis selleks, et õppida, aga AI võimaldab toota tulemusi ilma, et mõistmine peaks sellele tingimata eelnema. See ei ole selle aine probleem ega isegi mitte etteheide. Usun, et mõistmine oleks olnud hoopis teistsugune, kui ma oleksin ise eelnevalt suuteline arendama – ehk siis äkki ma ise lihtsalt ei oleks pidanud siin (veel) olema, olgugi, et ma väga hindan seda, et ma olin? Äkki tulevikus hakkavad kehtima mingid piirangud, kus ilma teatud baasteadmiste lävenditeta ei tohigi tehisaru kasutada.
  • Päris ebavajalikult palju aega kulutasin UI peale – ühelt poolt minu beebi ja võiks olla kena vaadata, kuid teisalt on midagi selles, kui ma päriselt suudan AI-loodut valideerida, kaasa rääkida ja temaga vaielda. Backendis ei ole mul selleks piisavalt eelteadmisi (seesama õõnes tunne?), frontendis on seda tunduvalt lihtsam teha.
  • Õppisin AI-d ka üldisemalt paremini kasutama; mingi basic AI-literacy kursus oleks ka nagu ülikoolist/elust laiemalt puudu. Loodan, et taolised AI toimemehhanisme detailselt lahkavad ained muutuvad kohustuslikuks ka teistes teaduskondades – või veel parem, juba varasemas kooliastmes.
  • Kuulujutud vastavad tõele – Käveri ained on ühed kõige kasulikumad, isegi kui rasked. Mulle tundub, et 'gerilja-pedagoogika' on hea termin, mis seda kõike hästi iseloomustaks. See on aine, milles ma oleks tahtnud edasi käia ka siis, kui EAP-sid ei saaks.

Kursuse jooksul tegin kolm kodutööd ja aus vastus küsimusele "kuidas läks" on väga erineva süvenemisastmega. Esimene projekt neelas mu tähelepanu nii ära, et ülejäänud kaks said paratamatult vähem armastust. Aga järjest. Esimese poole semestri tundide lõpuks oli nutumaik kurgus, lõpus oli juba väga tore.

Ülesanne oli ehitada ChatGPT-laadne veebirakendus algusest peale.

Ausalt öeldes ei teadnud ma kursuse alguses praktiliselt mitte midagi. Mitte ainult, et polnud midagi sarnast teinud, vaid enne sügist polnud ma tegelikult üldse programmeerimisega otseselt kokku puutunudki. Nii et esimesed tunnid läksid lihtsalt mõistetest aru saamisele, et mis asi on SSE, VPS ja kõik muu "hiina keel". "Explain it to me like I'm 5" ja "ma pole elus kunagi programmeerinud, ma ei tea midagi — selgita nüüd" olid kindlasti mu kõige sagedamini kasutatud promptid.

Selle projekti puhul sain valmis kõik nõutud asjad: dual provider backend (OpenAI + Anthropic, ka Azure variandid ai-proxy.cm.itcollege.ee kaudu), käsitsi SSE-parsing, tool-use loop viie tool'iga (kuupäev/kell, web search SearXNG-ga, web fetch, todo, kalender), projektid süsteemipromptide ja tool-konfigiga, failide üleslaadimine (tekst, pdf, pildid), backend configuration UI, kasutajakontod isoleeritud andmetega, API-võtmed AES-256-GCM-iga krüpteeritud. Tech stack: React 19 + TypeScript + Vite + Tailwind ees, Express + TypeScript + SQLite taga, deploy CI/CD kaudu Dockeriga. Pooltest asjadest mul pole siiani aimu, et mis mida tähendab, ja mida teeb, aga luban iseendale, et ühel päeval saavad needki asjad selgeks.

See ülesanne oli mu jaoks kõige vingem ja kulutasin sellele kõige rohkem aega — võib-olla liiga paljugi. Mitu korda otsustasin, et on valmis, ja siis tegin ikka jälle edasi ja lisasin/muutsin midagi. Väga addictive tegevus.

Ülesanne nõudis ka käsitsi inimretsensiooni ühele lõputööle ja võrdlust AI omaga. Valisin neljanda lõputöö (Kadri Kuke 2025 IABM töö), jooksutasin grader-skill'i, sain täis ai-review.md (AI-pakutud koondhinne 3/5) ja seadistasin võrdlusstruktuuri. Aga käsitsi inimretsensiooni ma lõpuks täismahus ei kirjutanud — jäi pooleli ja ei olnud aega. Tagantjärele oleks see olnud kõige sisukam tükk, sest just seal oleks näinud konkreetsete näidete pealt, kus mudel oma erialavaldkonnas eksib ja kus tugevam on.

mida sellest kursusest kaasa viin

Kõige suurem avastus oli see, et "tavalisel inimesel tänavalt", kellel pole üldse programmeerimistausta, on päriselt võimalik ehitada päris töötavaid asju. See oli minu jaoks täiesti uus teadmine ja see oli ka üsna sõltuvust tekitav tegevus, sest kogu aeg tuleb lahedaid ideid ja kuna ma nüüd tean, et kõik on põhimõtteliselt ühe (hea) prompti kaugusel, siis on raske lõpetada.

Samas õppisin ka seda, et ainult hea ideest ei piisa, agent vajab konteksti, piiranguid ja kriteeriume, et midagi kasulikku teha. Oma mõtteid täpselt sõnastada on omaette oskus, mis paranes iga projektiga märgatavalt. Eriti IT-kaugema taustaga inimesele on oluline osata kirjeldada, mida sa tegelikult tahad, sest AI saab aru sellest, mida sa kirjutad, mitte sellest, mida sa mõtled.

Minu arvamus Kursusest​

Kursus oli korralik, sain palju targemaks, eriti esimeses ülesandes, kus oli palju erinevaid asju teha, sain aru kuidas ai-d saab kasutada ja mis on nende piirid. Kursus edaspidi minu arvates võiks olla pikem nt 6 EAP või isegi 9 EAP (ma muidugi ei kujuta ette, missugune Käveri 9 EAP maht on, tundub hirmus), et käia üle rohkem raamistikke ja materjale nt igal ülesandel oleks kohustuslik mingit kindlat raamistikku kasutada. Tunnen, et kursus oli igati väärt võtmist.

Minu arvamus ai raamistikest​

Igale asjale siin nimekirjas kuulub mu enda "skill issue" juurde.

GSD​

  • Puhas saast
  • raiskab kohutavalt palju tokeneid
  • raiskab kohutavalt palju aega
  • Väga palju lugemist ja nigelad tulemused
  • Token- ja ajakulu on ebaproportsionaalselt suur võrreldes saadava kasuga
  • puhas vibe coding prügi

Open spek​

  • Korralik
  • Natuke liiga väike
  • Greenfieldiks nõrgem kui tahaks (natuke enda skill issue, üritan liiga palju korraga teha, eriti alguses)

Spek kit​

  • Hea
  • Natuke suur, kuid pigem see greenfieldiks
  • väiksemaid asju pigem ilma selleta, see üldpildi jaoks
  • pole nii palju veel kasutanud, pean rohkem tutvust tegema

Claude code plan mode​

  • Hea
  • Väga hea, kui tead täpselt mida tahad ja projekt on pisikene
  • väga lihtne kasutada

Kuidas edasi tegutseda plaanin​

  1. Teha enda koodi templated, et saade need esimesed x tuhat rida koodi, mis kõige tähtsamad, siis kindlam tunne kui ai hakkab ülejäänut "pattern matchima".
  2. Kirjutada iga viimane kui asi mis vaja when, then, and formaadis välja enne ühtegi koodi rida kirjutamatta ja sealt edasi itereerida.
  3. Olla veel detailsem kui enne
  4. Olla rohkem valmis kõike ära kustudada, kui väga lappab ja spekki kohandada ja siis uuesti proovida

Essee​

Tarkvaraarendus agentidega aine vaimustust pole tagasi hoidnud ei kodus, tutvusringkonnas ega tööl. Lastele oli lahe rääkida, et emmel on kodutöö, kus AI-ga tuleb AI-d teha ja ise võib maksimaalselt 5 rida koodi kirjutada. Lisaks on neil motiveeriv näha, et kui koolis õppida, siis on võimalus ülikoolis ägedaid asju teha. „Küisme emme tehtud AI-lt" annab uuele teadmisele hoopis suurema ja kaalukama väärtuse. Sama põnev on olnud neil kõrvalt jälgida ka, kuidas testimiste käigus grok ilmaennustuse küsimusele igasuguste fetchimiste, skillide jmt-seta vastab "I'm an AI, not a meteorologist!"

Noorima lapse haiguse ajal oli näiteks väga armas tema tuju tõsta sellega, et kirjutasime Telegrammis emme MyAgentHermesBot'ile, mis teksti lapse enda veebilehele kirjutada või mis värvi taust panna. Või kui Among Us'i fännist laps tahtis oma teemaga veebilehte, siis tegi MyAgentHermesBot just sellise nagu fänn soovis (sain lapselt juhised isegi enne õige värvikood välja otsida ja anda bot'ile tellimus värvikoodina). Said oma lehtede URLe edasi jagada. Isegi see, et Telegrammi kanali püstipanek algas suhtluesst BotFatheriga, oli laste jaoks naljakas.

Õpetamismeetod „paneme käed koodi" sobib mulle ülitäpselt, see on küll raske, aga teooriat suudan mõista ja mõtestada vaid praktilise tegemise käigus. Koodimise ainete puhul on minu jaoks oluline enda setup'is kaasa tegemine, „paneme käed koodi" käigus tean täpselt, kus ekraani nurgas mul mille jaoks ruumi on ja saan hoida enda joaks vajaliku silma all (ja seda on mul palju vaja silma alla):

Kui ekraan koodimisega on sõna otses mõttes nina all ja kõrvalaknas, võib-olla mängib siin rolli lühinägelikkus. Kuna koodi kirjutamisel on detailid olulised, eelistan kasutada Teamsi – pildi kvaliteet on parem kui Echos (pole Echo kollakat lisatooni), puudub „paneme käed koodi" kaasategemisel vägagi häiriv viide. Samas on Echos hea klassiruumi heli kellegi küsimuste/kaasarääkimiste korral kuulata. Lisaks on kiire kaasategemise korral on minu jaoks oluline backup võimalused, kui ühes kanalis kaob pilt lülitun teisele jne. Ainega alustades tähendas minu jaoks AI kasutus arenduseks midagi paarisprogemise-laadset, kas arutad läbi, lased teha jne. Kursuse lõpuks olen jõudnud BMAD'ini ja ledinud, et bmad-quick-dev'i on hetkel midagi mulle.

Mingeid varasemaid aineid kuulates, on läbi käinud mõte, et arenduse erialal lõpetajad võiksid olla selliste teadmiste ja kogemustega, et tahaks neid oma ettevõttesse palgata. Selle aine käigus kuulates, et "liiga leebe Käver" võiks karmim olla. Enda näite pealt võin öelda, et sellistes leebetes tööõhkkondades on minu kohta mitmeid kordi öeldud, et „sul ei kuku õunad korvist," „sinu tegemistel ei pea näpuga järge ajama, kas midagi jäi tegemata või on ainult osaliselt tehtud" ning et „võtad täieliku vastutuse oma tegemiste ja tulemuste eest".

Tarkvaraarendus agentidega aine saab minult nii palju üle maksimumi punkte, kui on võimalik anda. Minu meelest ülivajalik arenduse aine – AI-ta arendamine väga ei motiveeri enam. Samas ei kujuta ette, et eelneva ja praeguse tausta-/kogemuseta nautida oskaks, vajan ikka enda panust ka. Tänu AI-ga möllamisele, tunnen end tööl mingitel hetkedel arhitekti rollis, rääkimata kolleegide küsimustest ja pöördumistest, mis korduvalt on tekitanud mõtte „ega ma mingi vanemarendaja pole". Praeguses hetkes tunnen, et olen õiges kohas, teen enda jaoks õiget asja. Aine panus kiirelt areneva ja muutuva valdkonnaga kursis olemisel (sinna aitamisel) ja kaasategemisel on minu jaoks väga olulise väärtusega.

Kodutöö 1 - Chatbot​

Valmis AI-põhine veebirakendus, kus saab kasutajana sisse logida, vestlusi pidada, vestluste ajalugu salvestada ning erinevaid backende seadistada. Rakendus toetab OpenAI-compatible ja Anthropic mudeleid, API võtmete serveripoolset krüpteeritud hoidmist, projektipõhiseid system prompt’e, failide üleslaadimist ja mudelile antavat projektikonteksti. Vastused tulevad kasutajale token-haaval SSE streaminguga.

Lisaks tavalisele vestlusele valmis ka tööriistasüsteem, mille kaudu mudel saab kasutada näiteks veeb otsingut, veebilehe sisu lugemist, todo-listi, kalendrit ja praeguse aja küsimist. Frontend on tehtud Reacti ja TypeScriptiga, backend Expressi ja TypeScriptiga, andmebaasiks on SQLite ning kogu rakendus jookseb Docker Compose’i abil. Põhirõhk oli sellel, et aru saada, kuidas chat-rakenduse päris osad koos töötavad: streaming, providerite erinevad formaadid, tool calling, autentimine, failid ja deploy.

Arendamiseks kasutasin peamiselt kahte raamistikku: GSD ja OpenSpec.

GSD oli minu arvates päris kehv – liiga palju MD faile, mida lihtsalt ei jõua läbi lugeda; sööb ohtralt tokeneid; järg võib ära kaduda ja kord läheb päris kiiresti käest ära, kui tekib poole arenduse käigus idee mingile asjale täiesti muud moodi läheneda. Ühesõnaga liiga bloated oli see raamistik minu jaoks, väga vähe kontrolli toimuva üle. Läksin poole arenduse pealt OpenSpeci kui ka tavalise Codexi plan mode kasutamise peale üle.

OpenSpec oli igati asjalik. Toimib paremini, kui on juba piisav koodibaas olemas. Suurem kontroll töövoo üle ning saab featuuride arendamisele läheneda detailsemalt samm-haaval, on ka rohkem viitsimist specid üle lugeda enne koodi genereerimist. Muidugi eeldab, et arendaja ise teab täpselt, mida ta tahab järgmisena teha. Greenfieldiks on ta natuke nõrgavõitu, kuid siiski igati parem, kui see GSD slop.

Üldised muljed aine ja õpitu kohta​

Ainest oli väga palju kasu, edaspidi võiks olla see 6 EAP-line. Jäi meelde seisukoht, et esimesed 1000 rida koodi saavad otsustavaks, et missugune saab edasine koodi kvaliteet olema. Isiklikult oli kõige rohkem kasu skillide loengust ja SDD põhimõtetest. Minu jaoks oli OpenSpec kõige meeldivam agentne raamistik, mida käsitleti kursuse jooksul. Olen võtnud selle ka väljaspool ainet kasutusse.

4. Reflections​

This part is done by me manually.

First of all, what I really like the most about this course is that I understood there is no magic in it (like Andres always says) - its just step by step things happening after one another and in the end, we have this beautiful thing called AI. That means the more controlled the steps are, the better. I learned I can control these steps by having good prompts, the more specific, the better.

Secondly, for me, as of TODAY, it just proved me the complexity has moved up a level. And thats super good. I always liked thinking about how systems should connect with each other rather than manually typing out something I already have in my head (at least I think so). But what I mean is that the good engineers immidiately stand out with using it well.

Thirdly, I understood AI is really good when you are leading solo projects. But with a team full of many people where your decision can impact the decision of the next people etc, speaking with business people, figuring out flows? Thats where the bottleneck is. And I personally like that bottleneck, because we can pump out code fast but we really need to spend time on the decisions we make.

What I liked especially about this course:

  • Understanding what is a SKILL (just a well documented, step by step prompt)
  • Understanding what is a TOOL USE (you give the model the knowledge that it can predict some function usage and it will predict it, our code will then handle actually using that function)
  • Understanding what is an AGENT (just a loop with tools to use)
  • Understanding how request/response cycle works with AI (one response split into chunks)
  • Understanding AI is pretty good when the solution in my head is clear and I can give correct boundaries
  • Understanding AI can make crazy decisions when it does not have boundaries
  • Understanding what problems exist in the AI world exactly - that compute is expensive, how providers try to save up on costs etc. Its very cool to think back in 15 years on how did they actually solve it (or not)?
  • Understanding what SDD is and how important it would be to keep spec and code in sync

What to do better:

  • I dont know...
  • ...because I feel like this course covered just exactly what I needed to know. We do not have many answers yet but this course taught me foundations and these will not change

Tere, Antud email on kirjutatud 100% AI-vabalt ja filtrita, isiklikke emotsioone ja arvamust väljendatuna. Alustuseks ma tänan Teid parima kursuse eest senini minu õppimise ajaloos, mida ikka on juba kogunenud 47 aasta jooksul 🙂. Ma olen taas (üli)koolis tagasi üle 23 aasta ja antud kursus ületas minu ootused nii mitmelgi moel. Esiteks see energia, vabadus ja mis kõige tähtsam – julgustus katsetama ja eksima – oli midagi ootamatut, aga samas superpositiivne. Antud aine 3 AP on ajalises mõttes kõige kulukamad, mida kogenud, samas parimalt kasutatud. Tegelikult on mul täna väga keeruline hinnata, mis on see, mis ma panustan antud aine läbimiseks ja mis on reaalselt läinud igapäevaülesannete täitmiseks. Kasu on juba täna käegakatsutav nii rahaliselt kui ka emotsionaalselt. Rahalise poole pealt oleme suutnud ettevõttena säästa reaalselt viiekohalise summa vaid mõne kuuga välisarendaja teenuste arvelt, seda just antud kursuselt saadud informatsiooni, tehnikate ja mis kõige olulisem – julgustuse arvelt. Emotsionaalselt – see meelerahu, mida annab teadmine ja määr usalduse osas AI tehnoloogiaid kasutada, ja mitte vähem oluline, nii mulle isiklikult kui meeskonnale saavutusrahuldus. Produktiivsus, mille oleme saavutanud, on märkimisväärne, ja tunnustus teistelt tiimidelt arenduskiiruse, funktsionaalsuse ja teiste parameetrite osas on omaette valuuta. Tulles täpsemalt antud kursuse ja ülesannete juurde, siis mulle väga meeldis struktuur, ülesehitus ja valitud ülesanded. Siinkohal pean üles tunnistama, et kursusel saadud informatsiooni olen kasutanud oma tiimisiseselt "knowledge sharing" eesmärkidel ja mitte ainult info jagamiseks, vaid ka reaalselt praktikasse pannud. Mis on kõige parem kokkusattumus – saadud informatsioon toetas meie igapäevaseid ambitsioone kasutada tehisintellekti võimekusi mitte ainult mõne koodirea kirjutamisel, vaid teiste ettevõtte funktsioonide toetamisel. Chati ülesandest sain inspiratsiooni oma klientidele parema, operatiivsema ja kvaliteetsema toe pakkumisel. Oleme arendamas lahendust, mis seda võimaldaks meie enda teadmusbaasilt. Lisaks plaanime luua lahenduse sisemiseks kasutamiseks, mis võimaldaks paremini ja spetsiifilisemalt ette valmistada kliendikohtumisteks ja follow-up info edastamiseks, seda kõike eel- ja järelinfo põhjal.

Nagu mainitud, siis ülesannete ülesehitus ja skoop oli minu arust väga hea ja andis võimaluse tutvuda erinevate aspektidega AI kasutamisel nii tarkvaraarenduseks kui ka äriprotsesside loomiseks. Kui siiani olin kasutanud LLM-i väga tavalisel ja lihtsal moel, siis tänaseks on võtted muutunud palju. Minu põhiline töökeskkond on IntelliJ IDEA, selles kasutusel nii Kilo Code kui Claude Code CLI. Keerulisemate, kompleksemate terviklahenduste loomiseks kasutan spec driven metoodikat, mis annab võimaluse dokumenteerida ja vajadusel tagasi võtta mingeid otsuseid. Väiksemate muudatuste, featuuride jaoks sõltuvalt keerukusest sageli Ask -> Architect -> Code -> Review -> "Commit" (mille ise lisanud Kilole, plaanin veel täiendada). Kasutamise kogemustest võiks välja tuua paar asja: 1. Mudeli valik – keerulisemate asjade jaoks kindlasti mitte kasutada lihtsaid mudeleid. Teinegi kord jäi mudel vahetamata ja vastus ei vastanud ootustele. Samas kui spec olemas, on kodeerimisel kasutada näiteks "Sonnet"-it täitsa OK. Ja tuli ka ette, kus ühe ülesande jaoks tuli vahetada mudelit, kuna "jooksis kinni". 2. Alati lasta teha review, see leiab teinegi kord asju, mis vajavad muutmist, parendamist. Kõige keerulisem minu jaoks on täna "skills"-ide teema – kuidas neid õigesti luua ja rakendada, aga küll praktika õpetab, tuleb proovida, katsetada ja hinnata. Sellele vaatamata oleme hakanud looma töö kiirendamiseks "command"-e. Mida peab kindlasti esile tooma – kasutatud mudelid (põhiliselt Opus) saavad väga hästi hakkama terviklahenduste loomisel alates planeerimisest kuni CI/CD pipeline'i loomiseni. Samuti ei jäänud hätta refaktoorimise ülesannetega. Loomulikult peab ise lahendusest üle käima ja olema. Peab ise aru saama, mis lahendus peab tegema ja päriselt teeb. Olulisemad osad on vaja kriitiliselt üle vaadata ja esitada täpsustavaid küsimusi erinevate nurkade alt. Näiteks valideeri, kas töötab nii ja naa, mis juhtub, kui olukord, sisend on selline ja selline. AI on kindlasti väga suur abimees, aga ise peab ikka olema loodavas lahenduses 100% kindel. Mis on natuke murettekitav, on enesesundimine mitte laisaks muutuda. Kui teatud kindlus, kogemus saadud, hakkab tekkima võib-olla liigne usaldus ja alati ei kontrolli 100% tulemust üle. Seda peab endale ikka ja jälle meelde tuletama. Ja kõige selle tulemusena teatud oskuste lisandumine kas peatub või isegi tekib taandareng. Samas annab see võimalusi uurida ja õppida teisi asju, milleks kas varem polnud aega või vajadust. Tuleb tõdeda, et mida vähem sa tead, seda lihtsam on. Momendil on ideid, plaane ja suundi, kuhu minna, nii palju, et hoia ainult tagasi. Samas tuleb tunnistada, et kogu selle elevuse juures tuleb ennast kogu aeg korrale kutsuda – loe läbi, mis intellekt kirjutab, mida ütleb plaan, mida soovitab review jne. Olulisemad teemad ja elemndid millega järgmistel perioodidel plaanin rohkem tegeleda: RAG, MCP ja CI/CD. Kõigis nendes on oma spetsiifika, rakendused ja tehnikad mis vajavad süvenemist, samas olulised ettevõte protsesside seisukohast. Teie energia ja meetodid on täiesti erinevad varasemast, dekaadide tagusest kogemusest ülikoolis.Soovin Teile jõudu ja jaksu samamoodi jätkamisel ja loodan teiega kohtuda mõnes teises loengus. Aitäh!

My personal thoughts​

I will keep this short and simple. I came on this course mostly because I had already been playing around with LLM tools myself and wanted to see if there is anything I missed myself. To my surprise, yes, I am not all-knowing. There was still alot for me to learn, mostly in the realm of additional tooling you can download for your agent harness.

Agentic development (and LLMs in general) are still a Wild-West territory, but some norms have started to shape out. That mostly being the return of waterfall and spec-driven development taking the grandstand. I personally have started using BMAD for assisting in project building. While yes it is a total burden on my tokens, it at the same time delivers the most reliable processes and results. Those two are especially important if you plan on using agents for work that involves money and is not a hobby project. With the help of BMAD and knowledge gathered from this course I have managed to build up a rather sophisticated CMS system for managing online textbooks that uses gitea as a backend and each repository lives in a separate repository - basically trying to get public educators to use markdown-based editing. While working on that process I realized that coding is in the past, going forward the only thing that matters are your system design competencies and your understanding of the customers needs. Those two sadly are very hard to teach at any level and only can come from real experience. We as educators can try to nudge the student in the right direction in that regards.

In terms of this course, for masters level it definently has to grow into a 6ECT course with a 3ECT course as a prerequisite for bachelors students. There is alot of topics to cover and not enough time.

Tarkvaraarendus agentidega (ITS8090) — final report

See aine tegi selgeks, et agentidega arendamiseks peab ikka ise ka midagi oskama. Minu jaoks kujunes aine natuke selliseks, et kuidas AI aitab kasutada AI-d. Kuigi kõik ei õnnestunud nii hästi kui tahtnuks, siis tänu sellele ainele ja abilistele (Taavi ja Illimar) saan nüüd tulevikus oma pea ja AI abiga püsti vajaliku setupi (docker, CI\CD jne). Nende arendaja nn baasoskuste jaoks võiks olla eraldi mingi pisiaine (moodle kursus), kus saaks vajalikud teadmised ilmselt mitmete ainete jaoks. Loengus kõlas mõte, et igale IT tudengile võiks õppima asudes lisaks matriklinumbrile ka oma VPS anda, kus saab erinevates õppeainetes hullata. Osalen Tartu Ülikooli poolt korraldatud koolitusel 'Andmeinseneride täiendkoolitus' ja siin aines omandatud oskused on seal täiega ära kulunud. Enam ei ole nn tavaline koodi copy-paste mees vaid kasutan KiloCode+Codex+Claude Code jne nüüdsest ja väldin igasugust käsitsi koodikirjutamist. Aine ise oli mahukam kui 3 EAP, aga seda oli ka enne teada, et Käveri puhul 3 -> 6 ja 6 -> 9 ja 9 -> 12 ehk sama raha eest saab rohkem. Arvestades teemade rohkust ja pidevat muutumist võiks seda ainet jagada et mingid teemad on eraldi (nt skills, personal agents) ning nt mingit tehnilisemad asjad eraldi. Aga samas võib neid ka koos olla, aga järjekord võiks olla lihtsamast->keerulisemani. Hetkel oli arendusega vähem kokkupuutunuid inimestele esimene ülesanne paras malakas pähe. Sai käidud kõigis loengutes-praktikumides, ühes osalesin olude sunnil kaugelt. Kulutatud aeg nii kohapeal kui iseseisvalt on läinud asja ette. Sain ülesanded tehtud kuidagi, väga rahul nendega ei ole, aga nüüd tean kuidas paremini teha - tuleb rahulikult ja järjepidevalt projektiga tegeleda ja mitte nn auke sisse lasta. Sain aru, et agentidega arendamiseks peaks ikka mingi baas ka olema, ei ole nii, et julge pealehakkamine on pool võitu. Tegelikult hetkel nii kujuneski ja sellepärast pidigi pool aega jamaga tegelema.

Lisan eesti keeles ja vabas vormis oma mõtted ülesandest, kursusest ja üleüldiselt LLM-agentidega töötamisest.

Vestlusrakenduse ülesande lahendamisel oli minu jaoks väga kasulik 10. nädala töötuba. Arenduse detailid said seal piisava põhjalikkusega lahatud. Selles ülesandes OpenSpec spetsifikatsiooni (spec) kasutamises tekkis mul teatud arusaamatus: kui speci implementeerimise käigus avastad, et seal on vead sees, siis kas sünkroniseerid selle delta-speci enne põhispeciga ära ja lood uue parandusspeci või lood selle ilma eelmist sünkroniseerimata? Ma kasutasin oma töös viimast lähenemist. Aga mure oli kogu aeg selle pärast, et spec vastaks implementatsioonile ja vastupidi.

Siin tekkis mul ka tõdemus, et kehvem keelemudel soovib speci saada rohkem detailsust. Parem keelemudel suudab lüngad paremini ära täita. Nii et kui sa lood speci hea keelemudeliga ja pärast kasutad kehvemat, siis suure tõenäosusega tuleb selle implementatsioon vigane.

Vastav tehnoloogiastäkk sai valitud puhtalt selle tõttu, et oleksin nendega võimalikult tuttav. Võib-olla mõned asjad võivad olla seetõttu aegunud valikud (nt Bootstrap). Olen ise C++ arendajana pikka aega töötanud ja pole veebiga väga palju pidanud kokku puutuma – viimati maadlesin 10 aastat tagasi Angulari esimese versiooniga. Siit tuleb mu teine tõdemus, et mida vähem on kogemust ja arusaama, seda rohkem toetud keelemudeli valikutele. See loob soodsa pinnase vigadeks.

Teises ülesandes sai õpitud, kuidas skille luua. Selle ülesande täitmisel jõudsin tõdemuseni, et agentne ökosüsteem (harness, agents, skills jne) on väga kasulik ka muudes valdkondades kui ainult tarkvaraarenduses. Teisted valdkondade inimesed ei ole seda veel enda jaoks avastanud. Ma kujutan ette, et praegune andmekeskuste ehitusbuum kestab veel mõnda aega.

Kolmandas ülesandes olid põhilised mured, millega maadlesin, failiteede õigused VPS-is. Hermes jooksis teise kasutaja all kui GitLab Runner. Mure oli ka GitLab API päringutega konteineris. Samuti oli vaja gitlab-web-manager skilli parandada ja parendada.

Tööriistadega nagu Hermes või OpenClaw võib veidi vaeva nähes ehitada võimekaid personaalseid agente kõikvõimalike tegevuste automatiseerimiseks ja juhtimiseks. Siin tekkis siiski mure turvalisuse pärast. Kui palju ligipääsu oma elule sa ikka agendile anda tahad ja kui palju inimesi suudab seda süsteemi turvaliseks ehitada ja turvalisena hoida?

Boonusena, antud ülesannete väliselt, katsetasin veidi ka lokaalse Qwen3.6-27B mudeli piire, mida suuremeelselt läbi AI-proxy tasuta kasutada võimaldati. Tahtsin näha, kas mudel on piisavalt pädev, et igapäevatöös C++, Qt6, QML-i ja CMake'i tehnoloogiastäkiga seda mõistlikult kasutada saaks.

Lühike vastus on, et jah, saab, aga temal tuleb oluliselt rohkem kätt hoida kui pilve tippmudelitel. Väga paljudes ettevõtetes ei ole aga võimalik pilvemudeleid kasutada ja seetõttu on nõudlus kindlasti lokaalsete mudelite järgi olemas. Aga üldiselt jäin lõpptoodanguga väga rahule.

Arvan, et antud kursus on hädavajalik kõigile tarkvaraarenduse tudengitele, aga mitte ainult. Ka paljud vanemad arendajad siin Eestis peaksid endale keelemudelite ökosüsteemi selgeks tegema, et tagada oma konkurentsivõime ja ka nende ettevõtete konkurentsivõime, kus nad parajasti töötavad. Fakt on see, et džinni me pudelisse enam ei topi ja nüüd on vaja uue reaalsusega kohaneda.

Kursuse jooksul valmis kolm projekti. Minu senised kogemused tarkvaraarendusega nullilähedased. Kursuse esimene osa läks suuresti mõistetest aru saamisele (mis on SSE, VPS, Docker, miks CI/CD), aga lõpuks oli iga projekt eelmisest arusaadavam.

Ülesanne oli ehitada ChatGPT-laadne veebirakendus.

Esimesed tunnid läksid sellele, et üldse aru saada, mida tähendab SSE, mis on Docker, miks on vaja CI/CD'd ja kuidas terminal töötab. Kasutasin Claude'i abi kogu protsessi vältel — nii koodi kirjutamiseks kui ka mõistete selgitamiseks. Kõige rohkem aitas see, et iga sammu sai enne küsida "mida see teeb ja miks?", mitte lihtsalt koodi kopeerida.

Projekti arendasin spec-driven meetodiga (OpenSpec): iga feature jaoks kõigepealt spetsifikatsioon (propose), siis ülevaatus, siis implementatsioon (apply), siis arhiveerimine. See tähendab, et kogu koodibaas peaks olema spec'ide põhjal taastatav — repo-s on 26 spec-faili kõigi feature'de jaoks. Kõik reeglid ja anti-pattern'id on kirjas CLAUDE.md failis.

Mida õppisin​

Kõige suurem õppetund oli see, et "spec-driven" lähenemine päriselt toimib.

Teine oluline asi: vigade parandamine on pool tööst. Iga feature töötas testides, aga live keskkonnas tekkisid üllatused — SearXNG keeldus JSON-it andma (vaikimisi keelatud), pildid kadusid andmebaasi salvestamisel, drag-and-drop avas faili brauseris failide üleslaadimise asemel.

Kolmas: SOLID printsiibid pole ainult akadeemiline jutt. Kui Backend Config UI oli algusest Router → Service → Repository kihtideks jagatud, oli hiljem testi kirjutamine ja muutmine triviaalne.

Mida sellest kursusest kaasa viin​

Kõige suurem õppetund on, et programmeerimistaustata inimene võib päriselt töötavaid asju ehitada kasutades AI-d targalt.

Hea ideest üksi ei piisa. Agent vajab konteksti, piiranguid ja kriteeriume. Iga projekt õpetas paremini sõnastama, mida tegelikult soovin. SKILL.md description-väli, OpenSpec spec'id, Hermesi reference-failid — kuidas anda agendile piisavalt konteksti, et ta saaks õigesti aru, aga mitte nii palju.

Töö on ca 80% setup ja 20% sisu. Project 3 ehitamise puhul võttis enamiku ajast VPN-i, võtmete, Discord intent'ide ja proxy konfiguratsiooni paika saamine. Agendi tööle saamine, ise võttis väga vähe aega, aga kui kõik vundamendi-tükid paigas, on rakendus iseenesest lihtne.

Üldine tagasiside ainele​

Üldiselt jäin ainega väga rahule. Aine kirjelduses seatud eesmärk sai täidetud: mõistan nüüd LLM-ide tööpõhimõtet ja seda, et midagi otseselt maagilist seal ei ole. Samuti saan erinevate AI-lahenduste puhul paremini aru, milline osa on LLM-il endal ja mis on kõik see muu, mis sinna ümber ehitatud on (skillid, rakised, MCP jt). AI valdkond on viimaste kuudega arenenud suurte hüpetega ning ülikool ei pruugi alati järele jõuda, kuid üldiselt võiks see aine meie õppekavas lausa kohustuslik olla.

Koodi kirjutamisel toimib see kõik tõesti hämmastavalt hästi ning nagu iga mugavusega, harjub inimene sellega kiiresti ära. Tunnen, et tekib kohatine mõtlemislaiskus ja programmeerimine kipub vahel vaibimiseks ära minema, kuigi tean, et ei tohiks. Motivatsioon päriselt aru saada tekib alles siis, kui midagi on katki – sest vea adekvaatseks kirjeldamiseks peab vähemalt natuke mõistma, mis toimub.

Programmeerimisõppe osas nõustun, et suund tõenäoliselt muutub: vähem rõhku läheb koodikirjutamise oskusele ja rohkem n-ö kõrgemale tasemele, mida varem valdas ehk pigem arhitekt – millistest osadest süsteemid koosnevad ja kuidas need suures plaanis töötavad. Detailid ei ole tingimata nii olulised kui põhimõtted ja sõnavara.

Implemented chatGPT but better in some ways. Deployed on the taltech provided VPS with the CI/CD pipeline set up. (happy that i got to see how the workers are configured for the first time - at work everything has always been set up already) At first i did Openspec after which i made a new project for speckit and then wiped the progress again and made it fully in BMAD. Interesting but took an insane amount of time for me since i did basically all of it in bmad and i had no idea that each step took so long and i think even the number of steps was surprising. I also was extremely concise in not making any mistakes and took care of any questions that arose instead of telling it to "do modern best practice" or something which again led to a huge amount of time spent. Bought the Claude max 20x subscription during this and i'll have to say its worth it even after it. Also did multiple runs of code reviews with codex which seems to have led to a pretty clean implementation. Also i think i used the playwright docker mcp for the first time during this which led to suriprisingly good visual result (to me surprising at the time)

Project 2​

Implemented pdf-to-md and thesis-grading skills. Was pretty straight forward, some issues were found and immediately fixed. Didn't take alot of time at all - at least the implementation. The thesis reading itself and the report took alot of time and was pretty exhausting. Will definitely lean towards using AI for this in the future. Immediately after implementing the skills for the first time I started making them at work and am now basically the main contributor of agent skills by a huge margin and have proven to be extremely useful.

Overall​

Speckit to me didnt feel as good to me as the others and i decided to use it on another project i had to make for taltech (an AI git grading thing) although i have to admit i didnt use it correct at first (changing old spec instead of just going for new when i needed to change implementation - at least i feel like it was the wrong approach). Openspec i feel like i would use again if the project wasn't too big and the change isn't too small although I feel like this is a rare circumstance. BMAD was great, maybe it's placebo but it seemed to do things well even though it took alot of time to accomplish something. BMAD i also tested out at work for a rather large scale load testing project and it again did well (document the existing project first and spec the change). For bigger projects I will to current knowledge definitely use it and for smaller changes ill probably use no framework at all and just use claude code directly (although havent for example tried GSD which might end up filling that gap better).

5. Refleksioon​

Üldiselt oli see väga kasulik aine. Sain täpselt seda, mida tahtsin - paremad tööriistad ja raamistikud millega tööd edasi teha. Mult küsiti ühel koolitusel, kus ma AI-st rääkimas käisin, et MIKS ma ülikooli läksin, sest youtubes on juba kõik nagunii olemas. Sain vastata, et enamus youtube soovitab minna Loveable ja kirjutada sinna et tahakas ägedat veebi...sinist...ja sätendavat...ja saab. Siin aines käis ikka läbi openspec, esimesed 1000 rida koodi, basic turvalisus jne. Väga silmiavav näha sellist päris arendaja lähenemist. Algorütm podcasti osa oli ka huvitav. Ma arvasin, et see fail rate pole nii halb - proovin nüüd ise mitte see statistika olla :D

Ma openclaw hullusega kaasa minna ei tahtnud ja tegelikult oli meeldiv üllatus et siin vaja Hermes installida. Ma tegelikult olen codex, claude code/cowork võimekusega rahul ja lükkaisn seda agendi osa kogu aeg edasi sest otsest vajadust ju polnud. Seega väga tänulik, et tänu tähtajale pidin ikka selle kogemuse ka läbi tegema :D Nüüd vaja ainult seda Hermest veist paremini tundma õppida ja mulle tundub, et Discord Telegrami vastu vahetada...

Cross-cutting reflections​

A few patterns showed up across all three assignments that are worth pulling out of the per-project write-ups:

The course rewards reading the spec twice. Assignment 1's nginx SSE buffering, Assignment 2's IAAB/IADB/IVSB vs IDBB curriculum confusion, and Assignment 3's "build vs configure Hermes" mis-scope all came from skimming. The cheapest fix in every case was re-reading the prompt and the linked canonical doc before writing code.

One VPS, three deployments, one port 80. All three projects either deployed to or interacted with the same course VPS (192.168.181.201). Sharing a single port across assignments forced explicit "which container is live right now?" decisions and made me appreciate Docker's docker stop / docker start lifecycle rather than rebuilding everything.

OpenSpec was the biggest workflow win. Spec-driven changes under openspec/changes/<change>/ felt heavy at first, but they made the assignments easier to break into shippable slices. By assignment 3 I was treating an OpenSpec change as the unit of work, not a feature ticket.

"Just configure it" beat "build it from scratch" twice. Assignment 3 explicitly (Hermes is a published image), and Assignment 1 indirectly (using SearXNG and Browserless as sidecars rather than coding a web-search tool). Time spent looking for prior art paid back >10× both times.

Gotchas folded into SKILL.md / READMEs are the real artefact. The skill specifications and project READMEs accumulated lessons-learned faster than my private notes did, because every gotcha forced a SKILL.md edit. By the end of Assignment 2 the SKILL.md gotchas section was demonstrably catching real issues on the next cohort run — proof that the feedback loop the assignment was supposed to demonstrate actually works.

LLM-as-judgment, code-as-orchestration. The most reusable design pattern across the three projects: keep the qualitative judgment in the host LLM following a markdown procedure, and use code purely for the deterministic plumbing (discover files, call APIs, persist results). Assignment 2's grade.py is the cleanest example; Assignment 3's gitlab-web-manager skill takes it to the extreme (zero code).

What I would do differently next round​

  • Smoke-test the API once before the batch run. Both Assignment 1 (provider streaming) and Assignment 2 (Mistral OCR) had eventually-consistent failure modes that a single 30-second test would have caught before a full cohort/UI run.
  • Reuse the VPS more deliberately. Three assignments competing for port 80 is silly. A simple nginx in front of the three apps on different paths would have let all three stay live simultaneously.
  • Write the per-assignment README during the build, not after. My best READMEs are the ones I drafted alongside the OpenSpec changes; the worst are the ones I bolted on at the end and immediately had to rewrite for the final report.

General feedback on the course​

I really liked this course. It was hard and time-consuming for me, but it was probably the most eye-opening subject I have taken in my first year of the master's. It genuinely moved me closer to feeling like a "wizard" — being able to point a competent agent at a real problem and ship a working result. Thank you, Mr. Käver.

A couple of suggestions for the next cohort, mostly from the perspective of someone who isn't a working programmer:

  • More onboarding tutorial for non-programmers. I struggled noticeably with setting up Claude Code / settings.json against the course ai-proxy (custom base URL, headers, the right model field, masked auth). There may well have been a lecture on it that I missed — I didn't manage to attend all of them — but a written, copy-pasteable "first 30 minutes" guide on the course site would have saved me hours, and would lower the bar for classmates whose background isn't software engineering.
  • VPS setup could be even more turnkey. Docker install, GitLab Runner registration, the gitlab-runner user's home directory ownership, port-80 conflict handling between assignments — each of these tripped me up at least once. A short "VPS day-zero" script or checklist (install Docker + compose, register a runner, create /home/gitlab-runner/web with the right ownership, document the shared-port-80 convention) would remove a lot of friction that has nothing to do with the actual course material.

Neither of these are complaints about the content — the assignments themselves are excellent and the build-up from "chat UI" → "skills" → "personal agent" lands really well. They're just the two places where I spent hours on plumbing rather than on the agentic ideas the course is actually about.