Program, ki ga nihče ne razume

Umetna inteligenca je pisanje programske opreme spremenila v pogovor. Odprla je vrata ljudem, ki ne poznajo programskih jezikov, izkušenim razvijalcem pa dala izjemno zmogljivega pomočnika.

Do nedavnega je bila razlika med zamislijo in programom zelo otipljiva. Uporabnik si je lahko jasno predstavljal orodje, ki bi prebralo račune iz elektronske pošte in pripravilo preglednico, vendar od predstave do rešitve ni vodila bližnjica. Naučiti se je moral programskega jezika ali najeti nekoga, opisati problem, se dogovoriti za ceno in čakati. Za večje sisteme je to samoumevno, za majhne, specifične naloge pa pogosto nima ekonomskega smisla. Nihče ne bo najel razvojnega podjetja za nekaj tisoč evrov, da bi mu izdelalo pretvornik iz natanko določenega PDF v natanko določeno obliko HTML.

Danes lahko isti uporabnik odpre pogovorno okno in napiše, kaj potrebuje. Sistem mu postavi nekaj vprašanj, sestavi program, ga požene, opazi napako, jo popravi in čez čas se na zaslonu pojavi rezultat. Uporabnik morda ne zna razložiti, v katerem jeziku je rešitev napisana, katere knjižnice uporablja in zakaj je v tretji vrstici zaviti oklepaj. Ve le, da je v vhodno mapo vložil datoteko in v izhodni dobil tisto, kar je želel. Če ne deluje, opiše težavo z besedami, kot bi jo razlagal sodelavcu: »Šumniki so pokvarjeni, datum je v napačnem stolpcu in pri prazni strani se program ustavi.« Nato poskusi znova. Takšen način dela je Andrej Karpathy, eden najbolj prepoznavnih raziskovalcev umetne inteligence, februarja 2025 duhovito poimenoval vibe coding, v slovenščini pa bomo uporabljali izraz programiranje po občutku. Ime je posrečeno, ker ne opisuje novega programskega jezika, temveč odnos do kode. Uporabnik se ne ukvarja več nujno z navodili, ki jih bo izvedel računalnik, ampak z občutkom, ali se nastajajoči izdelek »vede« prav. Gleda, govori, preizkuša in popravlja smer. Koda teče nekje v ozadju, podobno kot motor pod pokrovom avtomobila: pomembna je, vendar je za vožnjo ni treba razumeti do zadnjega vijaka.

Za amaterje in profesionalce

Tu se začne prva in najpomembnejša zmeda. Programiranje po občutku ni isto kot vsaka uporaba umetne inteligence pri razvoju programske opreme. Poklicni programer, ki modelu naroči, naj napiše teste, razloži neznan del starega sistema ali predlaga hitrejši algoritem, še vedno programira v povsem običajnem pomenu besede. Razume arhitekturo, zna presoditi predlog, prebere spremembe, preveri robne primere in zanje prevzame odgovornost. Umetna inteligenca je v tem primeru zelo zmogljiv pomočnik, nekakšna kombinacija iskalnika, dokumentacije, sodelavca in neutrudnega tipkarja.

Pri programiranju po občutku človek del nadzora zavestno izpusti iz rok. Ne preverja vsake vrstice, včasih je niti pogleda ne. Dokler program daje pričakovane rezultate, se pomika naprej; ko se zalomi, težavo znova opiše modelu. Programsko opremo lahko zato izdelujejo tudi ljudje, ki se nimajo za programerje. Oblikovalec si izdela pripomoček za preimenovanje fotografij, računovodkinja avtomatizira primerjavo tabel, novinar pa pripravi zbiralnik javnih podatkov.

Zakaj so modeli UI dobri programerji

Prelom se je zgodil prav pri programiranju, ker je programska koda sicer jezik, vendar strožji od vsakdanjega: ima natančno slovnico in rezultat, ki ga je mogoče hitro preveriti. Program se prevede ali pa se ne, test uspe ali pade, spletna stran se prikaže ali vrne napako. Model lahko svoj izdelek požene, opazuje posledice in jih popravlja. Z novimi orodji ne dopolnjuje več le naslednje vrstice, temveč prebere ves projekt, spreminja datoteke, uporablja ukazno vrstico in piše preizkuse. Pogovor z njim zato vse manj spominja na samodokončevanje in vse bolj na naročanje dela zelo hitremu, zelo načitanemu, a nekoliko nezanesljivemu sodelavcu.

Od kod njegova načitanost? Internet je dve desetletji zapisoval skoraj vsako programersko težavo, na katero je kdo naletel. Posebno mesto ima Stack Overflow, velikanski arhiv vprašanj in odgovorov, kjer so programerji skupaj pojasnjevali napake in brusili rešitve. Modeli UI so znanje črpali tudi iz javno dostopne kode, dokumentacije in forumov, pri čemer ostaja neprijetno vprašanje, kaj so smeli uporabiti, pod katerimi licencami in koliko avtorjev so vprašali za dovoljenje (namig – nobenega).

Programiranje po občutku zamegli mejo med izdelavo in razumevanjem.

Umetna inteligenca je postala izjemen pomočnik (tudi) zato, ker je pogoltnila velik del skupnega spomina programerske skupnosti.

Zdaj se krog obrača. Namesto da bi programer obiskal Stack Overflow, vpraša model, ki odgovori takoj in brez pripombe, da je bilo vprašanje postavljeno že leta 2011. Če ljudje ne sprašujejo javno, drugi ljudje ne odgovarjajo in na spletu ne nastaja nova zaloga preverjenega znanja. Modeli tako živijo od vodnjaka, ki ga njihova uspešnost pomaga prazniti. Starih odgovorov je veliko, toda nastajajo novi jeziki, knjižnice in napake. Brez javno zapisanih izkušenj bo prihodnje učenje težje in dražje.

Skoraj pravilno je lahko povsem narobe

Vendar težava ni le v količini znanja, temveč tudi v kakovosti. Na forumu je slab odgovor mogoče popraviti ali zavrniti, vidimo tudi, kdo ga je napisal in kako ga je ocenila skupnost. Jezikovni model pa vse to stisne v gladko poved, pri kateri izvor izgine. Odgovor je sijajen, skoraj pravilen ali pa samozavestno predlaga funkcijo, ki ne obstaja. Tovrstna orodja zato uporablja čedalje več razvijalcev, čeprav zaupanje v njihove odgovore ne raste enako hitro. Očitna napaka je poceni, ker jo hitro opazimo, verjetna rešitev z drobno, s skrito napako pa je draga, ker jo moramo najprej razumeti in šele nato popraviti.

Pri receptu za večerjo takšna halucinacija pomeni preslano omako, program pa lahko napačno zaokroža denar, razkrije osebne podatke, izbriše datoteke ali pusti odprta vrata napadalcu. Napaka morda več mesecev miruje in se pokaže šele pri primeru, ki ga nismo predvideli. Delujoč prikaz zato ni isto kot zanesljiv izdelek. Med njima so preverjanje, dokumentacija, varnostni pregledi in vzdrževanje. Če napačnega ravnanja ne znamo prepoznati, nas bo hitrost le hitreje pripeljala na napačen cilj.

Največja priložnost so majhne naloge

Kljub temu bi bilo programiranje po občutku neumno odpraviti kot igračo. Prav pri majhnih, notranjih in začasnih rešitvah je njegova korist največja. Podjetja so polna opravil, ki so premajhna za uradni projekt, a dovolj pogosta, da ljudem jemljejo dneve: prelaganje podatkov, čiščenje seznamov, izdelava poročil, preimenovanje datotek in pretvarjanje dokumentov. Klasični razvoj je zanje predrag, ker so analiza, dogovarjanje, izvedba in vzdrževanje dražji od prihranka. Če lahko človek, ki najbolje pozna problem, v popoldnevu izdela dovolj dobro orodje, se računica spremeni. S tem se ne zmanjšuje le cena posameznega programa, ampak se poveča tudi število stvari, ki jih je smiselno programirati. Ko nekaj postane cenejše in dostopnejše, tega navadno ne uporabljamo enako kot prej, le z manj zaposlenimi, temveč povsod. Preglednice pač niso odpravile računovodstva in fotoaparati v telefonih niso zmanjšali števila fotografij. Podobno bo morda s programsko opremo: posamezen izdelek bo cenejši, izdelkov pa neprimerno več. Poklic programerja zato ne izginja, se pa gotovo spreminja.

Sprememba bo najbolj boleča tam, kjer je delo mogoče dobro opisati in preprosto preveriti. Začetniki so nekoč dobivali manjše naloge, ob njih spoznavali sistem in počasi prevzemali več odgovornosti, danes te naloge najlažje opravi model UI. Podjetje lahko z manj zaposlenimi novinci kratkoročno pridobi, dolgoročno pa si odreže pot do bodočih seniorjev. Študenti računalništva zato gledajo v prihodnost z mešanico navdušenja in tesnobe. Učijo se poklica, ki je še pred nekaj leti veljal za varno vstopnico v dobro zaposlitev, zdaj pa tehnološki velikani razlagajo, koliko kode že ustvarijo njihovi modeli UI.

Osemdeset odstotkov česa?

Anthropic pravi, da 80 odstotkov programske kode za njihov model Claude napiše … Claude. Številke zvenijo osupljivo, vendar zahtevajo previdnost; vrstica kode ni enota vrednosti in samodejno ustvarjena sprememba ni nujno samostojno opravljeno delo. Če model napiše 80 odstotkov znakov, človek pa določi arhitekturo, izbere problem, zavrne tri slabe poskuse, preveri varnost in prevzame odgovornost, kdo je v resnici izdelal program? Tudi razmerje med tipkanjem in razmišljanjem je bilo v dobrem programiranju vedno nagnjeno k razmišljanju.

Modeli živijo od vodnjaka, ki ga njihova lastna uspešnost hkrati pomaga prazniti.

Umetna inteligenca lahko prevzame velik del tipkanja, ne da bi zato prevzela enak del razumevanja.

Več »ustvarjene« kode pomeni več kode za »pregledovanje« in »vzdrževanje«, navidezni prihranek pa se lahko preseli v odpravljanje napak, varnostne preglede ali poznejše prepisovanje. Nekatere ekipe z modeli res naredijo bistveno več, druge dobijo le več samozavestno napisanega tehničnega dolga. Umetna inteligenca je ojačevalnik: discipliniranemu razvijalcu poveča doseg, neizkušenemu uporabniku pa omogoči, da hitreje zgradi nekaj, česar ne zna presoditi.

Poceni, dokler ne postane drago

In nato je tu še denar. Programiranje po občutku se zdi skoraj brezplačno, ker je skrito v mesečni naročnini, toda resnejše delo porabi veliko računske moči. Model mora znova in znova brati projekt, preiskovati datoteke, poganjati orodja in popravljati poskuse. Ponudniki zato najzmogljivejše modele in daljše naloge vse pogosteje ločujejo od poceni paketov. Sedanja radodarnost je tudi boj za uporabnike; ni zagotovilo, da bo osebna programska tovarna za 20 evrov na mesec trajala večno. Anthropicov najmočnejši model Fable 5 že ni več na voljo v osnovnem naročniškem paketu.

Kdo bo razumel odgovor?

Programiranje po občutku je torej hkrati demokratizacija in davek na prihodnost, praktično orodje in nevarna bližnjica. Omogoča rešitve, ki jih drugače ne bi bilo, vendar zamegli mejo med izdelati in razumeti. Najpomembnejše vprašanje zato ni, ali bodo modeli znali programirati. Očitno je, da že znajo in da bodo jutri boljši. Vprašanje je, kaj bomo ob njih morali znati mi. Za osebni pripomoček, ki bo enkrat preuredil fotografije, je dovolj, da rezultat preverimo in ga po uporabi odložimo. Za program, ki odloča o denarju, zdravju ali zasebnosti, mora nekdo razumeti več kot le želeni občutek. Med tema skrajnostma se bo na novo določalo, kdo je programer, koliko je njegovo delo vredno in kdaj je programska oprema res dokončana.

Danes je mogoče program ustvariti, ne da bi znali programirati. To je večja sprememba, kot se zdi, in manjša, kot jo oglašujejo. Računalniku moramo še vedno povedati, kaj hočemo, ugotoviti, ali smo to res dobili, ter živeti s posledicami. Le da mu tega ne razlagamo več v njegovem jeziku. Zdaj se on trudi razumeti našega.

Vse manj verjamem, da se česa ne da

Matjaž Klančar

Najprej opozorilo: o modernem programiranju nimam pojma. Nekoč sem sicer programiral v Basicu (nekje pri Sinclair ZX81), nadaljeval s Turbo Pascalom in končal pri Clipperju. V njem sem celo napisal preprosto poslovno aplikacijo in zanjo dobil denar (!). Toda od takrat je minilo toliko časa, da se danes ne bi upal imenovati programer. Kvečjemu nekdo, ki približno ve, kaj je spremenljivka, in se še spomni, da je bilo treba računalniku nekoč vse zelo natančno razložiti. Potem sem slišal za vibe coding. Izraz se mi je zdel dovolj neumen, da me je začel zanimati. Za prvi poskus sem si izbral problem, ki nas pri Monitorju že dolgo mori. Končni PDF revije bi radi razbili nazaj na posamezne članke s slikami, primerne za množični samodejni uvoz na spletno stran. Na papirju se to sliši preprosto. V resnici pa so v PDF-jih okvirčki, podnaslovi, mednaslovi, podpisi k fotografijam, slike v okvirjih, stolpci in najrazličnejše posebnosti preloma. Naši hišni, sicer zunanji programerji so nekoč ocenili, da se tega enostavno ne da narediti. Pa se da.

Po nekaj urah pogovora s Claudom je nastal spletni program (teče v Dockerju), v katerega naložim PDF revije, čez malo več kot minuto (!) pa dobim posamezne članke v datotekah DOCX in pripadajoče fotografije. Dokumente pregledam, po potrebi kaj ročno popravim, nato pa jih znova naložim v isti program. Ta jih pretvori v HTML, in to s točno takimi razredi, kot jih pričakuje naša spletna stran. Sledi uvoz in delo je opravljeno. To ni le tehnološka demonstracija, vsak mesec nam prihrani približno štiri ure ročnega in duhamornega dela! Prav ta prihranek me je spomnil na drugo opravilo, ki mi vsak mesec vzame dve uri: obračun honorarjev Monitorjevih sodelavcev. Dosedanji postopek je bil lep primer digitalizacije po slovensko. Wordov makro je preštel znake v množici dokumentov, nato so sledili kopiranje podatkov v Excel, ročno urejanje imen avtorjev, popravljanje uteži in zneskov, izdelava vrtilne tabele s skupnimi vsotami ter na koncu še programček, ki je prebral Excelovo datoteko in avtorjem razposlal elektronska sporočila.

Vsi vemo, da se cene letov pri Ryanairju spreminjajo. Zdaj bom vedel točno, kdaj in za koliko.

Zdaj vse dokumente DOCX naložim v nov spletni program (spet v Dockerju). Dodam še PDF Monitorja, ker nekateri avtorji svojih člankov v dokumentih pač ne podpišejo, program pa iz revije ugotovi, kdo je kdo. Nato izdela tabelo XLS, ki jo pregledam in po potrebi popravim, naložim jo nazaj, program pa nato le še prek aplikacije v okolju Microsoft 365 razpošlje obvestila avtorjem. Hvala, Claude.

Ta dva poletna projekta sta me dovolj opogumila, da sem začel preizkušati še bolj nenavadne zamisli. Nastal je program, ki obiskuje Ryanairjevo spletno stran in mi vsak dan izrisuje gibanje cen vozovnic za dva leta, ki me zanimata, skupaj s ceno prtljage.

Testno WordPress okolje za preizkušanje oblikovalskih idej.

Še več, po novem imam za to tudi telefonsko aplikacijo za Android. Ker…, zakaj pa ne.

Nastala je tudi kopija spletne strani Monitor. si, ki teče v WordPressu in omogoča izbiro med tremi različnimi oblikovnimi podobami. Pri tem projektu je ChatGPT naredil praktično vse. Dobil je dostop SSH do vsebnika z Dockerjem, sam namestil WordPress, ga napolnil z dvema letnikoma člankov in novic z Monitorjeve strani (te vsako jutro dopolnjuje z novimi) ter pripravil tri oblikovne rešitve. Navodila niso bila oblikovalski elaborati na 20 straneh. Zadostovalo je nekaj takega kot, »naj bo podobno spletni strani X«, poznejše spremembe pa sem narekoval z običajnimi stavki kot »zgoraj desno dodaj okvirček Najbolj brano in ga barvno uskladi s preostalo stranjo«. Namen ni, da bi umetna inteligenca čez noč zamenjala našo pravo spletno stran; gre za igrišče, na katerem lahko hitro preizkušamo zamisli, primerjamo rešitve in ugotovimo, kaj nam je všeč. Ko bo smer dovolj dobra, jo bo mogoče predati v produkcijo in po njej prenoviti resnično stran.

Najpomembnejše spoznanje teh ‚vajbkodanih‘ poskusov ni, da zna umetna inteligenca napisati program. To sem vedel že prej. Presenetilo me je, kako hitro se je premaknila meja med zamislijo in delujočim izdelkom. Še vsaka ideja, ki se mi je na začetku zdela preveč divja in ob kateri sem pomislil, »tega pa že ne bo zmogel«, je na koncu zaživela.

Seveda rezultat ni vedno (takoj) popoln. Treba je preverjati, popravljati, razmišljati in včasih začeti znova. Toda za človeka, ki zna opisati problem, pozna svoj delovni proces in je dovolj trmast, da vztraja, je danes na voljo nekaj povsem novega: možnost, da si sam izdela orodje, ki ga potrebuje. Ne čez leto dni, po pripravi specifikacij, sestankih in ponudbah, ampak v nekaj urah.

Trenutno se ukvarjam z novimi, še bolj ambicioznimi idejami. Nekaterih si skoraj ne upam izreči na glas, ker zvenijo preveč zapleteno ali preprosto nemogoče. Toda po letošnjem poletju vse manj verjamem lastnemu občutku za to, česa se »ne da« narediti. Kaže namreč, da bosta mojstra Claude in Chat marsikaj od tega vseeno zmogla.

Aplikacija v popoldnevu

Primož Gabrijelčič

Pri hobijih je pa drugače. Občasno potrebujem kakšno manjše orodje in tipično je hitreje, če mi ga napiše Claude, kot če bi se s tem ukvarjal sam. V zadnjem letu mi je napisal nekaj skriptov za pobiranje knjig s spletnih strani, pa kodo za mikroprocesor, ki krmili osvetljavo v kuhinjski niši, in še kaj. Najbolj pa sem si zapomnil Claudovo sodelovanje pri dveh srednje velikih projektih, kjer sem sodeloval samo kot uporabnik.

Prvi projekt je orodje za samodejno »voronoizacijo« 3D-modelov. 3D-tisk je eden od mojih hobijev in v nekem trenutku sem hotel obstoječi 3D-model izvotliti in v steno dodati luknje. (Pobrskajte za »voronoi STL«, pa vam bo hitro jasno.) Spletna orodja za to početje so počasna, okorna in občasno nedelujoča, pa sem vprašal Claude, če zna kaj takega sprogramirati.

Pripravil je načrt, naredil Python program in izdelal orodje, ki reši problem v ukazni vrstici.

No, vsaj v teoriji. Izkaže se, da je popravljanje napak zelo počasno, če je na eni strani uporabnik, ki ne razume matematike, uporabljene za reševanje problema, na drugi strani pa program, ki ne more vizualno analizirati rezultatov in mu je treba vsak problem natančno opisati. (Pa še potem pogosto zaide v napačno smer). Pa še moje zanimanje za ta problem je malce usahnilo. Vseeno pa si lahko trenutno različico ogledate na github.com/gabr42/voronoizer.

Druga aplikacija je zanimivejša za širše množice. Pred slabim letom je Ankur Gupta napisal Python skript, ki za poljubno lokacijo na zemlji izdela stiliziran poster (github.com/originalankur/maptoposter). Nekaj mesecev kasneje se je na GitHubu pojavil grafični vmesnik okoli tega skripta.

Medtem je tudi že izginil s tega sveta, na srečo pa sem že predtem naredil svojo kopijo v github.com/gabr42/maptoposterwebapp

Tudi pri tem projektu sem bil samo uporabnik. Claudu sem opisal svoje želje in v popoldnevu mi je v konzolno aplikacijo dodal podporo za risanje morij, mokrišč, zgodovinsko pomembnih stavb in sakralnih objektov, v grafični vmesnik pa elemente UI za upravljanje novih funkcij. Spet je šlo za nekaj, kar bi sam brez težav naredil, a bi za to porabil en teden, ne samo popoldneva. Raziskati bi moral, kako konzolna aplikacije vleče podatke s spletišča OpenStreetMap, najti, kako so ti predstavljeni v podatkovni zbirki OSM, pa ugotoviti, kako integrirati risanje v obstoječi sistem. Potem bi se pa moral ubadati še z grafičnim vmesnikom, napisanim v Pythonu, o čemer tudi ne vem popolnoma nič.

Kar se mene tiče, je sedanje stanje programerskih orodij LLM že dovolj dobro, da jim lahko prepustimo izdelavo enostavnih in srednje zapletenih aplikacij. Priporočam pa, da izdelek vseeno najprej testirate, preden ga začnete uporabljati.

Računalnik je spet zabaven!

David Vidmar

Moji začetki so bili skromni: nekaj vrstic kode, kakšna preprosta skripta. Uporabljal sem Claude Code, ki je konec lanskega leta sprožil revolucijo sodobnega razvoja programja.

Ko so mi prvi uspehi vlili več samozavesti, sem si hitro zastavil ambicioznejši cilj. Prvi resnejši rezultat moje obnovljene sposobnosti razvijanja programskih rešitev je bila podpora enemu od hobijev: vodenju skupine dobrega ducata dolgoletnih navdušencev nad formulo 1. Skoraj desetletje že napovedujemo izide dirk, tekmujemo v natančnosti napovedi in se tudi v resničnem življenju radi usedemo za volan. Z UI sem razvil F1Chat Race Control, ki združuje Discord pomočnika in administrativni modul.

Popolnoma prilagojena programska podpora za hobi je z UI zlahka dosegljiva.

Pomočnik nas opozarja na roke za oddajo napovedi ter jih zbira in shranjuje v podatkovno zbirko, z administrativnim modulom pa pripravljam infografike napovedi, aktualne lestvice in nastavljam podrobnosti delovanja. Na trenutni izdelek sem zelo ponosen. Prihrani mi čas pri zamudnih in dolgočasnih opravilih, zato ga lahko več namenim bistvu našega druženja: klepetu in skupnim vožnjam. Rešitev se je medtem že precej oddaljila od prvotne zamisli. Z velikimi jezikovnimi modeli in s programerskimi agenti lahko vsakih nekaj tednov v nekaj minutah ter brez večjih skrbi temeljito preuredim kodo, zamenjam tehnološko osnovo in s samodejnimi testi preverim, da vse, kar je delovalo prej, deluje še naprej. Če se pojavi napaka, jo odpravim podobno, kot je nastala: ob pomoči UI. Novih idej pa ne zmanjka. Čeprav sem na začetku izbral tehnologijo, ki jo dobro poznam in razumem, generirane kode že nekaj časa ne preverjam več z branjem. Sprva sem jo nameraval redno pregledovati, danes pa mi zadošča, da razumem delovanje rešitve in ga potrdim s testi.

Elektronska pošta in koledarji

Pred nekaj meseci je pravo eksplozijo navdušenja povzročil OpenClaw – pristop z neskončno zanko agenta UI, ki je od prve predstavitve že nekajkrat zamenjal ime. Osnovna ideja projekta je, da omogočimo agentu dostop do vsega: datotek, elektronske pošte, aplikacij ali celo kar celotnega računalnika, ta pa bo namesto nas prebiral pošto in splet, odgovarjal na pošto, kupoval, se vključeval v pogovore in podobno. Rešitev je razmeroma preprosta in so jo po inicialni popularnosti implementirali neštetokrat. A v resnici gre le za nekakšen čarovniški trik, ki se izkaže za počasnega, nevarnega in, jasno, dragega.

Kot alternativo takšni avtomatizaciji sem z nekaj pozivi sestavil DaveBot – skupek obdelav, ki vsakih nekaj minut preverja elektronsko pošto. Ko zazna novo sporočilo z računom za elektriko, komunalo ali podobno storitev, prenese priloge, jih preimenuje in shrani na določeno mesto. Avtomatika vzdržuje tudi družinski koledar: obdeluje vabila k frizerju, obvestila iz šole in druga podobna sporočila. DaveBot za svoje delovanje ne potrebuje in ne uporablja UI. Potrebuje le natančno napisana navodila v obliki programske kode: katera sporočila naj pregleda, katere podatke in datoteke naj izlušči ter kaj naj z njimi naredi. Popolnoma nič nenavadnega ali čarobnega: vse to se je dalo razviti že pred razmahom UI za domačo rabo – potrebnih je bilo le nadležno veliko kode in poskusov za relativno majhen prihranek časa.

UI pa potrebujem za nekaj drugega: ko želim rešitev nadgraditi, ji preprosto naročim, naj dopolni kodo. Že zdavnaj »sva« pripravila skripto, ki rešitev prevede, preveri in jo ob uspešnem testu namesti na strežnik. Tam koda, sestavljena iz množice stavkov if in regularnih izrazov, mirno opravlja svoje delo – brez porabe dragocenih »tokenov«. Avtomatiziral sem torej »le« dolgočasno, a nujno pregledovanje pošte – ne pa pisanja sporočil, puhlih objav za bloge ali družbena omrežja. Moj robotek prav tako ne odgovarja namesto mene na sporočila živih oseb. Ne zato, ker se tega ne bi dalo razviti, temveč, ker želim ta privilegij obdržati zase.

Pametna hiša hitreje in pametneje

Redni bralci Monitorja me utegnejo prepoznati kot dolgoletnega uporabnika in promotorja odprtokodne rešitve za upravljanje pametne hiše Home Assistant. Od nekdaj občudujem ta izdelek in se navdušujem, da lahko v nedogled nadgrajujem in izboljšujem upravljanje digitalnega dela hiše. Sprva smo uporabniki agenta UI učili uporabljati vmesnik API, kmalu pa so člani skupnosti razvili ha-mcp – izjemen strežnik Model Context Protocol, ki vmesnik API zavije v obliko, primernejšo za uporabo z UI. Rezultat je resnično zmogljiva možnost, da kar z agenti UI prilagajam najrazličnejše zmožnosti, ustvarjam nove nadzorne plošče in avtomatizacije. Pohitritev je res izjemna in jo zares toplo priporočam vsakomur, ki Home Assistant že uporablja, pa še bolj vsem tistim, ki se bojijo, da bodo imeli z nameščanjem in upravljanjem pametne hiše preveč (tehničnega) dela.

Javni podatki

Ko smo ob zadnjih volitvah kolektivno grizli nohte, katera stranka bo zbrala največ glasov, sem pomislil, da lahko v nekaj minutah razvijem bolj pregledno nadzorno ploščo od tistih, ki sta jih ponujala DVK in POP TV.

Upravljanje Home Assistant z UI deluje bolje, kot sem si predstavljal.

Ključ do rešitve je javni dostop do podatkov in zmožnost hitrega pisanja kode ob pomoči UI. Tako je nastala aplikacija Volitve, s katero smo doma spremljali najzanimivejša volišča in nam znane kandidate.

Človek bi pomislil, da so aplikacije za spremljanje vremenske napovedi že zdavnaj dosegle popolnost, a ni tako: večina aplikacij in prikazov ne uporablja napovedi lokalne agencije, lokalni izdelki pa so včasih nezadostni. Takšno je vsaj moje mnenje – zato sem z UI spisal svojo! Najprej je delovala v ukazni lupini. Brez posebnega razloga, le zato, ker tam pač preživim veliko časa. Nato mi je estetika tekstovne vremenske napovedi prirasla k srcu in sem jo prenesel še v spletno aplikacijo ter prilagodil za rabo na mobilnem telefonu. Na koncu je nastal celo strežnik MCP, s katerim se lahko o vremenski napovedi za Slovenijo in Hrvaško pogovarjam z agentom UI. Ob pisanju članka pa se sprašujem, zakaj še nisem dodal Italije in Avstrije! Moment, takoj bom nazaj …

Podobno kot za vreme lahko rečemo tudi za prometne podatke: dostopni so, a ne nujno v obliki, kakršno si želimo. To je posebej pomembno za jutranja romanja v službe in šole, zato sem na stenskem zaslonu domače hišne pameti, pozneje pa še na spletu zbral žive in zgodovinske podatke o pretočnosti prometa, ki jih ponuja Google Maps.

Katera orodja in opremo uporabljam

Če brez pomisleka potrebujem surovo moč sodobnega modela LLM, bom posegel po Claudu. Za klepet na spletu ali razvoj programske kode uporabim Claude Code. A če me kdo izzove, odgovor vedno dopolnim z mislijo, da je izbira orodja manj pomembna od tega, kako ga uporabljaš. Brez zadržkov v delo vprežem tudi Codex ali GitHub Copilot, orodje, ki mi je trenutno na voljo. Če imam dostop do lokalnega modela LLM, občasno uporabim še OpenCode. S pravilnim pristopom so si v resnici zelo podobni, vsi po vrsti pa zelo uporabni.

Vse te rešitve najbolje delujejo, ko ne tečejo v okolju Windows – za svoje delo uporabljajo orodja ukazne vrstice, kot so curl, wget, grep, jq in podobna, zelo pogosto morajo napisati kakšno skripto (bash) ali nekaj vrstic kode (Node.js, Python itd.). Večina omenjenih orodij je v Linuxu ali macOS privzeto na voljo, v Windows pač ne. Na pomoč priskoči Windows Subsystem for Linux (WSL).

Večino UI kljub WSL uporabljam v okoljih macOS in Linux. Če uporabljam grafično okolje, v obeh operacijskih sistemih uporabljam terminal Ghostty, največkrat tudi tmux.

Moji izdelki so dovolj kakovostni takrat, ko potrdim njihovo delovanje. Ker ne obdelujejo posebej zaupnih podatkov, ker moje občutljivejše rešitve niso povezane z internetom in ker sem njihov edini uporabnik, je za ročno pregledovanje kode zelo malo razlogov. Pomembnejšo kodo na hitro preverim sam, nato pa še navzkrižno z več agenti UI. Pri preverjanju kode velikokrat uporabim knjižnico Playwright.

Več razmisleka zahteva izbira modela. Opažam, da mnogi za vsako nalogo vzamejo največji, najdražji model – nekako tako, kot bi se z letalom peljal v bližnjo trgovino. Zagotavljam vam, da sta srednji model, na primer Anthropicov Sonnet ali OpenAI-jeva Terra, in srednja stopnja truda največkrat zelo dober kompromis med rezultatom in ceno. Le občasno si privoščim kakšen pregled kode ali gradnjo načrta z najmočnejšim modelom in (naj)višjo stopnjo truda. »Domači laboratorij« teče na treh fizičnih strežnikih – bolje rečeno odsluženih računalnikih. Domači NAS je računalnik, sestavljen iz dobesedno zavržene stare matične plošče, starega procesorja i5 in 16 GB RAM; na njem teče Unraid.

Hiter pregled pretočnosti cest.

Še bolj ponosen sem na to, da del domače infrastrukture poganjata dva skoraj 15 let stara računalnika Mac mini. Gostita množico kontejnerjev Docker s priročnimi odprtokodnimi orodji in z lastnimi kreacijami. Oba poganjata Ubuntu Server. Svojih strežnikov ne upravljam več sam, ampak mi pri tem pomaga UI. Največkrat tako, da mi pomaga razvijati dve skripti – eno za postavitev novega strežnika in eno, ki strežnik povsem posodobi.

Umetna inteligenca, ki je v končnem izdelku ni

Pozorno branje zgornjih odstavkov razkrije skrivnost ali – raje posebnost – opisanih domačih rešitev: vse so napisane z umetno inteligenco, vendar je pri svojem vsakodnevnem delovanju ne uporabljajo, zato me ne skrbijo stroški ali dostop do mojih podatkov. V debatah popolnih navdušencev nad UI ali popolnih skeptikov težko sodelujem. Tak način uporabe UI pač ni v skladu z zgodbami, ki jih beremo na LinkedInu ali X, niti s sanjskimi ali peklenskimi napovedmi o prihodnosti UI.

To ni članek o tem, da bi UI razmišljala namesto mene. Je zgodba o tem, da mi UI pomaga hitreje razvijati, vzpostavljati, popravljati, zavračati in znova graditi rešitve. Največja sprememba ni v tem, da zdaj pišem manj kode, ampak v tem, da jo lahko napišem več! Pri tem mi seveda pomaga, da precej dobro vem, kaj želim razviti in kako naj rešitev deluje.

Morda je to lahko tudi nasvet in primer, kako UI uporabljamo odgovorno in varno: kot pomoč pri razvoju rešitev, ki znajo nato zanesljivo delovati brez nje.

Nad pričakovanji!

Vladimir Djurdjič

Brez orodij s področja umetne inteligence se klona priljubljene storitve Feedly sploh ne bi lotil. V nekaj dneh sem ustvaril izboljšano različico, prilagojeno svojim potrebam.

Nastavil sem si dva konkretna izziva: razvoj celovitega klona (z izboljšavami) bralnika novic Feedly ter temeljito posodobitev upravljanja pametne hiše znotraj platforme Home Assistant. Oba projekta sta hitro razkrila tako blesteče prednosti kot skrite pasti tovrstnega razvoja.

Pri razvoju klona Feedly je UI zablestela pri oblikovanju vmesnika. Modeli se odlično obnesejo, če jim namesto opisov posredujem slike, barvne palete in sheme – preslikava vizualnih elementov v delujočo kodo je osupljiva. Izkazala se je tudi kot odličen tehnični pisec in samodejno generirala dokumentacijo, ki tako ni več breme, temveč naravni del projekta. Vseeno zgodba ni brez madeža zaradi potratnosti kode. Aplikacija je hitro postala obsežna, koda pa napihnjena in slabo optimizirana. Nujno je vpeljati proces zagotavljanja kakovosti: ko koncept deluje, mora slediti faza čiščenja, kjer se koda zreducira na produkcijski minimum, bodisi v oblaku ali okolju Docker.

Prebijanje skozi specifikacije in reševanje napak

Projekt Home Assistant je zahteval povsem drugačen pristop. Želel sem avtomatizirati domačo hišo s približno 50 elektronskimi napravami, kar je po klasični poti mukotrpno zaradi ogromno prebiranja pomanjkljive dokumentacije in preizkušanja.

V kratkem času mi je uspelo povezati upravljanje sončne elektrarne z zalogovnikom, toplotne črpalke, klimatske naprave, pametna stikala, vremenske senzorje, zalivalni sistem, celo podatke iz družinskega voznega parka. UI se je izkazala za ključnega zaveznika pri branju in interpretaciji zapletenih specifikacij, saj hitreje povezuje informacije in predlaga konfiguracijo, zna pa tudi prebirati izkušnje drugih z forumov.

Prav tako je neprecenljiva pri iskanju rešitev za hrošče – stroj hitro najde rešitev ali obvoz. Vendar orodja UI ne poznajo vedno vseh dejstev: model je večkrat iskal nesmiselne obvoze, npr. poskušal milijardokrat dostopati do datoteke, ker je napačno predpostavljal, da mu ne morem zagotoviti pravic.

V takih trenutkih je človeška iznajdljivost nenadomestljiva. Pri zapletenih zadevah pomaga funkcionalnost Computer Use, kjer stroj vizualno opazuje zaslon in sam opravi analizo – bistveno učinkoviteje kot posredno dokazovanje, »da imam prav«. Ker pa model tako dobi neposredni dostop do okolja, jo svetujem izključno znotraj izoliranih virtualnih računalnikov.

Upravljanje virov in končna kakovost

Interaktivno kodiranje prinaša izzive tudi pri iskanju informacij in porabi virov. Model se občasno preveč zanaša na splošna spletna iskanja in spregleda zadnje različice, zato je bolje, da vire preveri in eksplicitno vnese človek.

Največja praktična težava je ogromna poraba žetonov – tudi pri plačljivih storitvah hitro trčimo ob limite. Rekord: dnevno kvoto naročnine Claude Pro sem »pokuril« v manj kot 45 minutah. Nujno se je naučiti varčne rabe virov, npr. tako, da preproste naloge obdelujejo lokalni strežniki z modeli, kot so Qwen 3.6, Gemma 4 in Mistral.

Izjemno pomembno je tudi redno shranjevanje kontekstov sej – s tem ustvarjamo »varnostne kopije« na mejnikih, kamor se lahko vrnemo.

Integracije pametnih naprav so bile v preteklosti časovno potratno breme. Danes ob pomoči UI ideje zelo hitro spremenim v delujočo, robustno kodo.

Kakovost končnega izdelka je pogosto nad pričakovanji, pomanjkljivost pa je, da zmanjka kakšna malenkost, ki ni bila strogo izrecno zahtevana. Tu pomaga le vaja v natančnejšem podajanju navodil.

Delo v teku, rezultate še preverjamo

Tovrstno kodiranje predstavlja prelomnico v ustvarjanju tehnoloških izdelkov. Vloga razvijalca se premika k strateškemu vodenju, natančnemu izražanju zahtev in nadzoru kakovosti. Orodja omogočajo izjemno produktivnost, a le če razumemo njihove omejitve, redno razvijamo lastne spretnosti ter znamo uravnotežiti človeško intuicijo in strojno učinkovitost.

Vibe coding je še vedno mlada disciplina, resnične izkušnje z vzdrževanjem in s testiranjem se šele oblikujejo, stvari pa se spreminjajo praktično vsak teden – včerajšnja izkušnja jutri ni več povsem koristna. Marsikateri starejši IT-strokovnjak v tem vidi nov zagon, čeprav so vsi previdni glede tega, kaj to prinaša za vse nas.

Da znam programirati, sem odkril po naključju

Matic Zupančič

Perplexity, za katerega imel brezplačno letno naročnino Pro, sem problem predstavil dobesedno tako: »Potrebujem sistem za sledenje stikom (follow-upom). Kateri bi bil najbolj preprost? Moj proces je tak: 1. dan – prvi stik; 3. dan – follow-up; 5. dan – follow-up; 7. dan – follow-up […]. Orodja, ki jih imam na voljo: Microsoft 365 Business Premium, Kanban board (open source rešitev Kanboard). Idealen rezultat bi bila rešitev, v katero lahko vnesem ime potencialne stranke, funkcijo, podjetje, e-poštni naslov in datum prvega kontakta, nato pa vsak dan dobim opomnik, koga moram kontaktirati in v kateri fazi (dan follow-upa) je posamezna potencialna stranka.«

Želel sem si v bistvu izvedeti, kako drugi delajo outreach in follow-up na LinkedInu.

Ko mi eksplodira glava

Rezultat? Pričakoval sem nekaj nasvetov, morda link do kakšnega CRM-sistema, a dejansko me je Perplexity pustil s povešeno čeljustjo in z viharjem v glavi. Napisal mi je enostavno aplikacijo, pa ga sploh nisem prosil za to. Počutil sem se kot otrok, ki se mu je odprlo vesolje, ko je ugotovil, da zna brati in da je knjižnica za vogalom.

Po približno dveh urah pogovarjanja s Perplexityjem sem imel končni produkt – spletno aplikacijo, ki je živela v dveh datotekah: v eni sta bili vsa logika in oblika (HTML5 in CSS), v drugi (JSON) pa vse potrebne podatke.

Oboje odloženo v moj OneDrive in zaznamek v brskalniku – to je moja prva 'vajbkodana' aplikacija.

Zdaj pa zares

Vedno sem zavidal svojemu pokojnemu prijatelju, s katerim sva sodelovala pri mnogih marketinških projektih. Ko je potreboval kakšno orodje, si ga je preprosto sprogramiral.

Za svoje potrebe in za nekatere znance je že pred leti v pogon spravil preprosto rešitev, ki je bila uporabna za ponudnike storitev, denimo terapevte, programerje in podobno.

Šlo je za neke vrste katalog storitev z obrazcem za oddajo naročila, v zaledju pa še nekaj statistike, možnost kreiranja sledilnih linkov, pa izdelava QR-kode za hitro plačilo ter integracija s PayPalom in Čebelca.biz za izdajo računov.

Aplikacija že več kot leto sameva na strežniku, tehnologija okrog se spreminja in s tem počasi odpovedujejo nekatere funkcije. Moja žena pa jo dnevno uporablja za svojo terapevtsko dejavnost, zato sem bil prisiljen iskati alternativo.

Opogumljen od nedavno odkritega talenta programiranja, sem, kajpada, pomislil, da bi jo kar sam sprogramiral. Pa sem se lotil.

Claude Code z naročnino

Nič več Perplexity, pravi programerji uporabljajo Claude Code, naročnino sem že imel. Tokrat sem si vzel kar dobro uro, da sem prvi prompt sestavil, kot je treba. Opis tehnoloških zahtev (PHP, MariaDB), opis front-enda, opis zaledja, logika naročanja, opis integracij ipd. Na roko mi je šlo dejstvo, da je Anthropic v okviru naročnine za krajše časovno obdobje ponudil tudi najnovejši model Fable5. Prva različica je bila nad vsemi pričakovanji. Z grafičnega vidika morda nič posebnega, ampak osnovna logika je delovala. Aplikacijo mi je Code odvrgel v GitHub, zraven pa naredil še navodilo, kako jo namestim v svoje spletno gostovanje. Vse, kar sem moral priskrbeti, so bili podatki o uporabniku za MariaDB zbirko ter uporabniško ime in geslo za admin uporabnika.

Vsa izkušnja z vibe codingom me vedno bolj utrjuje v prepričanju, da je za učinkovito uporabo UI, ne samo pri programiranju, pomembno dobro poznati vsebino. Ukaz »Naredi mi aplikacijo za naročilo storitev« bo dal boren rezultat. Primer: ko enkrat veš, da se v Sloveniji uporablja modificiran standard za kreiranje plačilnih QR-kod, in to omeniš izbranemu LLM, bo sam poiskal ustrezne informacij za pravilno implementacijo. Vsaj v mojem primeru je bilo tako.

Integracije in iskanje rešitve

Zanimiv zaplet, če temu sploh lahko tako rečem, sem imel z integracijo svoje aplikacije in Čebelce, storitve za izdajanje računov. V prvi različici integracija ni delovala, kajti na slepo sem poskusil le s splošnim navodilom v smislu: »Ko potrdim naročilo kot imported, se sproži integracija API s Čebelca.biz in izdela se osnutek računa.« Jasno, kot bi prišel k zidarju in mu naročil, da naj mi naredi bivališče.

Moj cilj je bil, da je aplikacija približno gotova v enem popoldnevu. Vedel sem, da je treba za popolno dokumentacijo API prositi avtorja Čebelce. Kar pa mi ni ustrezalo, ker je bila tovrstna komunikacija zunaj mojih časovnih gabaritov. Potreboval sem torej bližnjico.

Dobil sem preblisk: nekje na GitHubu sem nekoč že videl, da obstaja modul za integracijo WooCommercea in Čebelce. Pa sem poskusil. Fable5 je dobil od mene navodilo, naj iz WooCommerce integracije izlušči, kar potrebuje.

Dobesedni del prompta: »Integracija s Čebelca.biz ne dela. Na podlagi vtičnika za WooCommerce poglej, kaj je potrebno, da zadostiš pogojem za izdelavo drafta računa za storitve. GitHub vtičnika je na https://github.com/Invoice-Fox/CebelcaBIZ-WooCommerce/.« Par minut kasneje je bila integracija s Čebelco gotova in testirana, da deluje pravilno. Medtem ko sem čakal, da Claude napiše kodo, sem dobival še druge ideje: »Kaj, če bi naredil še integracijo s sistemom Flik in integracijo z Exchange Online za pošiljanje pošte o naročilu? Pa če smo že pri tem, še SMTP2GO in poljubni strežnik SMTP, pa …« Ni bilo konca.

Kaj pa zdaj?

Če strnem to moje programiranje še v časovne okvire: pisanje promptov – tri ure; generiranje kode: približno 1,5 ure; testiranje rešitve: šest ur. Strošek? Če odmislim naročnino na Claude, sem v zadnji iteraciji porabil približno osem evrov za uporabo modela Fable5, ki se po novem plačuje po porabi.

Aplikacija je narejena in preizkušeno deluje. Ni pa še v produkciji. Zakaj? Ker me je enostavno strah, da se morda v tisti kodi ne skriva kaj 'čudnega'. Sem namreč pravi 'vajbkoder' in ne znam brati programske kode. Žena me pa čaka in ne bo druge, kot da ji aplikacijo namestim.

Leta 1999 v filmu, danes doma

Matej Huš

Meta 1999 sem si v enem zgodnjih razredov osnovne šole med počitnicami približno dvajsetkrat ogledal film Y2K o apokalipsi, ki je ob prelomu tisočletja zaradi ponorelih računalnikov pogoltnila svet. Posebna ameriška skupina strokovnjakov je imela v štabu veliko projekcijo zemljevida, čez katerega je zlovešče lezla črta kot datumska meja med tisočletjema. Film je menda objektivno slab – na IMDb ima oceno 3,4 –, meni pa se ni zdel tak. Zlasti projekcija me je navdušila; piflarje pač prepoznate zgodaj. Še isto poletje sem jo poskusil poustvariti v Visual Basicu, kolikor se je dalo, potem pa je za ta objektivno neuporaben, a zame zanimiv projekt zmanjkalo časa. Do letošnjega poletja. Četrt stoletja pozneje imamo umetno inteligenco, zato sem se odločil, da projekcijo vendarle dokončam.

Kodo sem ustvaril s Chatom, končni izdelek dal v pregled Claudu, njegove različice pa je nato pregledal še Gemini.

Uporabil sem brezplačni Claude z modelom Sonnet 5. Ker se mi ni mudilo, sta bili dve dnevni iteraciji ali tri za postranski hobi povsem dovolj.

Claudu sem v preprosti angleščini opisal, kaj bi rad. Po treh iteracijah je razumel bistvo, sproti pa postavljal smiselna podvprašanja. Tehnično izvedbo, vključno z izbiro jezika in platforme, sem prepustil njemu. Predlagal je JavaScript, CSS in HTML5, vse skupaj pa se izvaja lokalno v brskalniku. Za podatke o časovnih pasovih in državnih mejah je uporabil prosto dostopne datoteke JSON. Ker kode nisem prepričal, da bi eno od njih sama naložila s spleta, jo je treba ob zagonu ročno povleči v stran. Tako amaterski projekt, Britanci bi rekli bodge, je to bil, da sem rešitev sprejel.

Da zna Claude pisati kodo, me ni presenetilo. Bolj me je domiselnost, s katero je predlagal dodatne funkcije: centriranje zemljevida na datumsko mejo ali polnoč, izbiro poljubnega časa, pospešeno simulacijo, barvno označevanje oddaljenosti od polnoči, prikaz časa do naslednje polnoči, datumsko mejo in izpis datuma. Večino sva nato tudi dodala.

Večjih očitnih napak ni bilo, ob opozorilu pa je hrošče večinoma pravilno prepoznal in odpravil. Enkrat se stran ni osveževala, drugič je zemljevid izginil. Bi si 65 kilobajtov kode upal brez pregleda uporabiti v produkciji? Nikakor ne. ChatGPT Pro je v njej našel slabo sanitizacijo vhodnih datotek, neuporabljeno in podvojeno kodo, nekaj nedefiniranih funkcij ter druge nedoslednosti. Za moje skromne potrebe pa izdelek deluje dovolj dobro. To je tudi bistvena razlika med domačim eksperimentom in programsko opremo, od katere so odvisni drugi ljudje.

V službi več uporabljam ChatGPT in Codex. Pretehtalo je predvsem to, da imamo paket Plus s fiksno naročnino, medtem ko Anthropic po novem obračunava porabljene žetone. Največ časa mi prihranita pri banalnih skriptah, ki jih ni težko napisati na roko, a jih je hitreje prepustiti komu drugemu: sprehajanje po mapah, ustvarjanje in kopiranje datotek, poganjanje izračunov na superračunalniku ter priprava več tisoč skoraj enakih vhodnih datotek. Za preprosta opravila mi ChatGPT piše skripte v Bashu, za zahtevnejšo pripravo podatkov pa v Pythonu.

Kompleksnejša naloga je bila priprava specializirane kode in vhodnih datotek za modeliranje nanodelcev različnih oblik in velikosti. Ustvaril sem lasten GPT ter vanj naložil dvestostranski priročnik, celotno odprto kodo programa, nekaj svojih primerov in članke, v katerih sem programsko opremo že uporabljal. V manj kot uri je nastal zelo uporaben specialist, ki je poznal dokumentacijo, razumel moje prejšnje primere in znal reševati tudi zapletene naloge. Kodo, ki bi jo sam po oceni pisal teden dni, sem dobil v enem dopoldnevu pogovora.

Končni izdelek sem nato dal v pregled Claudu, ki je našel nekaj površnosti in šibkih točk. Te niso vplivale na rezultate, je bila pa koda zaradi njih manj elegantna in robustna. Več različic kode, za vsako obliko nanodelcev svojo, je nato pregledal še Gemini. Naloga je bila preprosta: Ugotovi, kaj koda počne, in napiši dokumentacijo. Ker mu je oboje uspelo brez težav, sem bil precej bolj prepričan, da je pravilna. Po dodatnem preizkusu na ročno pripravljenih podatkih je šla v produkcijo.

Se mi vibe coding še vedno zdi goljufanje? Ne več. Doma mi omogoča igro, podobno kot je CAD omogočil ustvarjanje brez znanja tehničnega risanja. V službi pa sem zaradi njega produktivnejši, saj moje glavno delo ni pisanje kode, temveč uporaba specialnega znanja. Koda je zgolj mehanično orodje, s katerim to znanje spremenim v rezultat.

Programerski pomočnik za »domači laboratorij«

Peter Šepetavc

Umetni inteligenci sicer pri razumskem sklepanju pogosto zmanjka kakšen kolešček ali dva, da bi bili rezultati zares inteligentni, moram pa priznati, da ji gre pri pisanju kode, še posebej, če se z njo primerjam sam, precej bolje. Moj izziv: svojo solato e-knjig iz različnih virov želim umestiti v kategorije, urediti opise in jih zložiti v urejeno virtualno knjižnico. Ker pa je Calibre zbirka knjig dokaj samosvoja digitalna žival, sem si najprej zadal manjši izziv: Claude mi je spisal spletno aplikacijo Readeck Autotagger, s katero urejam in čistim svojo shranjeno zbirko člankov v Readecku. Claude se je problema lotil brez podrobnejših navodil: zaželel sem si spletno aplikacijo, po možnosti ne preobsežne, ki bi periodično pregledala mojo zbirko shranjenih člankov v Readecku in novim člankom pripela prave oznake, s katerimi bo filtriranje po tematiki enostavnejše.

Njegova prva naloga je bila, da na podlagi obstoječih člankov naredi primerno razdelitev po tematikah, saj lahko na podlagi dva tisoč shranjenih člankov oceni, katere oznake bi bile najprimernejše tudi v prihodnje. Zaželel sem si še poseben filter za članke v slovenščini in seveda tudi možnost, da v prihodnje v aplikaciji dodajam nove oznake, če se izkaže, da kakšen vsebinski sklop manjka.

V naslednjem koraku je spisal Docker aplikacijo, ki sem jo namestil, pognal, označil skoraj dva tisoč člankov z najmanj eno oznako in največ tremi ter porabil za približno evro klicev API na Anthropic – sicer trivialen znesek, ampak z oznakami ne jaz ne Claude nisva bila zadovoljna. Naslednjih 20 iteracij aplikacije sva zato pilila pravila, katera oznaka sodi na kateri tip članka. Ko je že tretjič ali četrtič porabil evro za učenje samega sebe, sva naredila še en vmesni korak: na svoj računalnik sem namestil okolje Ollama, mu dal dostop do grafične kartice, aplikacijo pa prilagodil, da uporablja lokalni LLM, v mojem primeru Qwen3:14b, ki je, kot mi je povedal kar Claude, zelo primeren za izzive, kot je kategorizacija. Glede na to, da je bil to moj prvi večji kodirni izziv LLM (prej sem umetno inteligenco uporabljal predvsem za krajše skripte in kakšne popravke), sem se naučil naslednje: Claude zelo rad dodaja funkcionalnosti, zmožnosti, dodatna okenca v uporabniškem vmesniku, nerad pa »pospravlja« za sabo – z optimizacijo se je ukvarjal šele, ko sem mu to izrecno zapovedal, zanimivo pa je tudi to, da za ta korak potrebuje precej bolj podrobna navodila kot za »razmislek«, kaj bi v aplikacijo še dodal.

In vendar – Readeck Autotagger je v svoji 72. (!) iteraciji dovolj dober, da se mi z njim ni treba več ukvarjati: zažene se samodejno, oznake so v več kot 90 odstotkih primerov prave, ostalo pa uredim ročno enkrat tedensko, kar mi vzame kakšno minuto – vse to kar v aplikaciji. Dodal sem še nekaj manjših orodij in zmožnosti, ki v Readecku manjkajo (npr. iskanje podvojenih člankov), odpraviti pa moram še kakšnega hrošča ali dva – najočitnejši je ta, da včasih kakšnemu članku ne pripiše vseh oznak.

Opremljen z zmago nad oznakami v Readecku sem se lotil še aplikacije za urejanje knjižne zbirke v aplikaciji Calibre. V osnovi je izziv enak: Analiziraj shranjeno knjigo, iz nabora oznak izberi prave, zapiši jih v zbirko. V praksi je problem precej večji: Calibre namreč nima API-ja, s katerim bi enostavno urejal podatke v podatkovni zbirki, poleg tega pa je kategorizacija knjig precej bolj kompleksen problem od pripenjanja oznak člankom. Izziva sem se najprej lotil v Claudu, ampak sem se prevečkrat, kljub plačani naročnini, zaletel v peturni počitek zaradi pretirane uporabe, zato sem se prestavil v ChatGPT. Calibre aplikacija je trenutno še v povojih, vseeno pa jo omenjam zaradi primerjave med Claudom in ChatGPT: Claude je precej boljši pomočnik pri snovanju aplikacij, te pa so tudi lepše (čeprav je zaradi poplave enakih aplikacij na spletu njegov oblikovalski pristop že malo preveč vseprisoten). Po drugi strani se ChatGPT bolje obnese pri popravkih, ponovitvah in piljenju. Potrebuje pa precej bolj natančna navodila pri snovanju in razvoju novih zmožnosti in tudi oblikovno se ne potrudi najbolj. Je tovrstni razvoj aplikacij za homelab smiseln? Samo za okolja, ki so za požarnim zidom. Svojih umotvorov ne želim deliti s svetom, ker gre verjetno za dokaj slabo spisane aplikacije, ki obenem rešujejo zame specifičen problem. Ampak ali bi pred kakšnim letom sploh lahko spisal tovrstno aplikacijo? S svojim (ne)znanjem programiranja zagotovo ne.

Moj švicarski nož

Matjaž Gerčar

IT sem že skoraj 30 let Vin ves ta čas spremljam razvoj izdelave aplikacij, vendar me samo kodiranje nikoli ni zares veselilo – prej dolgočasilo. Pred 15 leti me je prav to ustavljalo, da bi ustvaril svojo aplikacijo. Manjkalo mi je izkušenj, zato pod mojimi prsti ni nastalo nič več kot preprosta spletna aplikacija oziroma, bolje rečeno, spletna stran.

Kodiranje me še vedno dolgočasi, vendar mi to danes ne preprečuje več, da bi ustvarjal aplikacije, ki mi olajšajo življenje. Začelo se je z YouTube »downloaderjem«. YouTube omogoča prenos nekaterih posnetkov na računalnik, zato sem ženino prošnjo, naj ji na USB-ključek za poslušanje v avtu prenesem pet posnetkov, brez težav uredil ročno. Ko pa je nekega dne prišla s seznamom 50 pesmi, bi to pomenilo odpiranje 50 posnetkov v brskalniku in klikanje gumba Download pri vsakem posebej. Ker se je ravno takrat že dobro uveljavil ChatGPT, sem ga prosil, naj mi napiše Python skripto, ki iz datoteke prebere povezave do YouTubovih posnetkov in jih prenese.

V nekaj minutah sem imel prvo različico, po eni popravljalni iteraciji pa je skripta že delovala: 50 posnetkov v obliki MP3 na USB-ključku. Žena je bila zadovoljna, jaz pa še bolj, saj mi je vse skupaj vzelo največ 15 minut namesto dveh ali treh večerov programiranja — ali, še huje, ročnega prenašanja datotek. Kmalu sem začel uporabljati Claude. Poleg programiranja je znal ustvarjati datoteke, brati že napisano kodo in nadgrajevati obstoječe rešitve. Pomembno je tudi, da se ne strinja z vsem samodejno, kot to pogosto počne ChatGPT, ki lahko uporabnika utrjuje v napačnih prepričanjih. Moj prvi »claudovski« vibe coding projekt je bilo sortiranje fotografij. Žena jih je vsak mesec shranjevala v svojo mapo, zato je bil arhiv lepo urejen po letih in mesecih. Tak red je odličen za arhiviranje, precej manj pa za iskanje določene fotografije deset let pozneje, ko ne veš niti leta, kaj šele meseca. Ročno pregledovanje fotografij in dodajanje oznak, kot so sončni zahod, narava, šport, poroka, ljudje ali morje, bi bilo mukotrpno, za računalnik pa je bila naloga preprosta. Želel sem še iskalnik po oznakah, pozneje pa tudi možnost kopiranja fotografij v izbrane mape po teh oznakah.

Zato sem zaposlil Claude in mu opisal, kaj potrebujem. Pisanje navodil mi je vzelo več časa, kot je Claude potreboval za izdelavo povsem delujoče aplikacije za macOS.

Delovala je že v prvem poskusu in nastala v pičlih 38 minutah. Kode nisem niti videl, čeprav mi je Claude sproti razlagal, kaj počne, zato sem ves čas vedel, kaj se dogaja, ne da bi se moral ukvarjati s kodiranjem. Med izdelavo je sam odpravljal tudi napake, ki jih je našel. To je natanko tisto, kar sem si vedno želel: da se lahko posvetim uporabnosti in funkcionalnosti, kodiranje pa prepustim svojemu programerju. Eno od »vibecodanih« orodij, ki ga pogosto uporabljam, mi pokaže, kaj na disku zaseda največ prostora. Podobnih programov je na trgu veliko, vendar brezplačne različice pogosto silijo v namestitev dodatne programske opreme. Za Windows obstaja odličen WinDirStat, a ga za macOS žal ni. Nekaj minut priprave dobrega navodila za Claude, še nekaj minut čakanja — in že imam program za macOS, ki počne natanko to, kar potrebujem. Brez odvečne krame in zapletov: pokaže mi, kaj zaseda prostor na disku.

Na podoben način si pripravljam številna mini orodja in avtomatizacije. Eno od njih je sortiranje velikega števila datotek, ki mi pride še posebej prav po koncu projekta, ko se nabere veliko dokumentacije v različnih različicah in mapa hitro postane nepregledna. Ob Claudovi pomoči hitro ustvarim orodje, ki v mapo vnese red: ob zaključku projekta samo zaženem Pythonovo skripto, računalnik pa datoteke sam pospravi in uredi. UI je zame postala švicarski nož za izdelavo lastnih orodij. Že zdaj pa vidim naslednji izziv: vseh teh orodij bo kmalu toliko, da jih bo treba tudi urediti. Verjamem, da bo Claude, če ga prosim, poskrbel še za to – da bom imel pregled nad njimi in predvsem hitro našel tista, ki sem jih že ustvaril.;)

Od zamisli do realizacije v dveh urah!

Simon Peter Vavpotič

Za domačo vremensko postajo potrebujemo merilni priključek in aplikacijo. Priključek za merjenje temperature, zračnega tlaka in relativne vlažnosti zraka izdelamo z miniaturno ploščico s tipalom BMP280 ali BME280. Na 40-polno razširitveno vtičnico jo prek vodila I2C povežemo s štirimi žicami in konektorjem, spajkanje je zato preprosto tudi za manj izkušene. Na Amazon.de so na voljo tudi razvojne ploščice s priloženim kablom, ki jih lahko povežemo brez spajkanja. Sam sem izdelal trajnejši priključek s konektorjem, pri katerem ob ponovnem priklopu ne moremo zamenjati nožic. Za ohišje sem uporabil plastično lupinico Kinder Surprisa, za povezavo z računalnikom pa star štirižilni telefonski kabel.

Projekt sem dolgo odlagal predvsem zaradi zahtevne izdelave všečne okenske aplikacije za Raspberry Pi OS. Nato jo je namesto mene napisal Googlov Gemini 3. Chromium v Linuxu oziroma Chrome v Windows in Androidu ima tipko AI mode, ki omogoča brezplačno uporabo modela Gemini 3. Ta zna iz opisa v naravnem jeziku ustvariti tudi aplikacijo, zato ni treba začeti s prazno datoteko in preučevanjem vseh programskih vmesnikov tipala.

V besedilno okno enostavno napišemo: »Napiši programsko aplikacijo v programskem jeziku C++ za Raspberry Pi 500 s tipalom BME280, ki prek 40-polne vtičnice deluje po vodilu I2C...« Opis mora biti natančen, saj Gemini 3 običajno izbere najlažjo pot. Zahtevati moramo normalizacijo zračnega tlaka na morsko gladino, sicer rezultata ne moremo primerjati z objavami meteoroloških agencij. Za pravilne meritve temperature in vlage mora program uporabiti tudi tovarniške kompenzacijske vrednosti, zapisane v tipalu. Če želimo okensko grafiko namesto terminala, določimo velikost okna, barve, pisave, znakovne nabore in druge podrobnosti; česar ne opredelimo, Gemini naključno izbere iz svojega nabora znanja. Dober poziv je zato pravzaprav tehnična specifikacija.

Če ne določimo arhitekture, Gemini 3 sam izbere eno datoteko ali preglednejšo rešitev z glavnim programom in s knjižnicami. Vendar osnovni AI mode v Chromiumu ni prilagojen prenosu obsežne izvorne kode – programska koda se nemalokrat prelije prek zanjo namenjenega besedilnega okvirja. Del lahko kopiramo z gumbom, preostanek pa označujemo ročno s Ctrl+C in Ctrl+V ali z miško. Nato kodo po navodilih Gemini 3 prevedemo v izvedljivo programsko kodo in jo preizkusimo. Poleg C++ sem preizkusil tudi generiranje aplikacij v Pythonu 3 (datoteke *.py). Te so navadno krajše in preglednejše, vendar moramo ustvariti navidezno okolje ter vanj namestiti potrebne knjižnice.

Primerjava izmerjenih in uradnih Arsovih vrednosti ter prikaz, kako se je nova vremenska postaja obnesla na dopustu.

Preizkušanje in popravljanje...

Preproste terminalske aplikacije navadno vsaj za silo delujejo že v prvem ali drugem poskusu, okenska grafika pa je po mojih izkušnjah za UI trši oreh, saj nemalokrat »pozabi« dodati programsko knjižnico ali programsko spremenljivko. Izkušen programer napako popravi sam, drugi pa lahko modelu opišejo težavo in zahtevajo novo različico kode. Gemini 3 uporablja konstruktivistični pristop: predlaga popravke, navodila za namestitev manjkajočih knjižnic in dodatne nastavitve operacijskega sistema.

Če prevajanje po več poskusih ne uspe, Gemini 3 poskusi s korenitejšimi spremembami. Predlaga lahko celo dopolnitev knjižnic, kar zahteva brskanje po njihovi strukturi in ročno ustvarjanje datotek.

Izdelava priključka za merjenje vremenskih parametrov in okenske aplikacije za Raspberry Pi OS Trixie.

Če tudi to ne pomaga, predlaga alternativno rešitev z zamenjavo ene knjižnice ali več in ustrezno spremembo kode.

… nato uspeh!

Kljub začetni skepsi in spominom na čase, ko sem se za uporabne aplikacije »boril« s človeškimi programerji, sem od Gemini 3 dobil delujočo vremensko aplikacijo z vsemi zahtevanimi funkcijami. Med njimi sta shranjevanje meritev vsakih 10 minut v datoteko *.log in grafični prikaz njihovega spreminjanja skozi čas. Sam pri tem nisem napisal niti ene vrstice programske kode, od zamisli do delujoče rešitve pa sem potreboval približno dve uri. Največ časa sta vzela preizkušanje in jasno opisovanje popravkov.

Beseda skeptika

Jurij Kristan

Kot desetletnega mulca me mentor še ni pustil samega k strojni žagi, zato sem sestavne dele iz vezane plošče dolbel na plebejski način, z ločno žično žago, medtem ko so starejši sošolci občasno uporabljali tudi stroje. Razlika v hitrosti je bila občutna: ko sem imel sam šele sestavljeno ogrodje, so nekateri že lakirali končni izdelek.

Takratni temeljni nauk, da ima strojna pomoč pri tehničnem podvigu sila otipljivo vlogo, se mi dostikrat vrača v misli ob dilemah izkoriščanja velikih jezikovnih modelov, po domače umetne inteligence. Gre za zmogljivo orodje, kajti občutni pospeški v nekaterih panogah so neizpodbitni: v zadnjih mesecih lahko spremljamo hitrejše posodabljanje programja, ki ga žene avtomatizirano iskanje hroščev in ranljivosti z agenti LLM. Žongliranje s programsko kodo je gotovo ena poglavitnih odlik takšnih algoritmov, če ne kar najmočnejša ta hip. Pomoč pri programiranju je bila prva reč, za kar sem sam uporabljal ChatGPT, in še danes je ena najpomembnejših.

Če poslušamo Daria Amodeija in druščino, nam bodo kmalu čisto vse sprogramirali agenti, mi jim bomo zgolj dajali opisna navodila. Kar je praksa, ki se je je malce posmehljivo prijelo ime vibe coding. Elon Musk si je po svoji stari navadi privoščil kar trditev, da programerjev v klasičnem smislu ne bomo več potrebovali. Ko prvič poprosimo bota, naj nam zgenerira preprosto aplikacijo, nakar jo prevedemo in – uau – celo normalno dela, je občutek res precej navdušujoč. A situacija je mnogo bolj niansirana, kot nas poskušajo prepričati zagovorniki takšnih izdelkov, ki imajo tu seveda primaknjen svoj lonček, zato je treba njihove besede vselej jemati z dosti rezerve. Med preprostim zgeneriranim program(čk)om in smiselno uporabo je vendarle precejšen razkorak.

Najprej se moramo vprašati, kaj je sploh naš bistveni cilj. To se pravi: ali se s programiranjem ukvarjamo ljubiteljsko ali profesionalno. Osredotočil se bom na prvi primer, ker je to moja polprofesionalna in ne poglavitna službena dejavnost. Lotevam se množice precej različnih projektov, od računalniške grafike in programiranja iger v C++ do, v zadnjem času, obdelave podatkov in avtomatizacije v orodjih CAD. Pri zadnjih dveh področjih prednjači Python, kjer sem še vedno precejšen amater, a je hkrati pisan na kožo LLM, ker ga od vseh jezikov še vedno tudi najbolje obvladajo. Toda kot nekdo, ki za seboj nima desetletja prakse na tem specifičnem področju, imam za cilj še vedno predvsem izgradnjo znanja in razumevanja, ne »štancanja« aplikacij do zapovedanega roka. Tu pa je LLM absolutno najkoristnejši kot pomočnik, ne izvajalec.

Če se želimo nečesa naučiti, moramo to napraviti sami, ne pa rešitve preplonkati od Chata, kar je motiv, ki je trenutno nasploh predmet žolčnih polemik v šolstvu. LLM lahko svetuje, kako kodo optimizirati, jo očisti žužkov ali ponudi rešitev, če se res zaplezamo. Vse ostalo je žaganje veje, na kateri sedimo, oziroma otročja potuha. Edini primer, ko bi se sam lotil vibe kodiranja, je oblikovanje aplikacije za stvar, ki me v splošnem ne zanima in sem prepričan, da se je nikoli v življenju ne bom več lotil, ampak bi jo pač v nekem trenutku nujno potreboval. A na kaj takšnega še nisem naletel. In v tem primeru bi moral bržkone tudi razcefrati svojo izkaznico »geekovskega« piflarja, ker se za našo kasto res ne spodobi, da nečesa ne spoznamo v nulo.;)

Ampak, ampak, porečete, štos je vendar v tem, da nam zaradi napredka agentov *nikoli* ne bo več treba znati kodirati, kar pomeni, da se tega sploh nima smisla učiti. Moj argument tako povsem pade v vodo, mar ne?? S takšno trditvijo so resne težave. Verjetno bomo v neki prihodnosti res videli takšne supersposobne programerske butlerje, ki bodo na ukaz ustvarili celotno aplikacijo, ki bo hkrati ustrezala zahtevam in zanesljiva (!), a zlepa še nismo tam. Če si izposodim uvodno anekdoto, danes programerski agent nima vloge mentorja, ki je vzel deščico in jo vešče obžagal na strojni napravi, temveč se obnaša kot neprespani vajenec, ki včasih odreže kakšen vogal preveč. Problema halucinacij še vedno nismo v celoti rešili in ni videti, da ga je pri današnjih arhitekturah jezikovnih modelov sploh mogoče.

Razvoj resničnih produktov ob pomoči umetne inteligence je zato zapleten iterativni proces, v katerem mora razvijalec presneto dobro poznati tako notranjo strukturo aplikacije, ki jo želi, kakor omejitve jezikovnega modela, ki ga uporablja. Z drugimi besedami: LLM ima vlogo človeškega pripravnika, ki sicer zna kaj skodirati, a ga je treba pri tem dobro usmerjati, saj sicer rad odjadra po svoje. Prav zato smo v panogi priče bistvenemu problemu, da umetna inteligenca zamenjuje ljudi na začetku karierne poti, kar dolgoročno grozi, da bo osiromašilo naše strokovno zaledje. Za učinkovito in zanesljivo vibe kodiranje je treba nekaj znati – in tega znanja se ne pridobi zgolj z vibe kodiranjem.