V prvem delu male šole programiranja po občutku smo se naučili razviti spletno aplikacijo. Ta zajema podatke, ki nas utegnejo zanimati. V tokratnem članku pa bomo naredili korak dlje in aplikacijo izboljšali z dodano podatkovno zbirko in s prijavo ter razmislili, kako jo razvijati in poganjati varno ter učinkovito.
Za učinkovit razvoj programske opreme sta v zgodnjih fazah projekta ključna izbira tehnologije in pristopov ter učinkovito preverjanje pravilnosti delovanja. Ob uporabi pa je zelo pomembno, kam boste svoj izdelek namestili in kako ga boste zavarovali pred neželenimi vpogledi in spremembami.
Čeprav pri manjših projektih bolj ali manj dobro deluje že naiven pristop, kjer v nekaj stavkih opišemo cilj, vse ostalo pa prepustimo agentu in VJM, to ni pot, ki jo je smiselno ubrati. Z bolj strukturiranim pristopom bo rezultat precej boljši in, kar je še pomembnejše, na ta način se lahko lotite bistveno večjih projektov, ki so še vedno lahko uspešni.
Programski jezik
Prva je gotovo odločitev, kateri programski jezik in ogrodja boste uporabili. V prvem delu smo namignili, da bo UI največkrat kot programski jezik izbrala Python, čeprav je umetna inteligenca spretna v mnogih priljubljenih programskih jezikih.
Če ste tudi vi suvereni v C#, Javi, PHP ali Go, je najpametneje, da s tem znanjem prepoznate, ali je načrtovana arhitekturna rešitev smiselna, ugotovite, kdaj UI kodo po nepotrebnem zaplete, in razumete napake, ki jih bo UI naredila.
Če ne poznate nobenega programskega jezika dovolj dobro, svetujemo, da za spletne aplikacije izberete TypeScript za zahtevnejše in JavaScript za zares enostavne. Če analizirate in obdelujete podatke ali jih vizualizirate, izberite Python. Za namizne aplikacije v sistemu Windows izberite C# /.NET. Za strežniške aplikacije, ki jih boste namestili na Linux, pa je izvrstna izbira Go, ki se ponaša s hitrostjo izvajanja in skromno porabo pomnilnika.
Manj primerni izbiri sta PHP, ki ga uporabljajo predvsem spletne aplikacije starejšega tipa, in Java, ki je največkrat uporabljena za poslovne aplikacije. Če ne pišete ravno gonilnikov ali druge izjemno občutljive kode, potem tudi C++ in Rust nista prva izbira.
Pri načrtovanju se lahko naslonimo tudi na dobre prakse UI, če jo prosimo za načrt in predloge izboljšave podanih navodil.
Arhitektura
Pred nadaljevanjem našega projekta bo smiselno, da razmislimo tudi, kakšno obliko aplikacije si želimo. Bo to aplikacija, ki jo bomo občasno pognali na lastnem računalniku, ali pa bo to spletna aplikacija, ki jo bomo namestili na strežnik ali NAS? Bo aplikacija delovala samo znotraj našega omrežja ali bo dosegljiva prek spleta? Direktno ali prek VPN? Bo imela več uporabnikov ali jo bo uporabljal le avtor?
Kombinacij je preveč, da bi bilo mogoče sestaviti dovolj zanesljiva in enostavna priporočila. A k sreči nam na pomoč lahko priskoči UI, ki bo iz zapisanih želja in omejitev sestavila predlog, kako zasnovati smiselno, a še vedno dovolj enostavno arhitekturo naše aplikacije.
Za našo aplikacijo 'kokpit' lahko vprašamo nekaj takega: »Pravkar razvito aplikacijo želim nadgraditi tako, da bo podatke hranila v podatkovni zbirki. Uporabnik bo en sam, to sem jaz. Aplikacijo bi rad namestil kot 'docker container' na moj NAS, kjer bodo tekli samodejni zajemi in obdelave, do vsebin pa želim dostopati s svojega računalnika. Za začetek le iz mojega omrežja. Pripravi predlog arhitekture in izberi top tri jezike in ogrodja, ki so najpriporočljivejša in zahtevajo čim manj dodatnih komponent.«
Agent UI lahko pripravi tudi dokumentacijo in vizualizacijo sprejetih odločitev. Naročite mu, da pripravi poročilo v obliki strani HTML, ki si jo nato ogledate v brskalniku, potrdite načrt, povprašate o dodatnih informacijah ali pa zahtevate spremembe.
Dokument lahko izkoristite še za zapis odločitev, ki ste jih sprejeli, skupaj z njihovo razlago. To bo pomagalo UI, da se kasneje ne vrača k vprašanjem, ki ste jih z agentom že odprli, in ne odpira ponovno odločitev, ki ste jih že sprejeli.
Dobra praksa je, da naročimo agentu, naj izdela razlago in vizualizacijo arhitekture ali konceptov, ki jih uporabljamo. Tako bomo lažje zaznali neskladnosti med pričakovanjem in načrtom.
Podatki
Ne glede na to, kakšno aplikacijo razvijate, boste skoraj gotovo med zagoni želeli ohraniti podatke. Naj gre za podatke, ki ste jih vnesli ali naložili, podatke, ki ste jih zbrali, ali pa nastavitve aplikacije.
Najenostavneje je, če boste agentu naročili, da podatke hrani v datotekah, recimo v mapi data.
Če pa želite narediti korak dlje, bo zelo koristna uporaba podatkovnih zbirk. To pa še ne pomeni, da morate izbrati in namestiti podatkovni strežnik, kot je, recimo, MySQL/MariaDB ali PostgreSQL. Za aplikacije, ki jih uporabljate sami ali jih delite z nekaj deset nezahtevnimi uporabniki, ki sočasno ne zapisujejo in pregledujejo ogromnih količin podatkov, je navadno boljša izbira SQLite – podatkovna zbirka v eni datoteki, ki ne potrebuje ločenega strežnika. Tako boste deležni dobrot dveh svetov – enostavnosti datotek ter zmožnosti in hitrosti podatkovnih zbirk.
Agenti UI so zelo spretni pri kreiranju in uporabi podatkovnih zbirk SQLite, uporabljamo pa jih v vseh modernih programskih in skriptnih jezikih ne glede na to, v katerem operacijskem sistemu delujete.
Še praktičen namig – agentu naročite, naj pred vsakim prenosom aplikacije v produkcijsko okolje naredi varnostno kopijo podatkovne zbirke. Na ta način boste omejili škodo, če boste datoteko po nesreči napačno spremenili ali celo pobrisali. Torej: pred spremembo sodi programska koda na git, podatkovna zbirka pa v kopijo datoteke.
Varnejši razvoj in testiranje
Če berete ali poslušate članke o UI, potem vas gotovo vsaj malo zaskrbi, ko pomislite, da bo UI samostojno delovala v okolju vaših naprav z vašimi pravicami. Kako torej zagotoviti, da tudi pri razvoju po občutku ne bomo naredili škode?
Odgovor ni eden, plasti varovanja je več. Prva je ta, da vsi s(p)odobni agenti upoštevajo pravilo, da imajo pravico brati in pisati le v mapi, kjer ste jih pognali. Le vi jim lahko dovolite, da bodo začeli brkljati po drugih mapah, zato je smiselno, da smo pri tem previdni in upoštevamo, da je to pravilo odvisno od agenta, okolja in nastavitev ter se nanj ne zanašamo preveč.
Dobra praksa je, da agent ne teče z vsemi vašimi pravicami in na vašem računalniku, kjer so občutljivi podatki. Namenite mu lahko drug uporabniški račun ali ga poganjate v virtualnem računalniku, kjer je skušnjav manj. Agenti, kot sta Codex in Claude Code, že sami privzeto tečejo v lastnem peskovniku, iz katerega lahko pokukajo le z našim dovoljenjem, a zlato pravilo varnosti je uporaba več slojev. Vsak prinese dodatno zaščito, ker popolne pač ni.
Hkrati se agenti aktivno borijo proti temu, da bi 'videli' vaše ključe ali gesla in jih shranili v zgodovino pogovora. Upoštevajte njihove nasvete in gesel ne lepite v klepet, raje jih shranite v datoteke ali kot sistemske spremenljivke. Ne vključujte jih v kodo in ne shranjujte v git ter agentu omejite dostop do njih.
Dobra praksa je tudi, da agenta z ukazom ne napotite takoj na delo, ampak mu naročite, naj vam najprej predstavi načrt. Ob njegovem pregledu boste morebiti opazili napačno razumevanje navodil ali sumljiv način za dosego cilja, še preden se bo zgodil.
Če agent sam ne bo začel pisati programskih testov, mu naročite, naj za napisano kodo najde način, s katerim bo preveril pravilnost delovanja, še preden jo boste pognali na pravih podatkih ali ciljnem strežniku.
Programski agenti se trenutno razvijajo hitreje kot sodobni VJM in v novejših različicah agenti že sami predlagajo in po vašem dovoljenju poženejo brskalnik, v katerem tudi vizualno in prek zapisa napak preverijo, ali spletne aplikacije delujejo kot pričakovano. K temu jih lahko spodbudite ali jim naročite, naj za testiranje uporabijo zelo priljubljeno in zmogljivo ogrodje za testiranje Playwright.
Dobra praksa je tudi, da v svoj program vgradite pisanje dnevnikov delovanja, ki naj vključujejo zapise uspešno izvedenih korakov kode, še pomembneje pa je, da zapisujete sumljive trenutke in napake. Takšna datoteka je lahko zelo koristna pri razumevanju, kako aplikacija deluje oziroma ne deluje, v veliko korist pa bo tudi agentu UI pri razvoju in raziskovanju morebitnih napak.
Če je neprekinjeno delovanje pomembno, lahko brez večjih težav dodate sporočanje, ko gre kaj narobe. Pošiljanje SMS je mogoče opraviti prek enega izmed mnogih servisov, recimo Twilio. Če uporabljate Discord ali Signal, lahko z nekaj konfiguracije na platformi pošiljate sporočila tudi brezplačno. Za nadzor rednega izvajanja opravil je zelo priročna storitev Health checks.io, ki deluje na principu sprožanja alarma, če se aplikacija po predvidenem urniku ne javi s klicem API.
Gostovanje
Če boste aplikacijo res uporabljali le na eni napravi, potem težav z nameščanjem ni – ko jo boste potrebovali, jo boste pognali. Pomaga vam kar UI. Še bolje pa bo, če bo UI pomagala pripraviti datoteko.bat v sistemu Windows ali skript za drug operacijski sistem, ki bo pognal vse potrebno, da boste aplikacijo lahko uporabljali.
Če bo aplikacija imela več kot enega uporabnika ali pa jo boste želeli uporabljati s prenosnika in telefona, bo najenostavneje, če jo boste namestili na NAS, če ga le imate in podpira namestitev vsebnikov Docker. V nasprotnem primeru pobrskajte, ali se vam kje valja star PC ali prenosnik z vsaj 4 GB pomnilnika RAM, na katerega lahko namestite strežniško različico Linuxa. Najenostavneje bo, če boste izbrali Ubuntu Server. Kar pripravite ključek USB, za natančna navodila za namestitev in prilagoditve pa pobarajte UI!
Če ne gre drugače – nimate NAS ali drugega strežnika in ga tudi ne morete vzpostaviti –, je na spletu precej možnosti, da svojo aplikacijo zelo poceni poganjate pri enem od mnogih ponudnikov gostovanja in oblačnih storitev. Med evropskimi ponudniki sta najbolj poznana Hetzner in OVHcloud, med domačimi pa NEOSERV ali Domenca. Osnovno gostovanje vas bo verjetno stalo od tri do pet evrov mesečno. Za pomoč pri izbiri paketa gostovanja povprašajte UI – ta najbolje pozna strežniške zahteve rešitve, ki jo je pravkar razvila.
Varnost
Najenostavnejša rešitev za varnost je, da aplikacijo poganjate in uporabljate le v lastnem omrežju. Če jo boste s svetom delili z lastnih strežnikov, se odpiranju vrat poskusite izogniti. Za dostop prek VPN priporočamo Tailscale, ki omogoča povezovanje naprav v virtualno omrežje ne glede na to, kje so naprave, in je zelo priljubljen med navdušenci nad domačimi strežniki. Če želite aplikacijo deliti z drugimi, je dobra rešitev tudi (prav tako brezplačna) uporaba Cloudflare Tunnel, ki aplikacijo zaščiti pred boti in drugimi avtomatiziranimi škodljivci. V kombinaciji s storitvijo Access pa omogoča tudi zaščito z enkratnim geslom, ki ga prejmete na elektronski naslov, s prijavo z računom Google in na še več priročnih načinov.
Ko boste drznejši, pa lahko z UI razvijete zmožnost zaščite aplikacije po standardu OpenID Connect (OIDC) in med splet in aplikacijo postavite povratni posredniški strežnik (reverse proxy) – priporočamo Traefik ali Caddy – ter aplikacijo povežete s prijavno storitvijo, recimo Pocket ID. Zdaj, upam, že veste, da vam tudi pri namestitvi in konfiguraciji tega dela arhitekture pomaga UI!
Za nekoliko bolj resno postavitev aplikacij, predvsem zaradi uporabe varne komunikacije med brskalnikom in strežnikom prek protokola HTTPS, priporočamo, da si omislite lastno domeno.
Nova različica naše aplikacije
Z novimi dimenzijami, ki smo se jih dotaknili v prejšnjih razdelkih, lahko zasnujete in razvijete naprednejšo različico domače aplikacije osebnega kokpita, ki smo jo razvili po občutku v prvem članku.
Razložite agentu, kako želite uporabljati aplikacijo – kar na svojem računalniku ali načrtujete prenos na lastni ali spletni strežnik. Kako boste zaščitili dostop in kdo bodo uporabniki? Predebatirajte izbiro tehnologij in arhitekturnega pristopa ter se ne ustrašite, če bo predlagana menjava. UI je izjemno spretna pri prepisovanju programske kode iz enega jezika v drugega in spreminjanju arhitekture (enostavnih) rešitev.
Predlagam, da agentu naročite, da vzpostavi in za shranjevanje zgodovinskih podatkov uporabi podatkovno zbirko. Da ta ne bo rasla v nedogled, dodajte periodično obdelavo, ki bo po nekaj dneh zgodovinske podatke pobrisala.
Predlagajte agentu, da za razvito kodo napiše teste enot (unit tests), da bo lahko samodejno preverjal delovanje nevidnih strežniških zmožnosti, recimo zajema. Hkrati ga opogumite, da vaše pripombe in želje pri razvoju uporabniškega vmesnika po razvoju preveri v brskalniku ali s Playwrightom.
Občasno lahko agentu naročite, naj priskrbi pregled kode ter poišče napake in nepotrebno zapletene zadeve, nato pa pripravi predloge za popravke.
Nato je čas, da razdelamo strategijo varovanja. Če bo aplikacija delovala samo v vašem omrežju, večjih težav z varnostjo verjetno ne bo. Če bi želeli do aplikacije dostopati tudi, ko niste doma, razmislite o VPN, če pa računate na več uporabnikov, je nujno, da več časa posvetite načrtovanju in implementaciji varnostne strategije, ki vključuje prijavo z geslom, varno hrambo podatkov, dostop prek šifrirane povezave pa je tako in tako nujen, upajmo, že samoumeven. Najenostavnejši način za prijavo v aplikacijo je, da omogočite prijavo z računi Google, Microsoft in s podobnimi, UI pa vam bo povedala, kako urediti registracijo aplikacije v oblačnih storitvah tehnoloških velikanov.
Ko boste z aplikacijo zadovoljni, lahko agentu naročite, naj pripravi skript za prenos v produkcijsko okolje – na vašo napravo ali v oblak. Skript je veliko boljši kot postopek, ki ga vsakič izvede agent, saj bo deloval vedno enako, bo zanesljivejši in hitrejši, porabil pa bo tudi manj sredstev. Za povrh si lahko, ko boste v intenzivni fazi razvoja, omislite samodejno prenašanje v testna in produkcijska okolja, seveda po uspešnih preskusih, da deluje pravilno.
Rezultat je zdaj aplikacija, v katero se uporabnik prijavi, vsak pa ima lahko svoje nastavitve in preference, katere podatke prikazati. Hkrati lahko dodamo nove preglede trendov spreminjanja opazovanih podatkov, npr. temperatur ali cen.
Nova različica aplikacije uporablja podatkovno zbirko, zahteva prijavo in se zna namestiti sama. Če nam videz ni všeč, se lahko poigramo tako, da agentu naročimo, naj izdela 10 različic in nato izberemo tisto, ki nam najbolj ugaja.
Oblikovanje uporabniškega vmesnika
Področje, kjer umetna inteligenca še ne dosega človeka, je oblikovanje. Razlag in vzrokov, zakaj je tako, je mnogo in nekateri menijo, da bo sčasoma UI tudi tu lahko parirala (povprečnim) oblikovalcem.
Do takrat pa priporočamo, da ne prepustite agentu in UI, da izbirata videz, ampak jima posredujte spletne strani ali povezavo do programske kode spletne strani, portala ali orodja, ki vam je oblikovno všeč. Brez težav bo skopiral osnovne poteze, kar bi za domače aplikacije moralo biti več kot dovolj.
AGENTS.md
Vprvem delu smo na hitro omenili AGENTS.md, ki jo razumejo tako rekoč vsa orodja in je postala kar del programske kode, ki jo razvijalci delijo in hranijo, na primer v oddaljenem repozitoriju git.
Če smo ob prvih začetkih navodila za agenta pisali ročno, je danes najlažje, da mu naročite, naj datoteko ustvari in v njej hrani informacije, ki jih bo potreboval naslednjič.
Pri zahtevnejšem razvoju je agentu UI modro naročiti, naj v datoteko ne shranjuje zgodovine sprememb, saj je temu namenjena zgodovina sprememb v gitu (saj ste naredili repo, kot smo se naučili v prvem delu, kajne?).
Koristno je, če mu naročite, da po vsaki opravljeni nalogi pripravi predlog za commit in vas pozove, da ga opravi. Takrat naj vas vpraša še, ali želite narediti push.
Med debatiranjem z UI lahko kadarkoli naročite: »Zapomni si to v AGENTS.md.« Agent bo navodilo shranil v AGENTS.md. Namignite, da je dobro, če si zapomni, čemu je aplikacija namenjena in kako okvirno deluje, kako jo prevede, preizkusi in prenese na strežnik. Zapomni naj si tudi odločitve, navodila, kako želite, da organizira in oblikuje kodo, in podobno.
Hkrati ga pozovite, naj v datoteko ne shranjuje gesel, ključev in podobnih varnostno občutljivih informacij. Ne pozabite: AGENTS.md shranite in delite skupaj s programsko kodo!
Bodimo pozorni
Ko govorimo o aplikacijah, ki so na voljo prek spleta ter zajemajo in posredujejo podatke, je ključnega pomena varno delovanje. Splet je bojišče, in če smo se še pred leti bali hekerjev, so danes največja težava vsakega razvijalca boti. Ti neusmiljeno iščejo luknjo v prijavnem procesu, se trudijo dostopati do podatkov in želijo našemu programu posredovati podatke v obliki, ki bo program zlomila in kompromitirala. Problem je lahko tudi količina zahtevkov, ki ohromi strežnik in tako povzroči nedelovanje ostalih storitev na njem.
Izjemno je zato pomembno, da še pred objavo svoje kreacije na spletu ali mobilnih tržnicah stanje preverimo in odpravimo odkrite pomanjkljivosti.
Razviti varno prijavo je zahtevno, zato priporočamo uporabo prijavnih servisov ali storitev za varovanje, kot so povratni posredniški strežniki (reverse proxy, Traefik, Caddy in podobno) ali servis, kot je Cloudflare s storitvami Tunnel, ki omogoča dostop do domače spletne aplikacije brez odpiranja vhodnih vrat na usmerjevalniku. Access lahko poskrbi za preverjanje identitete uporabnikov in omejevanje dostopa do aplikacije. Osnovna storitev Cloudflare pa poskrbi še za preprečevanje porazdeljenih napadov za onemogočanje storitve (DDoS).
Če poskrbite še, da je aplikacija ustrezno ločena od ostalega omrežja, recimo z uporabo VLAN, in da imate varnostne kopije podatkov in kode, ste razmeroma varni.
Spomnimo se, da nimajo samo napadalci in drugi zlobneži močnih orodij, ampak jih imamo tudi mi!
V priljubljenem agentu začasno vklopite najmočnejši model in mu naročite, da varnostno pregleda aplikacijo, arhitekturo in postavitev ter predlaga popravke in dopolnitve. Če je mogoče, pregled izvedite z drugo UI, kot je tista, ki je aplikacijo napisala. Prakso redno ponavljajte, da morebiten spodrsljaj najdete in popravite, še preden bo prepozno.
Kaj izbrati?
Umetna inteligenca in izdelki na področju razvoja se tako hitro razvijajo in spreminjajo, da so vsi nasveti, ki jih podamo, lahko v trenutku zastareli. Kljub temu lahko podelimo nekaj nasvetov, kateri model izbrati za svoje delo.
Če uporabljate OpenAI Codex, za razvoj domačega programja skoraj gotovo ni treba izbrati najdražjih in najboljših modelov. V trenutku pisanja tega članka je uporaba GPT-6.1 Sol na srednji stopnji razmišljanja zelo učinkovit kompromis – napisana koda je zelo dobra, hkrati pa je uporaba dovolj poceni, da poraba žetonov in s tem cena ne bosta pretirani. Če ste naročeni na Anthropicov Claude, boste zelo veliko dobre kode lahko napisali z modelom Sonnet ali Opus 5.5. Vsekakor pa so poraba, kakovost izdelka UI in učinkovitost rabe odvisne od podane naloge.
Uporabite lahko tudi OpenCode in enega izmed njegovih brezplačnih modelov, kot je Big Pickle. Zavedajte se, da ti modeli uporabljajo vso vašo uporabo za nadaljnje učenje in izboljševanje delovanja modela, informacije, ki jim jih posredujete, pa se zelo verjetno znajdejo na strežnikih ponudnikov. Izplača se tudi redno spremljati preglede brezplačnih modelov, saj se občasno pojavijo nove, zmogljivejše različice.
Vedno pa velja splošno pravilo: če razvoj poteka predolgo ali je odziv med pozivi dolg, je velika možnost, da smo zahteve podali dvoumno, da si jih je UI razložila napačno ali da smo nalogo zakomplicirali mi. V takem primeru ustavite agenta in ga povprašajte, zakaj operacija traja tako dolgo. Pred začetkom razvoja ali konfiguracije pa je vedno modro prositi UI za ponovitev podane naloge z drugimi besedami in konstruktivno kritiko. Tako se lahko izognemo marsikateremu glavobolu.
Na spletu mrgoli primerjav modelov in težko je oceniti, komu gre zaupati, kdo pa je plačan, da na vrh lestvice postavi določen model. Med zaupanja vredne lahko štejemo storitev OpenRouter, ki trži dostop do mnogih modelov in izvaja analize na podlagi izkušenj svojih strank.
Brskanje začnite na openrouter.ai/discover in ne pozabite, da so razlike med modeli podobnih zmožnosti majhne in da po izkušnjah mnogih dajejo pretežno primerljive rezultate. Poleg tega se stvari tako hitro spreminjajo, da je zagovarjanje uporabe točno določenega modela precej kratkega trajanja.
