Studio

# AI kao tvoj lead developer: Nejra Coric na NetWorku u Neumu

Nejra Coric vodi CodeLoop Studio u Sarajevu. Ovo je njen zapis o radu s AI-em od nejasne ideje do nečega što će isporučiti: pitanja prije koda, jedan ekran po jedan, i privatni API ključ koji ne smije ostati na telefonu.

CodeLoop Studio·24\. oktobar 2026.·12 min čitanja

![Nejra Coric na NetWork 14 u Neumu, s konferencijskom akreditacijom i slajdom Human Upgrade iza sebe](https://www.codeloop.ba/_next/image?url=%2Fblog%2Fnetwork-neum%2Fnejra-coric-network-cover.jpg&w=3840&q=75)

Nejra Coric vodi CodeLoop Studio u Sarajevu. Ovo je njen zapis o predavanju na [NetWorku](https://www.networkkonferencija.ba/) 14 u Neumu, 21–23\. oktobra 2026: „AI kao tvoj lead developer“, od ideje do produkcije uz kontrolu nad svakom odlukom. [Engleska verzija](https://www.codeloop.ba/blog/ai-as-your-lead-developer-network-neum) je par ovoj stranici.

![Nejra Coric za govornicom, s naslovom predavanja na ekranu](https://www.codeloop.ba/_next/image?url=%2Fblog%2Fnetwork-neum%2Fnejra-at-the-podium.jpg&w=3840&q=75)

## Šta lead developer i dalje drži

Otvorila sam jednim pitanjem. Može li AI biti lead developer? Napisati funkciju, naći grešku ili skicirati nekoliko testova više nije iznenađujući dio. Korisno pitanje je koliki dio životnog ciklusa softvera mogu ubrzati, a da ne izgubim ono što moram isporučiti.

Kod je jedan dio tog ciklusa. Prije njega neko mora razumjeti zahtjev, napraviti plan i donijeti arhitektonske odluke. Poslije njega neko mora testirati, tražiti kvarove, provjeriti sigurnost, dokumentovati i održavati proizvod. AI koristim kroz cijeli taj raspon, od gole ideje preko funkcionalnosti, dizajna, implementacije, debugginga, testova i dokumentacije. Model za nekoliko minuta može napraviti nešto za šta su ranije trebali sati. Može napraviti i sigurnosni problem koji se duže ispravlja. Brže kucanje je manja ušteda. Veća je razumjeti problem ranije, uporediti opcije ili uhvatiti nešto što bih inače propustila.

Rad sam predstavila onako kako je studio stvarno postavljen. Software developer sam i osnivačica CodeLoopa, softverskog studija iz Sarajeva. Meni je prvo došao mobile, Android i iOS, a radimo i web aplikacije i custom softver. Dvije perspektive držim odjednom. Kao developer pitam da li arhitektura drži i da li proizvod zaista radi. Kao vlasnica pitam za rokove, budžet i to kako mali tim odgovori na veliki zahtjev, a da kvalitet i sigurnost ostanu. AI mi je promijenio način rada unutar te napetosti. Nije uklonio nijednu stranu.

Počela sam, kao većina developera, tako što sam model tretirala kao oštriji pretraživač. Imam problem, pošaljem dio koda, dobijem objašnjenje i nastavim. Prestao je biti alat koji otvorim samo kad zapnem. Proces sa slajdova i dalje je moj. Nisam nudila recept za koji tvrdim da odgovara svakom timu i svakom projektu.

## Kratak prompt izmisli konferenciju

Konferenciju pred sobom uzela sam kao primjer. Isti zadatak, web stranica za NetWork. Isti alat, Cursor. Dvije instrukcije.

Kratka je bila samo „napravi web stranicu za Network konferenciju“. Nisam imenovala sekcije, publiku, vizuelni identitet ni stack. Model je popunio praznine. Prvi ekran je izgledao završeno: veliki naslov NETWORK i rečenica „Gdje se veze pretvaraju u prilike“. To je generičko umrežavanje. NetWork je IT konferencija. Uz taj tekst model je izmislio govornike i cijene ulaznica i izabrao običan HTML. Stranica je izgledala gotovo. Gotov izgled nije isto što i tačan rezultat. Te činjenice nisam dala, pa je model dao svoje.

![Cursor, kratka instrukcija: Napravi web stranicu za network konferenciju](https://www.codeloop.ba/blog/network-neum/prompt-short.gif)

Kratka instrukcija u Cursoru.

![Generisana stranica s naslovom Gdje se veze pretvaraju u prilike, izmišljenim govornicima i cijenama ulaznica](https://www.codeloop.ba/blog/network-neum/result-short.gif)

Šta je kratka instrukcija proizvela.

Preciznija instrukcija imenovala je kakva je konferencija, kome je namijenjena, koje sekcije želim, paletu i Next.js. Prvi ekran je već znao događaj: „IT konferencija na Jadranu“, Neum, 21–23\. oktobar 2026\. Taj rezultat bio je bliži onome što sam zamislila, i još uvijek nije bio gotov. Pregledala sam sadržaj, podatke i ponašanje, pa prošla još jednu iteraciju. Petlju sam tamo imenovala: prompt, generisanje, pregled, dorada. Model vas dovede do verzije koju možete ocijeniti. Ocjena ostaje na vama.

![Cursor, instrukcija koja imenuje Neum, datume, crno-zlatnu paletu, IT publiku, sekcije i Next.js](https://www.codeloop.ba/blog/network-neum/prompt-detailed.gif)

Preciznija instrukcija: datum, publika, sekcije, paleta, Next.js.

![Generisana stranica s naslovom IT konferencija na Jadranu i datumima u Neumu](https://www.codeloop.ba/blog/network-neum/result-detailed.gif)

Šta je preciznija instrukcija proizvela.

Tu se vidi zašto prompt određuje koliko vremena ćete potrošiti. Kratka instrukcija traje minut. Račun stiže kasnije, kad prvi ekran izgleda završeno, a opisuje drugi događaj. Poruka, struktura, podaci i stack su pretpostavke. Svaka pretpostavka postaje refaktorisanje: brisanje izmišljenih govornika, ispravka naslova, zamjena steka, usklađivanje sa stvarnom konferencijom. To vrijeme izgleda kao običan rad na kodu. Cijenu nejasnog prompta tada više ne vidite, pa se čini da je generisanje bilo brzo.

Minute koje na početku odu na kontekst i zahtjeve vrate se kao posao koji ne morate raditi. Model i tada treba pregled. Kod jasnog zahtjeva dorada ide prema događaju koji ste imenovali. Kod kratkog, prvo rušite konferenciju koju je model pretpostavio. Dobar prompt, kako ja tu riječ koristim, jasniji je zahtjev. Ne mora biti duži. Što su jasniji cilj, kontekst i granice, manje vremena i resursa kasnije ode na ispravljanje pretpostavki koje su izgledale uvjerljivo.

Poenta mi je bila ko donosi odluku. Next.js nije automatski bolji stack.

Nema ni jednog toka rada koji odgovara svakom početku. Alat biram prema problemu.

* **Ideja, i još ništa nacrtano.** ChatGPT da pritisnem proizvod, alat poput Google Stitcha za prvi ekran, Figma da postavim vizuelni sistem, i tek onda Cursor.
* **Klijent koji već ima Figma fajl.** Čitam ekrane, komponente, stanja i tokove. Lijep okvir nije specifikacija. I dalje moram znati šta se dešava kad se pritisne dugme, kad API ne odgovori ili kad polje ostane prazno.
* **Referentni sajt i rečenica „nešto slično ovome“.** Proučavam strukturu i interakcije, pa gradim nešto što pripada tom klijentu. Cilj je vidjeti šta im se zapravo sviđa, ne kopirati stranicu.

U sva tri slučaja modelu ne dam da piše kod dok nema šta da razumije: šta već postoji i čemu ovaj zadatak zapravo služi.

## Ideja nije zahtjev

„Želim aplikaciju za svoj biznis“ je rečenica, ne proizvod. Iza nje su korisnici, poslovna pravila, ograničenja i odluke koje neko mora donijeti. Ako te odluke čekaju dok fajlovi već postoje, postaju skuplje. Primamljivo je otvoriti Cursor, opisati želju i gledati kako se pojavljuju ekrani. Pitanje kojeg se držim je jesmo li napravili ono što je potrebno, ili ono što je model pretpostavio da želimo.

Na malom timu stari put i dalje važi. Razgovor s klijentom, lista pitanja, scenariji, specifikacija, još jedno pojašnjenje. Taj posao postoji da se ne razvija pogrešan proizvod. AI ga ne briše. Koristim ga da dođem do nacrta koji mogu pregledati, umjesto da krećem od prazne stranice. Instrukcija koju dam je jednostavna: postavi mi pitanja na koja moramo odgovoriti prije implementacije. Model može predložiti teme, označiti nejasan zahtjev i skicirati prvu specifikaciju. Ne može potvrditi šta je klijent zaista odlučio. To i dalje radim ja. Red na mom slajdu je da je AI sagovornik, ne direktor proizvoda.

Uzmite jedan običan zahtjev. „Treba mi aplikacija za rezervaciju termina.“ Model će rado nacrtati kalendar i dugme za potvrdu. Stanem i odgovorim na šest pitanja prije nego što iko napiše taj ekran. Svako mijenja kod.

1. **Može li se termin otkazati?** Ako da, do kada, i šta se dešava s plaćanjem? Vraća li se termin odmah u kalendar? Jedna mala funkcionalnost povlači poslovna pravila, bazu, obavještenja i možda integraciju plaćanja.
2. **Mogu li dvije osobe rezervisati isti termin?** Ako oba telefona u 14 sati vide slobodan termin i oba pritisnu potvrdu, provjera koja živi samo na ekranu potvrdit će obje. Pravilo se mora osigurati na backendu, transakcijom i ograničenjem u bazi. Poslovno pitanje upravo je postalo arhitektonska odluka.
3. **Treba li osobi nalog?** Rezervacija bez naloga je brža. Historija, promjena termina ili podsjetnik traže korisnika, sesiju, oporavak pristupa i zaštitu tih podataka. Jedan odgovor mijenja obim projekta.
4. **Šta vidi administrator?** Zaposlenici, radno vrijeme, otkazivanja, možda izvještaji. Može li zaposlenik vidjeti samo vlastiti raspored? Ako ima više lokacija, ko šta vidi? Sakriti dugme nije autorizacija. Isto pravilo mora se provjeriti na serveru.
5. **Šta ako pružalac usluge otkaže?** Deset osoba je već rezervisalo. Ko se obavještava, kome se nudi novi termin i ko odlučuje? To je poslovni proces, ne jedan ekran.
6. **Šta ako zahtjev zakasni?** Osoba pritisne rezerviši, ništa se ne desi, pritisne ponovo. Je li server sačuvao prvu rezervaciju, a telefon odgovor nikad nije čuo? Treba definisan način da se ponovljeni zahtjev prepozna, da jedna radnja ne postane dvije rezervacije.

Demo koji radi može sakriti svaku od tih pretpostavki iza interfejsa koji izgleda gotovo. Funkcionalan demo nije proizvod koji je spreman.

## Napišite specifikaciju i zabranite višak

Kad ti odgovori postoje, i dalje ih ne lijepim u Cursor i ne kažem „napravi aplikaciju“. Pretvorim ih u nešto što mogu provjeriti. Instrukcija koju koristim je: na osnovu dogovorenog napiši zahtjeve, user stories, kriterije prihvatanja i rubne slučajeve. Ne dodaj funkcionalnosti koje nismo dogovorili.

Posljednja rečenica je važna. Tražite aplikaciju za rezervacije, a uslužan model predloži i loyalty program, sistem bodova, chat između korisnika i osoblja i preporuke. Zanimljivo, i van obima. Obim koji niste dogovorili dodatni je posao, ne poklon.

* **Zahtjevi** govore šta sistem mora raditi. Osoba može rezervisati slobodan termin. Administrator može upravljati dostupnošću.
* **User stories** govore kome služi i zašto. „Kao korisnik, želim vidjeti slobodne termine da odaberem vrijeme koje mi odgovara.“ To je svrha, ne dugme.
* **Kriteriji prihvatanja** govore kako ćete znati da je gotovo. Kad se slobodan termin rezerviše, sistem ga sačuva i prikaže potvrdu. Ako je termin u međuvremenu zauzet, sistem ne smije potvrditi drugu rezervaciju za isti resurs i vrijeme. Tu rečenicu možete implementirati i testirati. „Napravi rezervaciju“ ne možete.
* **Rubni slučajevi** su putevi koje demo preskače. Nema mreže. Isti zahtjev poslat dva puta. Administrator mijenja raspored dok neko rezerviše. Vanjski servis ne radi.

Developer, osoba koja testira i klijent tada mogu gledati isti dokument. Specifikaciju ne preskačem zato što model može napraviti nacrt. Koristim model da specifikacija brže nastane i da je lakše održavati. Neko ko stoji iza proizvoda i dalje mora potvrditi da dokument prati dogovor.

## Opcije, pa odluka

Gotovo svaki ozbiljan proizvod može se izgraditi na više načina. Greška koju viđam je odabrati stack koji već poznajete, ili pitati model „koju arhitekturu da koristim?“ i prihvatiti samouvjeren odgovor. Tražim opcije i cijenu svake. Oblik na mom slajdu je problem, opcije, kompromisi, odluka. Fleksibilnost često znači složeniji sistem. Brža prva verzija često znači granice na koje ćete kasnije naići. Lakše skaliranje često znači više vremena i novca u infrastrukturi.

Za aplikaciju za rezervacije prolazim tri oblika, i očekujem da čitalac dva odbaci.

* **Jedan salon, nekoliko zaposlenika, skroman promet.** Jedna aplikacija, jedan backend, jedna baza, jasni moduli. Brže do prve verzije, lakše za test, i iskreno o tome šta se dešava ako proizvod kasnije jako poraste.
* **Više lokacija, stroža pravila, više uloga, integracije pred nama.** Modularnije razdvajanje poslovne logike. Kupujete fleksibilnost i plaćate složenošću.
* **Platforma za hiljade pružalaca i odvojene poslovne domene.** Odvojeni servisi možda zasluže svoje mjesto. Donose i komunikaciju među servisima, distribuirane greške, više infrastrukture, monitoring, deployment i teži set testova. Ako će prvu verziju koristiti nekoliko stotina ljudi, deset mikroservisa je arhitektura za problem koji još nemate.

Prompt koji koristim imenuje stvarna ograničenja: zahtjeve, očekivani broj korisnika, budžet, šta tim već zna i kako proizvod treba rasti. Onda: predloži tri pristupa. Za svaki, prednosti, nedostatke, sigurnosne rizike, cijenu održavanja i tačku na kojoj prestaje imati smisla. To je korisnije od „koja je najbolja arhitektura?“ Model može objasniti lošu arhitekturu s istom sigurnošću kao i dobru. Odgovor tretiram kao materijal za odluku. I dalje provjeravam pretpostavke, sigurnost, trošak, i ponekad mali dokaz prije nego što se vežem. AI ubrzava pregled opcija. Ne poništava posljedice pogrešne odluke. Kad je sistem u produkciji, tim drži arhitekturu. Model ne.

Imam pravilo koje mogu ponoviti. AI predlaže. Developer odlučuje. Prije nekoliko godina, isprobati težu arhitekturu značilo je dane postavljanja prije nego što je vidite. Model taj početak sada može skicirati brzo. Složenost nije nestala. Do nje stignete ranije. Tehnički impresivno nije isto što i ispravno za ovaj projekat. Ista tehnologija može biti dobar izbor za jedan proizvod i loš za drugi, a model to ne može procijeniti bez stvarnih ograničenja.

![Nejra Coric za govornicom, sa slajdom o arhitekturi: rizičan direktan poziv AI provideru i kontrolisani put preko backenda](https://www.codeloop.ba/_next/image?url=%2Fblog%2Fnetwork-neum%2Ftalk-architecture.jpg&w=3840&q=75)

## Privatni ključ ne smije ostati na telefonu

Slajd koji sam nazvala „Arhitektura mora biti razumljiva“ uzeo je mobilnu aplikaciju koja zove AI servis. Dokumenti, tekst, slika, preporuka: oblik je isti. Aplikacija pošalje zahtjev i dobije odgovor, obično preko API-ja. Najkraći put je onaj koji sam označila kao rizičan. Telefon razgovara direktno s providerom, a privatni API ključ sjedi u aplikaciji, na uređaju koji osoba preuzme.

Na demou taj put izgleda gotovo. Dugme radi. Odgovor se vrati. Isporučena aplikacija se i dalje može raspakovati. Sakriti ili obfuscirati ključ nije pouzdano mjesto za kredencijal koji tereti vaš račun. Ko ga izvuče može trošiti na taj račun, probiti limit ili zloupotrijebiti servis. Demo koji radi nije isto što i siguran sistem.

Kontrolisani crtež stavlja naš backend između telefona i providera. Aplikacija više ne drži privatni ključ providera. Zove backend. Backend provjerava ko zove, smije li ta osoba koristiti funkcionalnost i treba li zahtjev uopšte ići dalje. Tek onda server, s ključem koji ostaje na serveru, razgovara s providerom i vraća rezultat. Tu možete postaviti limit, zapisati greške, odlučiti šta izlazi iz sistema i zamijeniti ključ bez nove verzije u storeu.

Backend ne tretiram kao čarobnu bravu. Nemaran auth na serveru i dalje je ozbiljna rupa. Dobijate mjesto na kojem te kontrole mogu živjeti, umjesto da ključ povjerite aplikaciji koju dajete javnosti. Ista logika pokriva pristup bazi, korisničke tokene i administrativne privilegije.

Tu generisani kod uvlači ljude u problem. Ako modelu kažete da poveže mobilnu aplikaciju s AI API-jem, često će uzeti najkraći put koji radi. Neki klijentski kredencijali su napravljeni za to. Privatni ključ plaćenog računa nije među njima. Direktna integracija je brži prototip. Serverski put je više posla: endpoint, provjera pristupa, zaštićeni kredencijali, limiti i testovi. To vrijeme sam spremna potrošiti. AI mi može pomoći da endpoint i testove napišem brže. Brzina je loš razlog da se preskoči sigurnosni zahtjev. Ako ne mogu objasniti kako sistem štiti ključ, modelovo „gotovo“ nije gotovo. AI može napisati kod. Developer i dalje mora znati šta taj kod izlaže, šta štiti i šta se dešava kad zakaže.

## Jedan ekran postavlja pravila

Kad krećem od ideje, put dizajna na mom slajdu je ideja, ChatGPT, Stitch, Figma. Svaki alat ima drugi posao. ChatGPT je mjesto gdje prolazim proizvod prije piksela: kome je namijenjen, kako izgleda prvo otvaranje, može li se koristiti bez naloga, šta se dešava ako osoba odustane na pola toka i kako izgleda prazan ekran. Radije na ta pitanja odgovorim u razgovoru nego da kasnije precrtavam deset ekrana.

Stitch je mjesto gdje iz tog opisa dobijem prvi interfejs. Tražim jedan ekran, obično onaj koji nosi glavni posao, i imenujem osjećaj, elemente, navigaciju i vizuelna pravila. Lijep screenshot još nije upotrebljiv interfejs. Primarno dugme može biti teško naći. Ekran može biti atraktivan i nepraktičan. Mijenjam ga. Figma je mjesto gdje taj pravac postaje komponente, tipografija, boja, razmaci i stanja na koja mogu pokazati dok se aplikacija gradi. Tu referencu želim prije nego što postoji velika količina aplikacijskog koda, jer velika izmjena dizajna postaje mnogo skuplja kad je kod napisan. Generisanje prijedloga je brže. Ne zamjenjuje dizajnera. Neko i dalje mora odlučiti da je prijedlog zaista dobar: ponašanje, pristupačnost, hijerarhija, način na koji se proizvod koristi.

Pravilo na kojem sam insistirala je jedan ekran po jedan. Prvi ekran postavlja vizuelni sistem za ostatak aplikacije. Paleta, tipografija, primarna i sekundarna dugmad, razmaci, kartice, navigacija i ono što osoba treba prvo primijetiti. Home, detail, profile i settings imaju različit posao. Home vodi do glavnog rada. Detail drži više o jednoj stvari. Profile drži podatke osobe. Settings mijenja kako se aplikacija ponaša. Osoba koja ih koristi ne bi smjela imati osjećaj da je na svakom tapu otvorila novi proizvod. Ista tipografija, ista paleta, isti razmaci, ista navigacija, isto ponašanje iste vrste komponente. Osoba koja je naučila šta radi primarno dugme treba to dugme sresti ponovo, s istim ponašanjem.

Ako u jednom promptu tražite cijelu aplikaciju — početni ekran, detalj, profil, postavke, registraciju, onboarding — ekrani se raziđu. Zaobljena dugmad na jednom, oštri uglovi na sljedećem, drugačija navigacija, drugačiji razmaci, drugačije veličine teksta. Radije prvo učvrstim prvi ekran, pa modelu kažem da ponovo koristi taj sistem: iste komponente, istu navigaciju, odobrene ekrane kao referencu. Zajednička dugmad, boje i razmaci postaju komponente i tokeni. Kasnija izmjena dešava se na jednom mjestu.

## Pročitajte projekat prije prve izmjene

Prije nego što agentu dozvolim da dira stvarni projekat, tražim da još ne piše kod. Slajd spaja Figmu i codebase, pa analizu, plan i implementaciju. Želim konkretno čitanje, ne tvrdnju da je „razumio repozitorij“. Šest provjera, prije novog ekrana ili nove funkcionalnosti:

1. **Arhitektura.** Gdje živi poslovna logika, kako su razdvojeni interfejs, servisi i podaci, i kojih se pravila ostatak projekta već drži. Na Flutter aplikaciji s jasnim slojevima ne želim API pozive u widgetu samo zato što je to najbrži način da ekran zasvijetli. Sutra će ga biti teže testirati i mijenjati.
2. **Navigacija.** Kako osoba dolazi do novog ekrana, uključujući notifikaciju ili direktan link, i šta radi Back. Mala izmjena navigacije može pokvariti tok koji već radi.
3. **Stanje.** Gdje stanje živi, mora li se promjena na jednom ekranu odmah vidjeti na drugom, i šta se dešava ako se aplikacija zatvori i ponovo otvori. Nova funkcionalnost treba koristiti način upravljanja stanjem koji projekat već ima.
4. **Postojeće komponente.** Dugmad, kartice, polja, dijalozi, zajednički stilovi. Želim da model nađe šta se može ponovo koristiti. Ponovna upotreba je dosljednost, ne samo brzina. Promijenite jedno zajedničko dugme i treba se promijeniti svuda gdje se to dugme koristi.
5. **Servisi i modeli podataka.** Ako ekran prikazuje rezervacije osobe, model mora pratiti odgovor koji backend već vraća, uključujući greške i prazan slučaj. Ne želim novi oblik podataka, ni novi servis, za nešto što već postoji.
6. **Granica zadatka.** Jedan ekran nije dozvola da se prepiše autentifikacija, konfiguracija baze ili API ugovor. Ako model nađe problem izvan zadatka, želim da ga prijavi, a ne da ga tiho „popravi“.

Tražim i da pokaže na kojim fajlovima i postojećim implementacijama zaključci stoje. Samouvjeren sažetak nije dokaz. Konflikt s trenutnim projektom želim naći prije diffa, ne nakon desetina izmjena.

Onda i dalje ne želim kod. Želim plan koji je dovoljno konkretan da ga mogu odbiti. Koji fajlovi će se mijenjati. Koje postojeće komponente će se koristiti. Treba li novih modela. Mijenjaju li se postojeći servisi. Šta ostaje netaknuto. Kako ćemo provjeriti rezultat. „Napravit ću ekran, povezati podatke i testirati“ ne govori mi ništa. Lista rezervacija je koristan primjer. Model predloži novi servis, novu karticu i novi način da se do nje dođe. Aplikacija već ima servis za rezervacije, karticu koja se koristi na drugom ekranu i sistem navigacije. Ispravka su tri rečenice: koristi postojeći servis, prilagodi zajedničku karticu, dodaj rutu u navigaciju koja već postoji. Radije promijenim pet rečenica u planu nego da popravljam pedeset fajlova.

Upoređujem to s novim developerom u timu. Od njega biste očekivali da pročita projekat prije nego što dira važan dio. Ne vidim razlog da od alata očekujem manje discipline. Sposobnost nije isto što i ovlaštenje. Prompt također nije sigurnosna granica. Kritične operacije i dalje traže stvarne dozvole, kontrole pristupa i pregled diffa. Granice su ono što mi dopušta da agenta koristim brže, jer je zadatak ograđen.

![Nejra Coric za govornicom, sa slajdom petlje: implementacija, pokretanje, pregled, ispravka, pa nastavak](https://www.codeloop.ba/_next/image?url=%2Fblog%2Fnetwork-neum%2Ftalk-iteration.jpg&w=3840&q=75)

## Implementiraj, pokreni, pregledaj, ispravi, nastavi

Demoi koje ljudi vide na internetu su jedan prompt i gotova aplikacija nekoliko minuta kasnije. Tako ne isporučujem nešto što će koristiti stvarna osoba, povrh postojećeg sistema, s poslovnim pravilima i podacima. Petlja na slajdu manja je od toga, i bliža poslu. AI generiše prvi pokušaj. Ja provjeravam stvarni rezultat. Onda:

1. **Implementiraj mali dio.** Jedan ekran, ili lista slobodnih termina, prije toka potvrde i svega oko njega. Ako agent odjednom izmijeni četrdeset fajlova, pregled je teži dio. Manji dio drži diff objašnjivim.
2. **Pokreni.** Na uređaju, simulatoru ili u browseru. Čist build nije tok koji radi. Ekran se može otvoriti dok dugme za potvrdu ne radi ništa, podaci mogu nestati na osvježavanju, ili se raspored može sudariti na drugoj veličini. To što model kaže da je gotovo nije provjera.
3. **Pregledaj** u odnosu na Figmu i zahtjeve. Razmaci, tipografija i to jesu li postojeće komponente ponovo iskorištene. I ponašanje koje statični okvir krije: loš unos, nema mreže, prazna lista, dvostruki tap. Ako se dizajn i trenutno ponašanje aplikacije ne slažu, želim da mi se taj sukob prijavi. Ne želim da model sam odlučuje bilo šta što dira sigurnost, podatke korisnika ili poslovna pravila.
4. **Ispravi konkretnu razliku.** „Ovo nije dobro, popravi“ ostavlja model da nagađa. „Razmak između naslova i kartice ne prati dizajn. Promijeni samo taj razmak“ može se provjeriti. Što je problem preciznije opisan, lakše je vidjeti je li zaista nestao.
5. **Nastavi** tek onda. Cijela funkcionalnost u jednom prolazu djeluje brže dok pogrešna pretpostavka ne natjera da je razmotate. Optimiziram prema rezultatu koji mogu objasniti i provjeriti, ne prema tome koliko je brzo završilo prvo generisanje.

Imam rečenicu za zamku. Vrijeme generisanja nije vrijeme isporuke. Model može napisati stotine linija za nekoliko minuta. Integracija, testovi, sigurnosni prolaz, poslovna pravila i provjera na više od jednog uređaja i dalje su posao. Ako sljedeća dva sata odu na vraćanje nečega što je ranije radilo, ništa nije postalo brže. Na proizvodu koji ljudi već koriste granicu napišem: koji fajlovi smiju da se mijenjaju, koje ponašanje mora ostati, koje komponente ponovo koristiti, koje testove pokrenuti.

## Onda pitam kako se kvari

Kad tok rezervacije radi onako kako je zamišljen, promijenim pitanje. Prestajem tražiti od modela da gradi funkcionalnost. Pitam kako funkcionalnost može prestati raditi. Dvije osobe rezervišu isti termin. Dvostruki tap koji pošalje dva zahtjeva. Timeout u kojem je server sačuvao rezervaciju, a telefon odgovor nikad nije čuo. 500 s backenda. Dugme koje onemogućite nakon prvog tapa nije dovoljno za dvostruki tap. Server mora prepoznati ponovljeni zahtjev kad ista operacija ne smije proći dva puta. Dvije osobe koje rezervišu u isti mah problem su konkurentnosti na backendu ili u bazi, ne loading indikator. Poenta nije da model čestita vlastitom kodu. Poenta je tražiti gdje ne radi.

S brojevima sam bila oprezna. Primjer uštede sati koji sam stavila na slajd označila sam kao ilustraciju, ne kao mjerenje vlastitih projekata. Tu ilustraciju izostavljam. Metoda je dio koji vrijedi zadržati.

## Pet pravila kojih se zaista držim

1. **Kontekst prije prompta.** „Napravi mi aplikaciju“ ostavlja modelu da popuni svaku prazninu, i popuniće je nečim što niste mislili. Imenujte šta gradite, kome, koji problem rješavate i koja ograničenja već znate. Model vam može pomoći da nađete praznine. Odgovore i dalje potvrđujete vi.
2. **Odluka prije generisanja.** Tražite opcije i kompromise. Brža izrada može biti skupa za održavanje. Dizajn koji se skalira može biti besmislen za proizvod koji još traži prve korisnike. Vi birate, prema stvarnim ograničenjima.
3. **Analiza prije koda.** Na postojećem projektu prva instrukcija je da se kod još ne piše. Postojeće komponente, navigacija, gdje žive podaci, kako su servisi organizovani i šta se ne smije mijenjati. Inače se vrijeme ušteđeno na generisanju koda vrati kao vrijeme popravke onoga što je radilo.
4. **Granice prije autonomije.** Agent koji može čitati repozitorij, mijenjati mnogo fajlova i pokretati komande treba preciznu izjavu šta smije dirati, uključujući ključeve i podatke korisnika. Jedan ekran ne traži novi sistem navigacije. Prolaz kroz dizajn ne traži prepisivanje backenda. Autonomija bez ograde brži je način da se napravi veći nered.
5. **Test i review prije produkcije.** Testovi koji prolaze nisu isto što i funkcionalnost koja je tačna, sigurna i spremna za stvarnu osobu. Ljudi koriste proizvod, ne prompt. Njih ne zanima je li funkciju otkucao developer ili model. Zanima ih da radi, da su im podaci sigurni i da se na proizvod mogu osloniti.

AI već može pomoći da se definišu zahtjevi, predloži arhitektura, skicira dizajn, napiše kod, generišu testovi, nađu greške, refaktoriše i dokumentuje. Može biti jak saradnik, analitičar, sparring partner za arhitekturu i još jedan par očiju dok testirate. Ne može preuzeti odgovornost. Cilj nije da model razmišlja umjesto nas. Cilj je da više dana ode na odluke koje i dalje traže osobu. Rečenica kojom sam zatvorila: AI može napisati kod. Mi stojimo iza proizvoda.

## Standard prema kojem radimo

To je standard koji sam opisala, i standard prema kojem radimo u CodeLoopu u Sarajevu. Ako želite imenovanu osobu na proizvodu, i AI tamo gdje skraćuje posao i pregled tamo gdje može nanijeti štetu, kratka verzija tima je na stranici [Tima](https://www.codeloop.ba/bs/tim). AI unutar proizvoda — krediti, privatnost, šta napušta telefon — drugi je posao od korištenja AI-a da se gradi, a živi uz [izradu mobilnih aplikacija](https://www.codeloop.ba/bs/izrada-mobilne-aplikacije) i [izradu softvera](https://www.codeloop.ba/bs/izrada-softvera).

[Ovaj zapis na engleskom.](https://www.codeloop.ba/blog/ai-as-your-lead-developer-network-neum)

Ključne tačke

* Nejra Coric, direktorica CodeLoop Studija iz Sarajeva, govorila je na NetWork 14 u Neumu, 21–23\. oktobra 2026\. Naslov: AI kao tvoj lead developer, od ideje do produkcije uz kontrolu nad svakom odlukom.
* Kratak prompt izmišlja činjenice koje nedostaju. Vrijeme na kontekst i zahtjeve na početku štedi kasnije refaktorisanje pretpostavljenog outputa.
* Prije koda traži pitanja na koja još treba odgovor, pa specifikaciju s kriterijima prihvatanja i rubnim slučajevima. Ne dodaje funkcionalnosti koje nisu dogovorene.
* Rizičan mobilni put stavlja privatni AI API ključ na telefon. Kontrolisani put je aplikacija, pa vlastiti backend, pa provider.
* Jedan ekran prvo postavlja vizuelna pravila. Implementacija ide u petlji: mali dio, pokretanje, pregled, konkretna ispravka, i tek onda nastavak.