AI-native Software Development: kako izgleda Agile kada je AI ugrađen u ceo razvojni ciklus

Ključne teze (Key Takeaways) – šta je najbitnije u ovom tekstu

AI-native Software Development nije isto što i korišćenje GitHub Copilot-a, ChatGPT-a ili nekog drugog AI Coding Assistant-a dok programiramo. Razlika je mnogo dublja.

Kod klasičnog AI-assisted razvoja čovek vodi proces, a AI povremeno pomaže: završava funkciju, objašnjava grešku, generiše test ili predlaže refactoring. Kod AI-native modela, veštačka inteligencija je ugrađena u gotovo čitav Software Development Life Cycle – SDLC (životni ciklus razvoja softvera):

Product Discovery,
analizu zahteva,
Backlog,
Planning,
arhitekturu,
programiranje,
testiranje,
Code Review,
CI/CD,
Deployment,
dokumentaciju,
Observability,
Incident Management,
analizu korisničkog Feedback-a.

To nije teorijski pravac. Atlassian svoj Rovo Dev već opisuje kao AI sistem koji radi kroz planiranje, generisanje koda i Code Review, povezujući informacije iz radnih zadataka i repozitorijuma (Atlassian). GitHub Copilot Code Review već koristi Agentic capabilities (agentne sposobnosti) za prikupljanje konteksta iz kompletnog projekta, a može koristiti i MCP servere kako bi tokom Review-a pristupio informacijama iz Issue Tracking-a, dokumentacije, Service Catalog-a i Incident alata (GitHub). Anthropic u svom 2026 Agentic Coding Trends Report-u ovu promenu opisuje još direktnije: softverski razvoj se pomera od pisanja koda prema orkestriranju agenata koji pišu kod (orchestrating agents that write code) (Anthropic).

Ali postoji kvaka: AI može ubrzati svaki pojedinačni korak razvoja, ali to ne znači da je automatski ubrzao sistem. DORA je u istraživanju State of AI-assisted Software Development 2025 zaključila da AI prvenstveno deluje kao pojačivač (Amplifier): dobre organizacione sposobnosti postaju bolje, ali se postojeće slabosti takođe mogu pojačati. Najveći povrat od AI ulaganja zato ne dolazi samo iz alata, već iz kvaliteta sistema u kojem se ti alati koriste (DORA).

I tu AI-native Software Development postaje mnogo zanimljiviji od pitanja koliko AI ubrzava pojedinačnog developera. Pravo pitanje glasi: kako treba da izgleda organizacija kada AI više nije alat pojedinca, već sastavni deo sistema kojim nastaje softver?

Prva faza bila je: AI mi pomaže da programiram

Sećamo se prvih masovnih AI Coding Assistant-a: počnete liniju, AI je završi; napišete komentar, model predloži funkciju; pitate zašto nešto ne radi, AI ponudi objašnjenje. Bilo je impresivno, ali konceptualno se nije promenilo mnogo. Developer je i dalje samostalno dobijao zadatak, analizirao problem, planirao rešenje, pisao kod, pokretao testove i otvarao Pull Request. AI je bio samo pametniji alat unutar postojećeg toka rada (Workflow). To je AI-assisted Development.

AI-native razvoj počinje kada više ne dodajemo AI postojećem procesu, već proces redizajniramo pod pretpostavkom da je AI stalno dostupan. To je ista razlika kao između preduzeća koje kaže „imamo veb-sajt“ i kompanije čiji je celokupan poslovni model „digital-native“. Tehnologija više nije eksterni dodatak – ona postaje sastavni deo arhitekture poslovanja.

Druga faza: dajte agentu zadatak, ne pitanje

Agentic AI menja osnovni odnos između čoveka i softvera. Klasični Chatbot pasivno čeka pitanje, dok agent dobija cilj. Na primer: „Implementiraj ovaj Jira Issue.“

AI sada može samostalno da:

pročita zahtev,
pronađe relevantne delove koda u repozitorijumu,
analizira zavisnosti (Dependencies),
napravi plan rada,
izmeni više fajlova istovremeno,
napiše prateće testove,
pokrene testove u okruženju,
uoči grešku i samostalno promeni rešenje,
pripremi gotov Pull Request.

Ne govorimo više samo o pomoći pri pisanju koda, već o delegiranju izvršenja. Atlassian Rovo Dev danas upravo tako povezuje Code Planning, Code Generation i Code Review, uz korišćenje konteksta iz Jira-e i drugih delova Atlassian ekosistema (Atlassian). To menja sve, jer ako agent dobija zadatak direktno iz Product sistema, AI više ne sedi samo u razvojnom okruženju (IDE) – on ulazi direktno u proces između produktnog menadžmenta i inženjeringa.

AI-native SDLC počinje pre prve linije koda

Mnogi diskusiju o razvoju uz AI svode isključivo na pitanje koliko dobro AI piše kod. To je samo jedan deo problema. Pre samog programiranja postavlja se ključno pitanje: šta uopšte treba napraviti?

AI može kontinuirano analizirati:

povratne informacije korisnika (Customer Feedback),
tikete tehničke podrške,
analitiku ponašanja u aplikaciji,
telemetriju i podatke o incidentima,
Product Backlog,
tehničku dokumentaciju,
istorijat prethodnih Sprintova.

Model može grupisati probleme, pronaći skrivene obrasce, predložiti kriterijume prihvatljivosti (Acceptance Criteria), ukazati na konfliktne zahteve i pripremiti prvi nacrt specifikacije. To ne znači da AI treba samostalno da donosi odluke o strategiji proizvoda, ali znači da veliki deo analitičkog i informacionog rada pre samog kodiranja može biti automatizovan. Product Owner ili Product Manager više ne počinje od praznog ekrana – dobija gotovu početnu analizu, pri čemu njegovo glavno pitanje postaje procena da li je ta analiza zaista ispravna.

Backlog budućnosti neće biti samo lista zadataka

U AI-native timu stavka iz Backloga (Backlog Item) moraće da sadrži znatno više konteksta nego ranije. Čovek može usput da pita kolegu za stolom šta je tačno mislio pod određenom stavkom, ali AI agent ne sme da zavisi od usmenih pojašnjenja.

Zato kvalitetno definisan zadatak mora precizno postaviti:

poslovni cilj,
kriterijume prihvatljivosti (Acceptance Criteria),
sistemska ograničenja,
relevantnu dokumentaciju,
bezbednosne zahteve,
dozvoljene sisteme i biblioteke,
eksplicitno zabranjene akcije,
dodeljeni nivo autonomije.

Loš zadatak, poput „Poboljšati login“, otvara haos: da li to znači brži odziv, viši nivo bezbednosti, redizajn interfejsa, uvođenje Social Login-a ili biometriju? AI može vrlo brzo nešto napraviti, ali to verovatno neće biti ono što je sistemu zaista potrebno. AI-native razvoj zato paradoksalno povećava vrednost jasnog konteksta: što implementacija postaje jeftinija, kvalitet specifikacije postaje relativno vredniji.

Prompt Engineering nije dovoljan – dolazi Context Engineering

U ranoj fazi generativne AI mnogo se govorilo o inženjeringu promptova (Prompt Engineering) i tome kako napisati bolju instrukciju. To jeste korisno, ali u ozbiljnom AI-native razvoju presudno pitanje postaje šta model tačno zna u trenutku kada dobije instrukciju:

kontekst repozitorijuma (Repository Context),
arhitektonske odluke (Architecture Decision Records – ADR),
standarde kodiranja (Coding Standards),
bezbednosne smernice (Security Policies),
zahteve proizvoda (Product Requirements),
istorijat incidenata,
API dokumentaciju,
vlasništvo nad servisima (Service Ownership),
poslovna pravila (Business Rules).

GitHub Code Review danas već koristi Repository Instructions, Agent Skills i MCP servere kako bi u proces pregleda koda automatski uključio informacije iz drugih internih sistema (GitHub). To jasno pokazuje pravac: sledeća velika konkurentska prednost timova neće biti posedovanje najnaprednijeg modela na tržištu, već činjenica da njihov AI raspolaže najboljim organizacionim kontekstom.

AI-native razvoj tera kompaniju da konačno dokumentuje ono što „samo Milan zna“

Svaka ozbiljna IT organizacija ima svog Milana, Petra ili Jelenu. Na pitanje zašto sistem funkcioniše na određeni način, odgovor je redovno: „Pitaj Milana.“ Zašto ovu tabelu u bazi ne smemo da diramo? „Milan zna.“ Zašto servis koristi čudan obrazac? „Duga priča, pitaj Milana.“

To je bio problem i bez veštačke inteligencije, ali sa AI agentima postaje fatalan. Agent ne može da pročita znanje koje postoji isključivo u glavi jednog senior inženjera. Ako organizacija želi da automatizuje delove razvoja, moraće implicitno znanje da prevede u eksplicitno:

kroz ažurnu dokumentaciju,
kroz ADR zapise,
kroz jasne inženjerske politike,
kroz mašinski čitljiva pravila,
kroz standardizovane kataloge servisa (Service Catalogs).

Paradoksalno, AI će naterati kompanije da konačno uvedu red u sopstveno znanje.

Planning se menja kada kod više nije glavno ograničenje

Klasičan Sprint Planning tradicionalno polazi od kapaciteta inženjera: imamo šest programera, jedan je odsutan, koliko zadataka možemo da završimo? Ali šta se dešava kada tih šest programera dobije na raspolaganje deset autonomnih Coding agenata?

Kapacitet više nije jednostavna računica. AI agenti mogu paralelno pripremiti pet implementacija, ali inženjerski tim u istom periodu može detaljno da pregleda samo dve. U tom trenutku pisanje koda prestaje da bude usko grlo, a novo usko grlo postaju kapacitet revizije (Review Capacity), QA testiranje, bezbednosne provere ili donošenje produktnih odluka.

Planiranje sprinta zato više ne postavlja pitanje: „Koliko koda možemo da napišemo?“, već: „Koliko promena sistem može bezbedno da apsorbuje?“ To je neuporedivo zreliji pokazatelj kapaciteta.

Velocity postaje još problematičnija metrika

Ako je brzina tima (Velocity) bila problematična dok su kod pisali isključivo ljudi, situacija postaje apsurdna kada implementaciju preuzmu agenti. Tim je prošlog meseca isporučivao 80 Story bodova, a uvođenjem agenata taj broj skoči na 150. Da li je tim time postao dvostruko produktivniji?

Ne znamo:

Da li korisnici dobijaju više stvarne vrednosti?
Da li je kvalitet koda porastao ili opao?
Da li je skočila stopa neuspešnih promena (Change Failure Rate)?
Koliko radnog vremena odlazi na naporan Review?
Koliki procenat AI-generisanog koda mora naknadno da se refaktoriše?

DORA iz tog razloga izričito upozorava da se uticaj veštačke inteligencije mora posmatrati na nivou celokupnog organizacionog sistema, a ne kroz izolovanu, lokalnu brzinu developera (DORA).

AI-native Agile moraće više da meri Flow, manje Activity

U AI-native okruženju suočićemo se sa eksplozijom aktivnosti: generisani kod, gomile Pull Requestova, automatizovani testovi, dokumentacija, pokretanja agenata, ponovljeni pokušaji i komentari. Međutim, puka aktivnost (Activity) nije isto što i stvarni ishod (Outcome).

Daleko korisnije postaju metrike toka (Flow):

Lead Time i Cycle Time,
učestalost deploymenta (Deployment Frequency),
stopa neuspešnih promena (Change Failure Rate),
vreme oporavka od incidenta (Recovery Time),
vreme čekanja u redu za pregled (Review Queue Time),
stopa ponovnih pokušaja agenta (Agent Retry Rate),
učestalost ljudskih intervencija (Human Intervention Rate),
obim dorade (Rework),
stopa propuštenih defekata (Defect Escape Rate),
cena po prihvaćenoj promeni (Cost per Accepted Change).

Ali ni same metrike toka nisu dovoljne ukoliko na kraju ne daju odgovor na ključna pitanja: da li je korisnik dobio bolji proizvod i da li kompanija ostvaruje bolji poslovni rezultat? AI dramatično povećava obim rada (Output), a agilni pristup mora sprečiti organizaciju da taj obim pomeša sa stvarnom vrednošću (Outcome).

Coding više nije jedina stvar koju AI radi

Rovo Dev već uveliko objedinjuje planiranje koda, generisanje i reviziju (Atlassian). GitHub Copilot Code Review koristi širi kontekst projekta, nudi različite nivoe dubine analize i agentne funkcije za automatsku primenu ispravki. Pri tome, sam GitHub eksplicitno upozorava da Copilot Review ne garantuje pronalaženje svih grešaka i preporučuje da se povratne informacije pažljivo validiraju uz obavezan ljudski pregled (GitHub).

To je ključna tačka razumevanja: AI-native model ne znači automatizaciju po svaku cenu. Zreo inženjerski sistem mora jasno da razgraniči:

šta AI obavlja potpuno samostalno,
šta AI priprema i predlaže,
šta čovek obavezno proverava,
šta isključivo čovek ima pravo da formalno odobri.

Code Review se pretvara u višeslojni sistem kontrole

Na ITNetwork-u smo detaljno obradili ovu temu u tekstu „Da li Code Review ima smisla ako AI piše kod, a drugi AI ga proverava?“. U AI-native razvojnom ciklusu pregled koda više ne predstavlja jednostavan pravolinijski proces u kom programer pošalje kod kolegi koji klikne Merge.

Umesto toga, uspostavlja se strukturirani Review Pipeline:

Coding Agent -> Automatski testovi -> Statička analiza -> AI Code Review -> Bezbednosni skener -> Klasifikacija rizika -> Ljudski pregled (gde je potreban) -> Merge.

Ljudska pažnja se više ne troši ravnomerno na sve promene: ispravka slovne greške i rutinski testovi ne nose isti nivo rizika kao promene u autentifikaciji, platnom prometu, enkripciji, obradi ličnih podataka (PII) ili kritičnoj infrastrukturi. Zato AI-native tim mora primenjivati automatizaciju zasnovanu na riziku (Risk-Based Automation): što je potencijalni opseg štete (Blast Radius) veći, to je dozvoljeni nivo autonomije agenta manji.

Testiranje može postati gotovo kontinuirano – ali postoji opasna zamka

AI može generisati testove u deliću sekunde. Međutim, ukoliko je isti model pogrešno protumačio poslovni zahtev, napisao implementaciju na osnovu te zablude, a zatim generisao testove koji potvrđuju to isto iskrivljeno tumačenje – dobićemo potpuno zelene testove za potpuno pogrešan proizvod.

To stvara zatvorenu epistemološku petlju. AI-native razvoj zato zahteva nezavisne kontrolne mehanizme:

kriterijume prihvatljivosti definisane van implementacionog agenta,
testiranje zasnovano na svojstvima (Property-Based Testing),
ugovorno testiranje (Contract Tests),
rigorozno bezbednosno testiranje,
opservabilnost u produkciji,
povratne informacije stvarnih korisnika.

Test koji uspešno prolazi nije dokaz da pravimo pravu stvar – on dokazuje samo da sistem radi ono što je sam test definisao kao očekivano.

CI/CD u AI-native timu prestaje da bude samo automatizacija Deployment-a

CI/CD cevovod postaje primarna bezbednosna granica između onoga što AI može da proizvede i onoga što zaista sme da stigne do krajnjeg korisnika.

Pipeline automatski validira testove, kvalitet koda, zavisnosti, bezbednost, performanse, usklađenost sa propisima i interne politike. AI agent može pripremiti kompletan deployment, ali to ne znači da ima pravo da ga samostalno pusti u svako okruženje. Interni test servis može imati visok nivo autonomije, dok produkcioni bankarski sistem zahteva sasvim drugačiji nivo kontrole. AI-native podrazumeva automatizaciju po dizajnu (Automation by Design), ali nikako odsustvo upravljanja (Governance).

Deployment može biti brži od ljudske sposobnosti da razume šta je Deploy-ovano

Kada agenti mogu u kratkom roku da proizvedu i spoje ogroman broj promena, inženjerski tim rizikuje da izgubi mentalni model nad sopstvenim sistemom:

„Šta je tačno pušteno u produkciju jutros?“

„Sedamnaest PR-ova koje su generisali agenti.“

„Ko u timu dubinski razume te promene?“

Tišina.

To je alarmantan signal. Razvoj softvera nije samo fabrička proizvodnja izmena, već kontinuirano održavanje kolektivnog razumevanja sistema. Kada brzina izmena raste brže od sposobnosti tima da održi mentalni model arhitekture, nastaje kognitivni dug (Cognitive Debt). Dok tehnički dug (Technical Debt) znači da je sistem težak za menjanje, kognitivni dug znači da ga ljudi više ne razumeju dovoljno dobro da bi mogli da garantuju njegovu stabilnost. Zrele organizacije moraće da mere oba parametra.

Observability postaje Feedback za ljude i agente

Tradicionalno, opservabilnost pomaže inženjerima da razumeju ponašanje sistema u produkciji, lociraju problem i dijagnostikuju uzrok incidenta. U AI-native sistemu te iste podatke u realnom vremenu koristi i agent:

registruje skok stope grešaka (Error Rate),
uočava degradaciju baze podataka ili novi sistemski izuzetak (Exception),
povezuje incident sa konkretnim commit-om koji ga je izazvao,
samostalno predlaže vraćanje unazad (Rollback),
priprema privremenu zakrpu (Patch) koju čovek odobrava.

Time se razvojni krug u potpunosti zatvara:

Zahtev -> Kod -> Test -> Deploy -> Praćenje (Observe) -> Učenje (Learn) -> Izmena.

AI je prisutan u svakoj pojedinačnoj tački ovog toka, što predstavlja suštinsku definiciju AI-native SDLC-a.

Agile tada prestaje da bude prvenstveno način organizovanja rada ljudi

Agile prerasta u operativni sistem za upravljanje petljama povratnih informacija (Feedback Loops).

Daily Scrum sastanak gubi smisao ako se svede na to da šest inženjera prepričava šta su radili juče. Ako AI kontrolna tabla pre početka sastanka već prikazuje koji zadatak kasni, gde postoji međutimska zavisnost, koji Pull Request čeka u redu i koji integracioni test pada, statusno izveštavanje postaje suvišno. Daily Scrum se tada vraća svojoj izvornoj svrsi: brzoj inspekciji napretka ka cilju sprinta (Sprint Goal) i taktičkom prilagođavanju plana. AI priprema tačan kontekst, a ljudi donose odluke.

Isti princip važi i za Retrospektivu. AI može u sekundi analizirati Cycle Time, incidente, zastoje u pregledu koda, greške agenata, rad u toku i obim dorade. Međutim, otvoreni razgovor o tome zašto se ljudi ustežu da eskaliraju problem, zašto timovi ne sarađuju dovoljno blisko ili zašto menadžment iznenada menja prioritete nije problem analize podataka. AI donosi precizne podatke na sto, ali ne može samostalno popraviti organizacionu kulturu.

Product Owner dobija digitalni Research tim koji nikada ne spava

Zamislimo AI koji neprekidno analizira tikete podrške, recenzije korisnika, analitiku ponašanja, beleške prodajnog tima, korišćenje novih funkcionalnosti i razloge za odlazak korisnika (Churn). Svakog jutra Product Owner dobija sažetak:

„Tri konkretna problema beleže značajan rast u poslednja 24 sata.“
„Novu opciju koristi svega 4% aktivnih korisnika.“
„Korisnici iz segmenta X masovno traže istu integraciju.“

Ovo višestruko podiže nivo produktne inteligencije, ali sa sobom nosi i zamku: ukoliko Product Owner prestane da direktno razgovara sa korisnicima pod izgovorom da „AI već analizira podatke“, dobijamo loš sistem. Podaci nisu zamena za empatiju prema korisniku; model prepoznaje statističke obrasce u informacijama koje ima, ali ne može videti ono što niko u sistemu nije izmerio.

Scrum Master ili Agile Coach postaje dizajner Human-AI sistema rada

Kada AI automatizuje izradu statusnih izveštaja, sažetke sastanaka, analizu toka rada, detekciju zavisnosti i pripremu metrika za retrospektivu, administrativna dimenzija uloge Scrum Mastera u potpunosti gubi vrednost.

To nije pretnja, već konačno oslobađanje: Scrum Master nikada nije ni trebalo da bude administrativni zapisničar tima. Njegova stvarna vrednost u AI-native organizaciji pomera se prema:

sistemskom razmišljanju (Systems Thinking),
mentorskom radu i coachingu,
optimizaciji protoka (Flow Optimization),
vođenju organizacionih promena,
upravljanju veštačkom inteligencijom (AI Governance),
definisanju granica odgovornosti između ljudi i agenata,
unapređenju petlji povratnih informacija.

To znači znatno manje zakazivanja sastanaka, a znatno više inženjerskog dizajniranja celokupnog radnog sistema.

Developer više nije samo osoba koja pretvara zahtev u kod

Anthropic u svom izveštaju 2026 Agentic Coding Trends Report naglašava prelazak sa manuelnog pisanja koda na orkestriranje agenata (Anthropic). To iz korena menja profil veština savremenog inženjera:

Znatno manje vremena odlazi na: šablonski kod (Boilerplate), rutinske jedinične testove, bazične CRUD operacije i manuelno pisanje tehničke dokumentacije.
Fokus se seli na: precizno definisanje problema (Problem Framing), softversku arhitekturu, inženjering konteksta (Context Engineering), orkestraciju agenata, napredni Code Review, debagovanje kompleksnih stanja, procenu rizika i duboko poznavanje poslovnog domena.

To nipošto ne znači da inženjersko znanje gubi na značaju. Naprotiv: da biste merodavno pregledali i odobrili kod koji je generisao agent, morate posedovati dovoljno duboko znanje da prepoznate suptilne greške koje mašina pravi. AI smanjuje potrebu za pukim kucanjem koda, ali podiže vrednost vrhunske inženjerske procene.

Najveći problem imaju juniori

Ako AI agenti u potpunosti preuzmu jednostavne bagove, pisanje testova, ažuriranje dokumentacije i male funkcionalnosti, postavlja se pitanje šta ostaje junior inženjerima za praksu. Upravo su ti zadaci decenijama predstavljali poligon na kom su se sticala iskustva. Senior inženjer nije postao senior čitanjem priručnika, već prolaskom kroz hiljade sitnih grešaka i praktičnih odluka.

AI-native organizacija zato mora svesno da osmisli novi obrazovni put za ljude: junior treba da koristi AI, ali istovremeno mora da:

čita i analizira generisani rezultat,
ume da objasni logiku iza implementacije,
samostalno modifikuje kod,
razume zašto je određena arhitektonska odluka dobra ili loša.

Najgori mogući scenario jeste model u kom junior napiše prompt, agent izgeneriše kod, drugi AI odobri rešenje, a junior samo klikne Merge. Produktivnost u takvom scenariju kratkoročno raste, ali inženjerska kompetencija dugoročno nepovratno propada.

To je Cognitive Outsourcing problem

Ljudska civilizacija je odavno prepustila pamćenje telefonskim imenicima i pretraživačima, navigaciju GPS uređajima, a računanje kalkulatorima. To je uglavnom bilo racionalno. Međutim, kada eksternalizujemo bazičnu kognitivnu veštinu, naš lični kapacitet neminovno atrofira.

Ako inženjer godinama ne mora samostalno da debaguje kompleksne probleme, projektuje baze, piše logiku i testira rubne slučajeve, koliko će biti sposoban da interveniše kada AI pogreši na problemu za koji nema dovoljno konteksta u podacima? AI-native razvoj mora planski da održava ljudsku ekspertizu: ponekad je brže pustiti model da odradi posao, ali je organizaciono zdravije da čovek zadrži potpuno razumevanje procesa.

Dokumentacija postaje deo izvršnog sistema, a ne mrtva arhiva

U mnogim kompanijama tehnička dokumentacija izgleda porazno: interni viki poslednji put je ažuriran pre dve godine, README datoteka potiče iz 2021, a dijagram arhitekture nema dodirnih tačaka sa realnim stanjem u produkciji.

AI agent koji zavisi od takvih informacija donosiće katastrofalne odluke. Zato AI-native razvoj drastično podiže cenu zastarele dokumentacije: ona prestaje da bude pasivna arhiva i postaje mašinski čitljiv operativni kontekst (Machine-Consumable Operational Context). Ako je dokumentacija loša, agent pravi loš softver. Održavanje dokumentacije time prestaje da bude dosadan administrativni zadatak i postaje direktan faktor kvaliteta automatizovanog razvoja.

MCP i slični standardi mogu postati vezivno tkivo AI-native SDLC-a

Model Context Protocol (MCP) omogućava jezičkim modelima i autonomnim agentima standardizovan, bezbedan pristup spoljnim alatima i izvorima informacija.

U razvoju softvera to znači da AI ne mora da bude ograničen samo na Git repozitorijum, već uz odgovarajuće dozvole može pristupati:

sistemima za praćenje zadataka (Issue Trackers),
internoj dokumentaciji,
katalozima mikroservisa,
platformama za upravljanje incidentima,
alatima za testiranje,
bazama telemetrije.

GitHub već omogućava integraciju MCP servera unutar Copilot Code Review procesa radi obezbeđivanja dodatnog konteksta (GitHub). Model bez konteksta nudi generičke odgovore; agent uvezan u poslovne sisteme donosi kontekstualno precizne odluke. Međutim, pristup većem broju sistema otvara ozbiljna bezbednosna pitanja.

AI-native znači da Identity & Access Management više nije samo za ljude

Kada Coding Agent dobije sopstveni nalog u sistemu, moraju se postaviti jasne granice: koja tačno prava ima? Da li sme da čita produkcione tajne (Secrets)? Sme li da menja konfiguraciju infrastrukture (Infrastructure-as-Code)? Može li samostalno da otvori PR, odobri merge, pokrene deployment ili obriše podatke iz baze?

Uvođenje desetina ili stotina agenata otvara potpuno novi IAM izazov, gde mora važiti striktan princip najmanjih privilegija (Least Privilege):

agent koji piše dokumentaciju nema razloga da pristupa produkciji;
agent koji analizira incidente ne mora imati pravo da samostalno izvršava sanaciju.

Nivo autonomije i prava pristupa moraju biti direktno proporcionalni potencijalnom riziku.

Shadow AI bi mogao biti gori od Shadow IT-a

Nekadašnji problem „Shadow IT-a“ nastajao je kada zaposleni na svoju ruku počnu da koriste neodobrene SaaS aplikacije. „Shadow AI“ nosi znatno veću opasnost: programer samoinicijativno instalira lokalnog agenta i dodeli mu neograničen pristup izvornom kodu, internoj dokumentaciji, API ključevima i produkcionim kredencijalima, a da kompanija nema nikakvu svest o tome.

Ozbiljan Enterprise AI-native razvoj ne može se svesti na to da menadžment kaže zaposlenima da slobodno koriste veštačku inteligenciju. Neophodno je uspostaviti:

listu odobrenih alata,
jasne politike rukovanja podacima,
revizorske zapise (Audit Logs),
precizne modele dozvola,
upravljanje modelima (Model Governance),
bezbednosne kapije i pravila.

To je prvorazredno inženjersko pitanje, a ne samo tema za pravnu službu.

AI-native ne znači da svaki korak mora biti AI

Organizacije lako upadnu u zamku tehnološkog maksimalizma pod parolom: „Ako može da se uradi preko AI-ja, neka ga radi AI.“ Ako je deterministički alat brži i pouzdaniji, treba koristiti njega:

kompajler ne treba zamenjivati jezičkim modelom;
statički analizator koda ima jasnu, egzaktnu funkciju;
jedinični test treba da ostane strogi jedinični test.

Veštačku inteligenciju treba primenjivati tamo gde ona donosi stvarnu dodatu vrednost: u interpretaciji zahteva, analizi obrazaca, generisanju koda, uvezivanju konteksta i radu sa nedovoljno definisanim problemima. Tamo gde postoji jeftiniji i pouzdaniji deterministički mehanizam, veštačka inteligencija je suvišna.

AI-native ne znači AI na svakom mestu, već AI tamo gde unapređuje funkcionisanje sistema.

Isti princip važi za ljude

Podjednako je važno razumeti da ne treba svaki ljudski zadatak automatizovati. Čovek ima nezamenljivu ulogu u situacijama koje zahtevaju:

tumačenje nejasnih poslovnih i društvenih ciljeva,
pregovaranje među stranama sa suprotstavljenim interesima,
procenu etičkih i reputacionih rizika,
donošenje teških strateških kompromisa,
preuzimanje lične i profesionalne odgovornosti.

Najzdraviji AI-native sistem zato nije onaj koji implementira najveći broj AI funkcija, već onaj koji uspostavlja najbolju raspodelu rada između determinističke automatizacije, AI agenata i ljudi.

To je zapravo nova arhitektura rada

Ovu strukturu možemo zamisliti kroz tri komplementarna sloja:

Prvi sloj – Deterministička automatizacija: CI/CD sistemi, automatizovani testovi, linteri, statička analiza i sistemske politike (pravila koja se egzakton proveravaju).
Drugi sloj – Veštačka inteligencija: agenti koji analiziraju zahteve, generišu kod, predlažu arhitekturu, orkestriraju zadatke i prepoznaju skrivene obrasce u podacima.
Treći sloj – Ljudi: inženjeri i lideri koji postavljaju ciljeve, donose rizične odluke, balansiraju kompromise i snose krajnju odgovornost za isporučeni proizvod.

Problem u praksi nastaje kada se ovi slojevi pobrkaju: LLM ne sme služiti kao zamena za strogu verifikaciju pravila, niti skup ljudski mozak treba trošiti na ono što deterministička automatizacija može bez greške ponoviti hiljadu puta.

Budući Sprint možda neće biti ograničen kapacitetom za kodiranje

Kada pisanje koda prestane da bude usko grlo, postavlja se pitanje šta u praksi ograničava kapacitet jednog sprinta. To mogu biti:

brzina donošenja odluka o proizvodu,
kapacitet pregleda i verifikacije (Review),
dubina testiranja,
validacija od strane stvarnih korisnika,
bezbednosne procene,
deployment procedure,
kapacitet korisnika da smisleno usvoje nove promene.

To iz osnova menja definiciju kapaciteta: sprint više ne postavlja pitanje koliko linija koda tim može da ispiše, već koliko novih hipoteza može kvalitetno da testira u praksi bez degradacije stabilnosti sistema. To je neuporedivo bliže izvornoj filozofiji agilnog razvoja.

AI-native može da vrati Agile njegovoj originalnoj ideji

Ironično, veštačka inteligencija ima potencijal da eliminiše ogroman deo administrativne birokratije koja se godinama taložila oko agilnih metoda: automatsko generisanje statusa, izveštaja, sažetaka sa sastanaka, transkripata, analiza Backloga i praćenje metrika omogućava ljudima da se ponovo posvete onome što je zaista važno – živoj interakciji, povratnim informacijama, kreiranju vrednosti i donošenju odluka.

Agilni manifest nikada nije zagovarao prekomernu administraciju u Jiri, iako je većina korporativnih implementacija završila upravo u toj zamci. AI može uspešno da skine taj teret sa leđa inženjera, pod uslovom da se koristi promišljeno.

Ili može napraviti Agile birokratiju na steroidima

Naravno, postoji i mračniji scenario u kom se tehnologija zloupotrebi za generisanje još većeg broja izveštaja, još agresivnijih metrika, fiktivnih procena, gomilanja menadžerskih kontrolnih tabli i automatizovanog nadzora nad zaposlenima. U tom slučaju ne dobijamo agilnost, već mikromenadžment na steroidima (AI-powered Micromanagement).

Tehnologija sama po sebi nema sopstvenu filozofiju – ona podjednako efikasno može poslužiti za osnaživanje autonomije timova ili za uspostavljanje rigidne centralizovane kontrole. Izbor je uvek na rukovodstvu kompanije.

DORA-ina najvažnija poruka je zato organizaciona

Veštačka inteligencija nije magični štapić koji se može naknadno instalirati preko bilo kog postojećeg stanja u kompaniji. DORA izveštaj za 2025. godinu jasno definiše AI kao pojačivač (Amplifier): najveći povrat investicije dolazi iz zrelih organizacionih praksi, a ne iz samog softverskog alata (DORA).

To znači vrlo jednostavnu jednačinu:

Vrhunski tim + napredan AI = potencijalno superioran sistem rada.
Loš proces + napredan AI = neuporedivo brža proizvodnja loših rezultata.
Loša arhitektura + napredan AI = hiperprodukcija zavisnosti u lošoj arhitekturi.
Slaba pokrivenost testovima + napredan AI = gomilanje koda koji niko ne kontroliše.
Ušančena birokratija + napredan AI = automatizovana birokratija većih razmera.

To je neprijatna, ali lekovita istina koju menadžment mora da prihvati.

AI-native organizacija nije kompanija koja je kupila 500 Copilot licenci

Kupovina licenci za zaposlene je najlakši korak; temeljan redizajn celokupnog toka rada je znatno teži poduhvat. Prava AI-native organizacija mora imati jasne odgovore na strateška pitanja:

Koji se delovi životnog ciklusa softvera automatizuju?
Koji agent raspolaže kojim nivoom pristupa i prava?
Koji organizacioni kontekst se obezbeđuje modelima?
Ko i na koji način verifikuje finalni rezultat?
Kako merimo kvalitet i protok vrednosti?
Kako sistemski čuvamo i prenosimo inženjersko znanje na ljude?
Kako upravljamo bezbednosnim i pravnim rizicima?
Kako štitimo osetljive podatke kompanije?
Kako prilagođavamo uloge u timu?
Kako sprečavamo stihijsko bujanje agenata (Agent Sprawl)?

Bez precizno definisanih odgovora na ova pitanja, kompanija nema AI-native razvoj – ima samo gomilu aktivnih pretplata na softverske alate.

Budućnost možda pripada vrlo malim timovima sa veoma velikim izvršnim kapacitetom

Jedna od najznačajnijih posledica ove transformacije biće pojava kompaktnih inženjerskih jedinica: pet izuzetno stručnih profesionalaca koji uz podršku desetina specijalizovanih agenata, automatizovanih testova, interne razvojne platforme (Platform Engineering) i Continuous Delivery praksi mogu isporučiti obim posla za koji je ranije bila potrebna armija programera.

Međutim, veći obim rada ne garantuje automatski veću vrednost. Takav tim mora posedovati vrhunsku sposobnost u odabiru pravih problema, beskompromisnoj prioritizaciji, očuvanju kvaliteta i upravljanju rizicima. Kada operativno izvršenje pojeftini, odluka o tome šta uopšte treba izvršiti postaje najskuplja stavka.

Najveća buduća IT veština možda neće biti pisanje koda

Najvrednija inženjerska veština u godinama pred nama biće inženjerska procena (Engineering Judgment):

prepoznati kada model nudi suptilno pogrešno rešenje,
znati kada određenu funkcionalnost uopšte ne treba praviti,
uočiti kada jednostavno rešenje vredi više od prekomerno sofisticiranog koda,
proceniti koji je arhitektonski kompromis dugoročno prihvatljiv,
razumeti zašto podatak da kod prolazi sve testove često nije dovoljan dokaz kvaliteta.

To su kompetencije koje se ne mogu izmeriti linijama koda, ali upravo one razdvajaju vrhunski softverski inženjering od puke manufakturne proizvodnje sintakse.

AI-native Software Development zato ne znači smrt Agile-a

Naprotiv, ovo označava njegovu narednu veliku evoluciju. Agilni pokret je nastao kao odgovor na neizvesnost u projektima u kojima je bilo nemoguće unapred predvideti sve detalje. Veštačka inteligencija ne eliminiše tu neizvesnost – ona je višestruko uvećava, jer nam omogućava da brže pravimo promene, brže testiramo pravce, ali i znatno brže pravimo skupe greške.

Zato osnovni agilni principi ostaju kritični:

transparentnost (Transparency),
inspekcija (Inspection),
prilagođavanje (Adaptation),
kratke petlje povratnih informacija (Short Feedback Loops),
rad u malim paketima (Small Batches).

Menja se samo tehnološki sloj koji se nalazi ispod njih. Na ITNetwork-u smo kroz tekst „Od Agile-a do AI-Augmented Agile-a: nova generacija razvoja softvera“ napravili prvi korak ka ovoj temi, pokazujući kako AI ulazi u veći deo SDLC-a dok ljudski tim i dalje diriguje procesom. AI-native razvoj ide korak dalje: on ne pita gde naknadno možemo dodati AI, već postavlja pitanje: kako bismo iz temelja dizajnirali razvoj softvera da smo od prvog dana znali da će inteligentni agenti biti dostupni na svakom koraku?

I odgovor verovatno neće ličiti na današnje timove

Budući razvojni sistemi podrazumevaće znatno manje administrativnih procedura, napredniju automatsku analizu, manje rutinskog koda, veći broj specijalizovanih agenata, automatizovanu reviziju, brže produktne eksperimente i minimalno vreme od ideje do produkcije.

Ali paralelno sa tim, zahtevaće:

rigoroznije upravljanje (Governance),
mašinski čitljivu dokumentaciju,
sveobuhvatnu opservabilnost,
precizne modele prava pristupa,
jasnu podelu odgovornosti,
beskompromisno očuvanje ljudske ekspertize na kritičnim tačkama.

AI-native ne vodi ka organizaciji bez inženjera, već ka organizaciji u kojoj se skupo ljudsko vreme više ne rasipa na zadatke koje mašina može pouzdano da reši. Taj princip poslovne automatizacije odlično je opisan i na Joombooz portalu u tekstu 5 automatizacija koje svaka agencija treba da ima u 2026.: automatizovati rutinske procese kako bi ljudi svoju pažnju, kreativnost i razmišljanje usmerili na poslove koji prave stvarnu razliku. Taj obrazac se direktno preslikava na savremeni softverski inženjering.

Najveća promena možda neće biti to što AI piše kod

Pisanje koda uz pomoć veštačke inteligencije ubrzano postaje uobičajena svakodnevica. Mnogo korenitija promena dogodiće se onog trenutka kada inženjerske organizacije nauče da celokupan sistem poslovanja postave oko jednostavnih činjenica: kod više nije redak resurs, generisanje rešenja više nije usko grlo, a agenti mogu paralelno obavljati stotine operacija.

U tom novom poretku deficitarni postaju:

jasan i precizan kontekst,
stručna inženjerska procena,
fokusirana ljudska pažnja,
lična i profesionalna odgovornost,
duboko razumevanje stvarnih potreba korisnika,
sposobnost donošenja ispravnih odluka.

U tome leži suštinski paradoks ove evolucije: što mašine postaju efikasnije u generisanju softvera, to važnije postaje da ljudi znaju koji softver zaista vredi praviti. Kod može postati besplatan, ali odluka nikada neće biti besplatna; implementacija može trajati jedan sat, ali njene arhitektonske i poslovne posledice mogu trajati čitavu deceniju.

Budućnost softverskog razvoja ne donosi veštačku inteligenciju umesto agilnih metoda, niti donosi agente umesto programera. Ona donosi integrisani ekosistem u kom inženjeri, deterministička automatizacija i autonomni agenti sarađuju unutar jedinstvenog razvojnog lanca. Organizacije koje budu predvodile ovu promenu neće pobediti zato što poseduju najveći broj agenata, već zato što nepogrešivo znaju šta smeju da im povere, šta nikada ne smeju da im prepuste i zašto ljudska odluka i dalje vredi neuporedivo više od hiljadu generisanih linija koda.

FAQ – AI-native Software Development

Šta je AI-native Software Development?

AI-native Software Development je inženjerski pristup u kom je veštačka inteligencija od samog početka projektovana kao integralni deo kompletnog razvojnog ciklusa (SDLC), a ne samo kao prateći alat za dopunu koda.

Koja je razlika između AI-assisted i AI-native razvoja?

Kod AI-assisted modela postojeći proces rada ostaje isti, dok AI služi kao pomoć inženjeru na pojedinačnim zadacima. Kod AI-native modela celokupan tok rada se iz temelja redizajnira pod pretpostavkom stalne dostupnosti agenata i automatizacije u svakoj fazi.

Da li je AI-native isto što i Vibe Coding?

Ne. Vibe Coding označava neformalno oslanjanje na AI alate gde se softver kreira kroz labave instrukcije na prirodnom jeziku. AI-native razvoj predstavlja robustan inženjerski sistem koji obuhvata produktni menadžment, arhitekturu, testiranje, bezbednost, CI/CD, opservabilnost i upravljanje rizikom.

Da li AI agenti već mogu da rade kroz više faza SDLC-a?

Da. Sistemi poput Atlassian Rovo Dev-a već uvezuju faze planiranja, generisanja koda i pregleda kroz jedinstven kontekst, dok savremeni agenti preuzimaju sve složenije autonomne zadatke.

Da li GitHub Copilot može automatski da radi Code Review?

Da. GitHub Copilot Code Review može samostalno pregledati Pull Requestove, koristeći kontekst projekta, instrukcije repozitorijuma i MCP servere, pri čemu GitHub zvanično preporučuje ljudsku validaciju njegovih nalaza.

Šta je Agentic Coding?

Agentic Coding je model u kom AI agent dobija definisan cilj (npr. rešavanje tiketa) i samostalno planira, menja fajlove, pokreće testove i kreira Pull Request, umesto da samo odgovara na izolovane promptove programera.

Da li će developeri prestati da pišu kod?

Manuelno kucanje šablonskog i rutinskog koda se drastično smanjuje, ali duboko inženjersko znanje ostaje presudno za postavljanje arhitekture, verifikaciju rešenja, debagovanje, bezbednost i strateško donošenje odluka.

Kako AI-native razvoj menja Scrum?

Planiranje sprinta prestaje da bude kalkulacija kapaciteta za kucanje koda i fokusira se na kapacitet pregleda (Review Capacity), procenu rizika, protok vrednosti i sposobnost sistema da stabilno apsorbuje promene.

Da li Daily Scrum i dalje ima smisla?

Ima, ali prestaje da bude sastanak za podnošenje statusnih izveštaja. Pošto AI automatski prati napredak i blokere, tim koristi sastanak isključivo za sinhronizaciju oko cilja sprinta i rešavanje sistemskih prepreka.

Kako AI-native razvoj menja Product Owner-a?

Product Owner dobija snažnu analitičku podršku za obradu korisničkih povratnih informacija i Backloga, ali definisanje vizije, strateških prioriteta i poslovne vrednosti ostaje isključiva ljudska odgovornost.

Kako se menja uloga Scrum Master-a?

Rutinski administrativni poslovi bivaju automatizovani, dok se fokus uloge seli na sistemsko razmišljanje, mentorski rad, optimizaciju protoka posla, vođenje organizacionih promena i dizajniranje saradnje između ljudi i agenata.

Šta je Context Engineering?

Context Engineering je inženjerska disciplina strukturiranja informacija, pravila, arhitektonskih zapisa i integracija koje se obezbeđuju AI modelu kako bi on doneo optimalnu odluku unutar konkretnog projektnog okruženja.

Zašto je dokumentacija važnija u AI-native razvoju?

Zato što agenti ne mogu da koriste prećutno znanje koje postoji samo u glavama inženjera. Ažurna tehnička dokumentacija i arhitektonske odluke postaju direktan mašinski čitljiv ulaz za funkcionisanje automatizacije.

Šta je MCP?

Model Context Protocol (MCP) je otvoreni standard koji omogućava AI modelima bezbedno i uniformno povezivanje sa spoljnim alatima, bazama znanja, tiketima i servisnim katalozima.

Koji su najveći Security rizici AI-native razvoja?

Najveće pretnje uključuju dodeljivanje prevelikih privilegija agentima, curenje produkcionih tajni, Prompt Injection napade, trovanje konteksta, neovlašćene izmene u infrastrukturi i nekontrolisano bujanje agenata.

Šta je Agent Sprawl?

Agent Sprawl označava stihijsko umnožavanje specijalizovanih agenata, njihovih prava i međusobnih zavisnosti, što sistem čini netransparentnim i izuzetno teškim za bezbednosno upravljanje.

Da li AI treba da ima Production Access?

Pristup produkciji mora biti strogo ograničen principom najmanjih privilegija, uz obavezne kapije za ljudsko odobrenje i detaljne revizorske zapise. U kritičnim sistemima direktan pristup produkciji je nedopustiv.

Šta je Cognitive Debt?

Kognitivni dug predstavlja postepeni gubitak dubinskog ljudskog razumevanja softverskog sistema koji nastaje kada mašine unose promene brže nego što inženjeri mogu da održe stabilan mentalni model arhitekture.

Kako AI-native razvoj utiče na Junior developere?

Omogućava im znatno brže usvajanje koncepata, ali nosi rizik atrofije inženjerskih veština ako preskoče fazu samostalnog rešavanja problema. Zato organizacije moraju namenski kreirati nove mentorske programe.

Da li AI-native znači potpunu autonomiju AI-ja?

Ne. Zreo inženjerski pristup podrazumeva selektivnu autonomiju zasnovanu na proceni rizika: rutinski poslovi mogu biti potpuno automatizovani, dok visokorizične promene uvek zahtevaju ljudsku kontrolu.

Kako treba meriti AI-native razvoj?

Fokus merenja mora biti na sistemskim metrikama: Lead Time, Cycle Time, stopi stabilnosti produkcije, vremenu revizije koda i stvarnoj vrednosti isporučenoj korisnicima, umesto na broju linija koda ili Story bodovima.

Šta DORA kaže o AI u razvoju softvera?

DORA izveštaj za 2025. godinu ističe da AI deluje kao pojačivač postojećih organizacionih obrazaca: organizacije sa stabilnim inženjerskim praksama beleže rast efikasnosti, dok one sa lošim procesima samo brže proizvode probleme.

Da li je AI-native Software Development sledeća faza Agile-a?

Jeste. Temeljni agilni postulati empirizma i brzog učenja postaju još relevantniji, dok se način tehničke realizacije zadataka u potpunosti transformiše kroz simbiozu ljudi i mašina.

Kako će izgledati AI-native tim budućnosti?

Činiće ga manji broj visokoobučenih inženjera koji orkestriraju flotu specijalizovanih agenata, oslanjajući se na determinističku automatizaciju i samouslužne platforme, gde se skupa ljudska pažnja čuva za strategiju, arhitekturu i etičku odgovornost.