Šta je najbitnije u ovom tekstu (Key Takeaways):
-
AI u razvoju softvera pravi ključni evolutivni skok: iz faze asistenta prelazi u fazu autonomnog agenta, odnosno digitalnog kolege.
-
Razlika je suštinska: asistent čeka direktno pitanje kako bi pomogao oko jedne funkcije, dok agent dobija širi cilj, planira korake, menja arhitekturu i samostalno prolazi kroz radni tok.
-
Alati poput GitHub Copilot Code Review sistema već koriste agentne mogućnosti za analizu konteksta celog projekta, dok se opcije automatskog pregleda i odobravanja Pull Request-ova postepeno uvode u inženjersku praksu.
-
Vrednost inženjera ubrzano se pomera sa pukog pisanja sintakse ka definisanju problema, obezbeđivanju konteksta, arhitekturi, upravljanju rizicima i inženjerskoj proceni (Engineering Judgment).
-
Istovremeno se javlja izražen paradoks: stepen usvajanja AI alata raste, ali poverenje developera u njihov rad ne prati taj tempo. Istraživanje Stack Overflow Developer Survey pokazuje da 84% programera koristi ili planira AI alate, ali čak 46% aktivno sumnja u tačnost rezultata, dok 66% inženjera navodi frustraciju rešenjima koja deluju „skoro tačno, ali ne sasvim“.
-
Programer budućnosti zato neće biti samo onaj ko najbrže koristi AI, već onaj ko najpreciznije prepoznaje situacije u kojima model greši.
Prvo je AI bio samo pametniji autocomplete
Početak ove tehnološke tranzicije delovao je prilično bezazleno. Programer bi započeo pisanje funkcije, a sistem bi ponudio logičan nastavak reda. Ušteda je merena u sekundama.
Ubrzo nakon toga, modeli su naučili da pišu cele funkcije, generišu jedinične testove, slažu kompleksne SQL upite, pišu regularne izraze i automatski generišu dokumentaciju. Ipak, osnovna dinamika posla ostala je nepromenjena: developer je taj koji u potpunosti razume zadatak, osmišljava rešenje i pažljivo kontroliše svaki korak izvršenja.
To je bila faza razvoja uz asistenciju (AI-assisted Development). Programer je čvrsto držao volan, dok je AI sedeo na mestu suvozača i povremeno predlagao kraći put.
Kada AI počne da dobija zadatke umesto pitanja
Dolazak autonomnih agenata iz osnova menja ovaj odnos. Sistem više ne dobija banalnu naredbu da napiše validaciju email adrese. Umesto toga, dobija zadatak: „Reši Issue #184“.
Da bi odgovorio na takav zahtev, agent mora samostalno da:
-
pročita i razume opis problema,
-
locira relevantne delove koda u repozitorijumu,
-
donese odluku šta tačno treba promeniti,
-
proveri postojeće testove i napiše nove,
-
sagleda potencijalne neželjene efekte na ostatak sistema.
To je organizaciono i tehnički neuporedivo bliže ulozi kolege nego pasivnog alata. Ne zato što model poseduje svest, namere ili moralnu odgovornost, već zato što preuzima zaokruženu jedinicu rada (work unit), a ne samo izolovanu instrukciju na nivou jedne linije koda.
AI kolega nije čovek, ali u radnom toku zauzima slično mesto
Ovu granicu moramo precizno povući. Veštačka inteligencija nema lične ambicije, ne gradi karijeru, ne oseća profesionalnu odgovornost i ne razume dinamiku ljudskih odnosa u kompaniji.
Međutim, posmatrano kroz prizmu procesa rada, ona preuzima ulogu stvarnog izvršioca: preuzme zadatak sa agilne table, vrati gotovo rešenje, zatraži dodatna pojašnjenja, otvori Pull Request i odgovori na primedbe tokom pregleda.
Suštinsko pitanje modernog menadžmenta zato više ne glasi da li mašina može da misli kao čovek, već kako organizovati agilni tim u kome deo svakodnevnih operativnih zadataka obavlja digitalni izvršilac.
Programer više nije prvi koji piše kod
U klasičnom razvojnom toku redosled je dobro poznat: Product Owner postavi zahtev, inženjer ga prouči, napiše kod, drugi inženjer uradi Code Review, a QA tim obavi testiranje pre puštanja u rad.
Uvođenjem agenata, tok rada dobija potpuno novu dinamiku:
-
Product Owner postavlja poslovni zahtev.
-
Developer definiše tehnički kontekst, bezbednosne okvire i ograničenja.
-
Agent samostalno generiše inicijalnu implementaciju.
-
Automatizovani AI pregledač radi prvu trijažu koda.
-
Developer radi fokusirani, dubinski pregled ključnih tačaka.
-
Automatizovani cevovod (CI/CD) proverava testove i sistem ide dalje.
Inženjer time prestaje da bude autor svakog pojedinačnog karaktera u editoru. On postaje arhitekta, strateg i validator promena koje sistem generiše.
Manje kucanja ne znači i manje inženjeringa
Često se zaboravlja da softversko inženjerstvo nikada nije bilo puko poznavanje i kucanje programske sintakse. Pisanje koda je samo mehanizam za rešavanje problema.
Prava inženjerska pitanja leže znatno dublje:
-
Kako će se ova arhitektura ponašati pod vršnim opterećenjem?
-
Šta se dešava ako eksterni servis prestane da odgovara?
-
Koji tehnički i poslovni kompromis (trade-off) svesno biramo?
-
Kako obezbeđujemo osetljive podatke korisnika?
-
Koliko će ova implementacija koštati tim za održavanje za dve godine?
Model bez problema može da izbaci dvadeset novih funkcija za pola minuta. Ipak, neko mora doneti zrelu odluku da li tih dvadeset funkcija uopšte treba da postoji u tom sistemu. To je inženjerska procena (Engineering Judgment) – a njena vrednost na tržištu raste srazmerno padu cene generisanja koda.
Paradoks brzine: proizvodnja koda raste, ljudska pažnja ostaje ista
Zamislimo razvojni tim koji je ranije u proseku kreirao pet Pull Request-ova dnevno. Uz pomoć agenata, taj isti tim sada može da proizvede dvadeset za isto vreme.
Postavlja se pitanje: da li je taj tim zaista postao četiri puta produktivniji?
Odgovor je daleko od jednostavnog. Ko će pažljivo pročitati tih dvadeset promena? Ko će sagledati njihov širi uticaj na sistem? Ko će preuzeti odgovornost kada tri naizgled nepovezane promene u produkciji izazovu lančani incident?
Ljudska kognitivna pažnja ne može se magično uvećati četiri puta samo zato što softver brže kuca. To stvara najveće usko grlo modernog razvoja: kapacitet izvršenja raste eksponencijalno, dok kapacitet verifikacije ostaje strogo ograničen.
Programer kao menadžer ograničene pažnje
U svetu hiperprodukcije koda, inženjer sve više liči na menadžera čiji je glavni resurs sopstvena pažnja.
Potpuno je neracionalno trošiti vreme na proveru formatiranja, nazive promenljivih ili standardne šablone koda (Boilerplate). Taj rutinski deo posla mašine rešavaju besprekorno. Ljudsku pažnju treba strogo sačuvati za segmente visokog rizika:
-
arhitekturu i domenske granice servisa,
-
bezbednost i upravljanje privilegijama,
-
kritične tačke u obradi poslovnih podataka,
-
skalabilnost baze i infrastrukture,
-
neočekivane lančane reakcije u sistemu.
Pravo merilo produktivnosti više ne glasi koliko je linija koda danas napisano, već na koje je ključne odluke utrošeno inženjersko razmišljanje.
Code Review postaje prva linija promene
GitHub Copilot već danas nudi mogućnost da analizira Pull Request koristeći celokupan kontekst repozitorijuma, projektna pravila i eksterne izvore podataka. Ipak, sam GitHub vrlo jasno naglašava da takav pregled ne može garantovati pronalazak svakog defekta i da ljudski nadzor ostaje neophodan.
AI je odličan kao prvi filter koji čisti trivijalnosti i ukazuje na očigledne propuste. Međutim, on ne može biti poslednja reč. U situacijama gde AI piše kod, a drugi AI model ga pregleda, lako se stvara privid potpune kontrole dok fundamentalne arhitektonske greške prolaze neprimećeno. Rutinu prepuštamo algoritmima, ali suštinske inženjerske odluke mora overiti čovek.
Senior developer više nije preskupi Linter
U tradicionalnim timovima, senior inženjeri su prečesto trošili sate na banalne komentare tokom pregleda koda: promeni ime promenljive, dodaj test za granični slučaj, pazi na null vrednost ili nemoj duplicirati ovu funkciju.
Iako su to korisne opaske, izuzetno je neisplativo da najiskusniji i najskuplji ljudi u kompaniji glume lintere. Automatizovani alati danas taj nivo provera rešavaju u sekundi.
Zahvaljujući tome, senior inženjer se konačno može posvetiti suštini:
-
Zašto ova poslovna logika uopšte pripada ovom servisu?
-
Šta radimo ako ova zavisnost (dependency) iznenada postane nedostupna?
-
Da li uvođenjem nove tehnologije pravimo dugoročni operativni problem?
-
Kako će izgledati migracija ovog sistema za tri godine?
Pregled promena zasnovan na riziku (Risk-based review)
Ukoliko deset agenata paralelno proizvodi promene, oslanjanje na to da će senior ručno pregledati svaki detalj vodi direktno u paralizu tima.
Rešenje leži u formalnoj klasifikaciji promena prema nivou rizika:
-
Promene niskog rizika (Low-risk): Izmene dokumentacije, jednostavni stilski popravci i rutinski testovi prolaze kroz automatizovane provere i AI odobrenje.
-
Promene srednjeg rizika (Medium-risk): Dodavanje standardnih funkcionalnosti zahteva brzi ljudski pregled uz zeleno svetlo automatskih testova.
-
Promene visokog rizika (High-risk): Izmene autentifikacije, migracije finansijskih baza, kriptografija i rukovanje ličnim podacima traže detaljnu, višeslojnu analizu iskusnih inženjera.
Tretirati izmenu README fajla i refaktorisanje bezbednosnog protokola na isti način predstavlja organizacioni promašaj.
Kako AI agenti menjaju Daily Scrum i planiranje sprinta
Zamislite jutarnji sastanak (Daily Scrum) na kome pored programera, testera i Product Owner-a ravnopravno učestvuje i pet aktivnih agenata. Oni, naravno, neće pričati na video-pozivu, ali njihovo operativno stanje mora biti jasno vidljivo celom timu:
-
Koliko je zadataka povereno agentima i u kom su statusu?
-
Koji agent je blokiran zbog nejasnih zahteva?
-
Koji Pull Request čeka na inženjersku proveru?
-
Gde su automatski testovi pali i zašto?
Daily Scrum time prestaje da bude dosadno pojedinačno raportiranje o tome šta je ko radio juče. On postaje operativni pregled hibridnog sistema u kome ljudi i agenti sarađuju ka ostvarenju cilja sprinta.
Samim tim, planiranje sprinta više ne može biti prosta računica bazirana na broju radnih sati developera. Kapacitet tima postaje kombinacija ljudskog kapaciteta, kapaciteta agenata, ali pre svega kapaciteta tima da te promene pregleda, testira i bezbedno pusti u rad.
Pad značaja klasične brzine (Velocity)
Ako softverski agent može da izgeneriše kompleksnu funkcionalnost za dva sata, broj osvojenih „Story poena“ naglo skače. Međutim, to ne znači automatski da je kompanija isporučila veću vrednost korisnicima.
Kao što nalazi DORA istraživanja jasno pokazuju, veštačka inteligencija deluje pre svega kao pojačivač (Amplifier) stanja u kom se organizacija već nalazi:
-
Ukoliko imate loše postavljene testove, AI će samo proizvesti ogromnu količinu koda koji neprovereno prolazi kroz sistem.
-
Ukoliko vam je proces pregleda površan, dobićete gomilu izmena koje niko suštinski ne razume.
-
Ukoliko vam je arhitektura loša, uz AI ćete je samo znatno brže zakomplikovati.
Brzina kucanja više nije usko grlo. Glavno pitanje postaje kvalitet inženjerskog sistema koji tu brzinu treba da apsorbuje.
Definisanje problema i Context Engineering postaju ključne veštine
Kada inženjer agentu zada instrukciju: „Napravi sistem za prijavu“, agent će to uraditi za minut. Ali koje standarde koristi? Da li je u pitanju OAuth, SSO, MFA ili Passkeys? Koji su bezbednosni zahtevi? Kako se upravlja sesijama?
Ako je zahtev nejasan, brzina agenta postaje mana, a ne prednost – sistem će neverovatno brzo i efikasno implementirati potpuno pogrešnu stvar. Zato sposobnost preciznog uokviravanja problema (Problem Framing) postaje jedna od najtraženijih veština.
Uporedo sa tim, inženjering konteksta (Context Engineering) potiskuje dosadašnji koncept „magičnih promptova“. Agent mora tačno da zna:
-
koja interna pravila kodiranja važe u firmi,
-
kakve su arhitektonske odluke ranije donete,
-
koje interne API servise sme da poziva,
-
gde se nalaze granice poverenja u sistemu.
Dizajniranje informacija, pravila repozitorijuma i integracija sa bazama znanja postaju ključan inženjerski zadatak.
Znanje iz glave mora preći u dokumentaciju
U skoro svakom IT timu postoji čuveni obrazac: „Zašto je ovaj servis ovako povezan? Pitaj Petra, on to drži u glavi“.
Agentu takvo prećutno znanje nije dostupno. Da bi digitalni saradnik uopšte mogao da donosi smislene odluke, kompanije su prinuđene da napokon formalizuju ono što su godinama ignorisale:
-
zapise o arhitektonskim odlukama (Architecture Decision Records – ADR),
-
kataloge servisa i njihove međusobne zavisnosti,
-
jasno definisana pravila vlasništva nad kodom,
-
mašinski čitljive bezbednosne polise.
Dokumentacija prestaje da bude dosadna formalnost koju niko ne čita. Ona postaje direktan ulazni parametar za rad agenata. Ako je dokumentacija loša ili zastarela, promene koje agent generiše biće podjednako loše.
Odgovornost uvek ostaje ljudska
Kada agent napiše kod, automatski pregledač ga odobri, testovi prođu, a u produkciji dođe do pada baze ili krađe podataka – postavlja se ključno pitanje: ko je zapravo kriv?
Kompanija pred korisnicima i regulatorima ne može jednostavno reći da je sistem pao jer je veštačka inteligencija pogrešila. Agent može imati visok nivo autonomije u radu, ali pravna, operativna i profesionalna odgovornost uvek ostaje na ljudima.
Zbog toga svaki agilni tim mora imati jasan revizorski trag: koji je agent korišćen, sa kojim kontekstom, ko je postavio zahteve i koji je inženjer svojim potpisom preuzeo odgovornost za puštanje koda u rad. Delegiranje posla nikada ne sme postati bežanje od odgovornosti.
Tiha kriza za juniore i rizik od atrofije veština
Najosetljivije pitanje ove tranzicije odnosi se na inženjere na početku karijere. Juniori su decenijama sticali zanat upravo kroz one zadatke koje AI danas rešava za par sekundi: popravljanje sitnih grešaka, pravljenje osnovnih formi, pisanje rutinskih testova i čitanje tuđeg koda.
Ako sav taj rad prepustimo agentima, a od juniora tražimo samo da pritisne dugme za spajanje koda, postavlja se pitanje kako će ti ljudi ikada razviti inženjersku intuiciju.
Postoji realna opasnost od atrofije veština (Skill Atrophy). Inženjer koji nikada nije proveo sate tražeći skriveni bag u sistemu teško će moći da reaguje kada kompleksna produkcija otkaže u kriznom trenutku.
Rešenje nije u zabrani korišćenja modernih alata, već u radikalnoj promeni mentorske prakse:
-
AI generiše početno rešenje, ali junior ima zadatak da ga do detalja objasni.
-
Zašto je primenjen baš ovaj šablon, a ne neki drugi?
-
Gde se kriju granični slučajevi koje model nije predvideo?
-
Kako bi se ovaj kod ponašao pod velikim brojem paralelnih upita?
Učenje se time pomera sa mukotrpnog kucanja sintakse na rano razvijanje analitičkog razmišljanja.
Seniori kao mentori i ljudima i AI sistemima
Uloga seniora dobija novu dimenziju. Oni više ne prenose znanje samo na mlađe kolege kroz razgovor, već ga ugrađuju direktno u pravila po kojima agenti funkcionišu.
Umesto da u svakom pregledu koda iznova ponavlja zašto se neka praksa ne koristi, senior to pravilo postavlja u kontekst razvojnog okruženja. To omogućava skaliranje stručnosti kroz celu firmu. Ipak, odgovornost je ogromna: ako senior postavi pogrešno ili zastarelo pravilo, agenti će ga neumoljivo i dosledno primenjivati na stotinama mesta u sistemu.
Opasnost od poslušnog agenta i prividne ljudske kontrole
Iskusan kolega će vam često reći: „Ovaj zahtev nema nikakvog smisla, napravićemo problem ako ovo ovako uradimo“.
Za razliku od čoveka, AI model je izuzetno poslušan. Ako mu zadate loše osmišljen zadatak, on će ga sa savršenom preciznošću pretvoriti u katastrofalan kod. Zato najbolji agenti nisu oni koji po svaku cenu završe zadatak, već oni koji su kalibrisani tako da prepoznaju nesigurnost, postave potpitanje i zaustave rad dok ne dobiju ljudsku potvrdu.
Takođe, moramo se čuvati prividne ljudske kontrole (Human Rubber Stamping). Ako inženjer pred kraj radnog vremena dobije dvanaest masivnih Pull Request-ova sa hiljadama linija generisanog koda i samo formalno klikne „Approve“ jer testovi prolaze zeleno, stvarna kontrola više ne postoji. Čovek u procesu ima smisla samo ako ima dovoljno vremena, znanja i fokusa da kritički preispita ono što pregleda.
Nova uloga Scrum Master-a i Product Owner-a
Uvođenje agenata menja i ostale uloge u agilnom timu.
Scrum Master koji se godinama bavio samo administrativnim vođenjem sastanaka i prepisivanjem zadataka u Jira-i brzo gubi svrhu, jer automatizovani alati te izveštaje prave u realnom vremenu. Njegova stvarna vrednost sada leži u razumevanju sistema: uočavanju uskih grla u protoku posla, usklađivanju dinamike između ljudi i mašina i uklanjanju organizacionih blokada.
Sa druge strane, Product Owner dobija praktično neograničen kapacitet implementacije, što sa sobom nosi rizik od nekontrolisanog gomilanja nepotrebnih opcija (Feature Inflation).
Kada je razvoj koda skup, visoki troškovi prirodno filtriraju loše ideje. Kada implementacija postane izuzetno jeftina, Product Owner mora imati čeličnu disciplinu da odbaci zahteve koji ne donose stvarnu vrednost biznisu. Glavna veština postaje znati šta ne treba graditi.
Kada je kod jeftin, održavanje postaje najskuplje
Jedan agent za jedno popodne može da izgeneriše 20.000 novih linija softvera. Pravo pitanje je: ko će to održavati sledećih pet godina?
Svaka nova linija koda povećava površinu za potencijalne napade, usložnjava bazu, zahteva dodatne testove i traži vreme budućih inženjera da je razumeju. Zato je vrhunski inženjer danas onaj koji zadatak reši sa 200 linija jasnog koda, ili još bolje, onaj koji dokaže da se problem može rešiti pametnijom konfiguracijom postojećeg sistema, bez kucanja ijedne nove linije.
U modernom razvoju, kod koji niste morali da napišete jeste vaš najvredniji kod.
Kalibrisano poverenje i bezbednosni rizici (Shadow AI)
Rezultati istraživanja u industriji jasno pokazuju da programeri zadržavaju zdravu dozu skepticizma. Poverenje u veštačku inteligenciju ne sme biti apsolutno, već kalibrisano prema vrsti posla:
-
Visoko poverenje: dopunjavanje koda, pisanje jednostavnih skripti i generisanje mock podataka.
-
Umereno poverenje: standardni jedinični testovi i refaktorisanje izolovanih modula.
-
Nisko poverenje: kompleksne migracije, bezbednosna arhitektura, kriptografski protokoli i finansijska logika.
Pored toga, kompanije se suočavaju sa ozbiljnim problemom „Shadow AI“ fenomena, gde zaposleni na svoju ruku instaliraju razne agente i daju im neograničen pristup internim repozitorijumima, lozinkama i poslovnim bazama.
Agilni tim mora postaviti striktan okvir: tačno se mora znati koji su alati odobreni, kakve nivoe privilegija poseduju i gde prestaje njihovo pravo samostalnog delovanja. Princip najmanjih privilegija (Least Privilege) za softverske agente mora biti postavljen još rigoroznije nego za same zaposlene.
Isti principi važe i van čistog softverskog inženjeringa. Na primer, agencija Joombooz kroz automatizaciju poslovnih procesa i primenu AI rešenja rutinske i ponavljajuće zadatke prepušta automatizovanim sistemima, dok ljude usmerava ka kreativnim procenama, strategiji i odlukama koje zahtevaju duboki kontekst. Reč je o istom modelu raspodele rada, samo primenjenom na celokupno poslovanje.
Budućnost programerske profesije
Programeri koji svoj posao vide isključivo kao pretvaranje tuđeg detaljnog zahteva u gomilu rutinskog koda suočiće se sa ozbiljnim problemima na tržištu rada. Taj segment posla mašine već sada obavljaju brže i jeftinije.
Međutim, inženjeri koji razumeju širu sliku – koji umeju da razlože nejasan problem, procene tehničke rizike, orkestriraju rad više agenata i donesu zrelu odluku o arhitekturi – postaće uticajniji nego ikada pre.
Digitalni kolega neće ići sa vama na pauzu i neće se raspravljati na retrospektivi. Ali će pisati kod dok vi spavate, pripremati analize dok ste na sastanku i generisati stotine testova u minuti.
Naš zadatak nije da se sa njim takmičimo u brzini kucanja. Naš zadatak je da budemo bolji u onome što tehnologija ne poseduje: u inženjerskom rasuđivanju, preuzimanju odgovornosti i donošenju odluka koje softver čine zaista korisnim za stvarni svet.
Često postavljana pitanja (FAQ)
Šta zapravo znači pojam „AI kolega“ u razvoju softvera?
To je termin koji opisuje autonomne AI sisteme (agente) koji ne čekaju samo pojedinačna pitanja u čet prozoru, već samostalno preuzimaju zadatke, planiraju korake, menjaju kod kroz više fajlova, pokreću testove i pripremaju rad za ljudsku proveru.
Koja je suštinska razlika između AI asistenta i AI agenta?
Asistent je reaktivan alat koji pomaže programeru oko trenutne radnje (na primer, dopunjava funkciju). Agent je proaktivan sistem koji dobija krajnji cilj i poseduje autonomiju da koristi alate, pretražuje repozitorijum i izvršava složeni niz akcija kroz ceo radni tok.
Da li inženjeri danas zaista veruju rezultatima koje AI nudi?
Poverenje je znatno niže od stepena upotrebe. Iako ogromna većina inženjera koristi ove alate, istraživanja poput Stack Overflow ankete pokazuju da skoro polovina programera sumnja u tačnost generisanih rešenja, a kao najveću manu navode kod koji na prvi pogled deluje tačno, ali sadrži suptilne greške.
Da li će veštačka inteligencija zameniti programere?
Neće ih zameniti, ali će dramatično transformisati njihov rad. Rutinsko kucanje koda se automatizuje, dok inženjerska procena, definisanje problema, dizajn arhitekture, bezbednost i validacija postaju centralni deo posla.
Šta podrazumeva Context Engineering?
To je inženjerska disciplina strukturiranja informacija koje se prosleđuju AI modelu: od arhitektonskih pravila i internih standarda kodiranja, preko dokumentacije i kataloga servisa, do tačnih opisa poslovnih procesa. Bez dobrog konteksta, čak i najnapredniji modeli daju neupotrebljive rezultate.
Kako GitHub Copilot koristi agentske mogućnosti u pregledu koda?
Copilot Code Review može samostalno da analizira promene unutar Pull Request-a uzimajući u obzir kontekst celog projekta, pravila repozitorijuma i povezane baze znanja, nudeći konkretne predloge za popravke pre nego što kod stigne do ljudskog pregleda.
Može li AI model samostalno da odobri puštanje koda u produkciju?
Alati poput GitHub-a testiraju mogućnosti automatskog odobravanja određenih vrsta promena u strogo kontrolisanim uslovima, ali opšta bezbednosna praksa i dalje nalaže da konačnu reč za promene koje nose poslovni i tehnički rizik mora dati čovek.
Kako ova promena utiče na inženjere početnike (juniore)?
Postoji opasnost od usporavanja profesionalnog razvoja ako juniori samo nekritički prihvataju generisana rešenja. Mentorski rad se mora promeniti tako da se fokus stavi na razumevanje koda, analizu zašto je model izabrao određeno rešenje i pronalaženje skrivenih graničnih slučajeva.
Šta označava termin Human-in-the-Loop u praksi?
To je bezbednosni princip prema kome čovek zadržava kontrolu nad ključnim odlukama. Međutim, on ima smisla samo ako inženjer ima dovoljno vremena i znanja da se zaista udubi u generisano rešenje, a ne da samo mehanički potpisuje zahteve.
Kako AI menja agilne ceremonije poput Sprint Planning-a i Daily Scrum-a?
Planiranje kapaciteta više se ne meri samo radnim satima programera, već sposobnošću tima da obradi, pregleda i testira sav generisani rad. Sastanci postaju fokusirani na koordinaciju hibridnog sistema u kome zadatke paralelno izvršavaju i inženjeri i autonomni agenti.
Šta je „Shadow AI“ i zašto predstavlja bezbednosnu pretnju?
To je nekontrolisana upotreba neodobrenih AI alata unutar kompanije. Najveći rizik nastaje kada zaposleni u javne alate unesu osetljivi izvorni kod, baze podataka klijenata ili API ključeve, čime direktno kompromituju bezbednost čitave organizacije.
Koja je najvažnija inženjerska veština u eri AI agenata?
To je bez sumnje inženjerska procena (Engineering Judgment) – sposobnost da sagledate širi kontekst sistema, prepoznate bezbednosne i operativne rizike i donesete nepogrešivu odluku o tome kada predlog veštačke inteligencije treba prihvatiti, kada prepraviti, a kada u potpunosti odbaciti.
