Agencije su groblje za programere: zašto ćete u outsourcing firmi brzo dostići plafon i postati „code monkey“

Počnimo direktno, bez uvijanja u celofan.

Postoji jedan razgovor koji se ponavlja u IT zajednici sa zamornom pravilnošću – u kancelarijama, na konferencijama, u privatnim Slack kanalima i na Reddit nitima u tri ujutro. Razgovor izgleda ovako: developer sa pet ili šest godina iskustva pogleda unazad i shvati da ne zna znatno više nego što je znao sa dve ili tri. Da je u međuvremenu napravio stotine, možda i hiljade tiketa. Da je isporučio desetine projekata. Da su svi klijenti bili zadovoljni. Da je plata solidna, ali nepomerljiva. Da ne može da prođe tehnički intervju u ozbiljnoj produktnoj firmi. Da bi čak bio nesiguran na svom aktuelnom poslu da mu neko postavi pitanje o sistemskom dizajnu, distribuiranim sistemima ili algoritmima izvan onog što svakodnevno pipka.

I onda dolazi pitanje koje treba da boli koliko i boli: Gde su otišle te godine?

Odgovor, u velikom broju slučajeva, glasi: u agenciji.

Ne u svakoj agenciji i ne za svakog developera. Ali dovoljno često, dovoljno predvidivo i dovoljno sistemski da to nije slučajnost ni individualni propust – nego strukturalni problem modela rada koji srpska, i šira regionalna IT industrija u ogromnoj meri prihvata kao normu.

Ovaj tekst je pokušaj da se taj problem imenuje, analizira i razume – bez suvišnog diplomatisanja, ali i bez paušalnog omalovažavanja svih koji rade u agencijama. Jer istina je, kao i obično, nijansiranija od naslova – ali naslov nije ni za jotu pogrešan.

Definicija terena: šta je zapravo „agencija“?

Pre nego što krenemo, moramo biti precizni u terminologiji, jer se pod rečju „agencija“ u srpskom IT kontekstu podrazumeva nekoliko različitih poslovnih modela koji imaju neke zajedničke i neke veoma različite karakteristike.

Tipovi firmi o kojima govorimo

Outsourcing agencija (klasični model): Firma koja prodaje razvoj softvera kao uslugu klijentima koji sami nemaju dovoljno razvojnog kapaciteta. Posao agencije je da isporuči definisanu stvar u definisanom roku za definisanu cenu. Uspeh se meri isporukom, ne kvalitetom koda koji ostaje iza nje. Klijent plaća, projekt se zatvori, tim pređe na sledeći.

Software house (softverska kuća): Varijacija koja zvuči prestižnije, ali u praksi funkcioniše slično. Kompanija ima sopstvenu razvojnu ekipu koja radi projekte za različite klijente. Razlika od klasične agencije uglavnom je u tome što software house obično drži projekte duže i ima dublji inžinjerski kapacitet – ali bazični model je isti: radite na tuđim proizvodima, za tuđe rokove, prema tuđim specifikacijama.

Dedicated team (posvećeni tim): Oblik outsourcinga u kome agencija „pozajmljuje“ tim klijentu na duži rok – mesecima ili godinama. Developeri rade isključivo za jednog klijenta, ali su formalno zaposleni u agenciji. U teoriji ima više kontinuiteta nego na projektnom modelu, ali strukturalna dinamika ostaje ista: vi ste resurs na raspolaganju klijentu, a ne vlasnici produkt strategije.

Consulting firma: Obično se fokusira na specijalizovane oblasti – cloud migracije, data inžinjering, specifični enterprise sistemi. Može nuditi viši nivo tehničke dubine od klasičnog outsourcinga, ali i dalje operira u modelu u kome isporuka klijentu, a ne razvoj sopstvenog znanja, definiše šta radi svaki dan.

Ono što sve ove firme dele – i ono što ih razlikuje od produktnih kompanija – je fundamentalna ekonomska logika: vaše vreme je sirovinski materijal koji se prodaje. Vaš posao je da isporučujete što efikasnije, što jeftinije i što brže. Sve ostalo – kvalitet arhitekture, dubina razumevanja domena, dugoročna tehno­loška vizija – sekundarno je u odnosu na tu jednu metriku.

Code monkey: šta to zapravo znači i zašto reč boli

Termin code monkey je uvredljiv i svestan je toga. Koristimo ga u naslovu upravo zato što pokriva nešto što je eufemizmima teže opisati.

Code monkey je developer koji:

• Prima specifikaciju ili tiket

• Pretvara ga u kod

• Predaje na code review ili direktno u deployment

• Prima sledeći tiket

I to je – sve. Nema razumevanja zašto sistem koji gradi funkcioniše onako kako funkcioniše u dubini. Nema vlasništva nad arhitekturskim odlukama. Nema znanja o poslovnoj logici koja stoji iza feature-a koji implementuje. Nema uvida u to kako će kod koji piše skalirati, kakve bezbednosne implikacije ima, koji tehnički dug ostavlja iza sebe.

Postoji jedna nit na Reddit-u – u subredditu r/cscareerquestions, naslov „Stuck as a code monkey“ (Zapeo kao code monkey) – u kojoj developer opisuje situaciju: više godina iskustva, solidna plata, ali apsolutno nikakvo osećanje rasta. „Osećam se kao da su moje jedine veštine: pišem ono što mi kažu, u formatu koji mi kažu, prema rokovima koje mi kažu“.​

Odgovori u toj niti su brutalno iskušeni: „Promeni posao. Nemaš problem sa veštinama – imaš problem sa sredinom u kojoj radiš.“

Poenta nije u tome da su code monkeyji loši developeri. Poenta je u tome da su ih njihova radna okruženja – sistematski i metodično – pretvorila u code monkeyje, čak i kada su počeli kao nešto što je imalo potencijal da bude daleko više.

Anatomija agencijskog rada: zašto sistem ne funkcioniše za vas

Hajde da budemo konkretni i da pogledamo tačno kako agencijski model rada utiče na karijerni i tehnički razvoj developera.

Pritisak rokova ubija kvalitet i učenje

Ovo je najočigledniji mehanizam, ali ga vredi eksplicitno navesti jer ga mnogi developeri racionalizuju umesto da ga imenuju.

U agencijskom modelu, projekti imaju fiksirane rokove koji su često nerealisti čni. Klijent je dogovorio isporuku do određenog datuma. Agencija se obavezala. Sales tim je obećao. A onda dolazi do klizanja zahteva (scope creep – proširenja opsega rada) i rokovi ostaju, ali posla ima više.

Prema istraživanju objavljenom od strane Harness-a 2024. godine, koje je anketiralo 500 engineering menadžera i developera: 62% developera iskusilo je scope creep sa zahtevima koji se šire tokom projekta, a 23% radi prekovremeno bar 10 dana mesečno.​

Šta se dešava u tim uslovima? Developer koji ima sat vremena da implementira feature nema vremena da:

• Istraži alternativne pristupe

• Napiše porec­ile testove

• Refaktoruje prethodni kod koji je loše napisan

• Postavi pitanje zašto feature uopšte postoji i da li je dobar način dizajna

On ima vremena da: isporuči feature koji radi. I to je – sve što se od njega traži, jer je to ono za šta agencija dobija novac.

Ovaj pritisak se ne dešava jednom ili dvaput – on je trajno stanje agencijskog rada. I svaki put kada developer skrati put, svaki put kada izabere brzo rešenje umesto dobrog, on gradi nešto u svom mozgu što je mnogo gore od tehničkog duga u kodu: naviku da ne misli duboko o onome što radi.

Tehnički dug kao standardni operativni postupak

Tehnički dug (technical debt) je u svakom razvojnom okruženju realnost. Ali postoji fundamentalna razlika u tome ko snosi tu cenu.

U produktnoj firmi, tehnički dug koji tim napravi danas – tim plaća sutra. Zato postoji snažan interni podsticaj da se on minimizuje, dokumentuje i planiran plaća. Inžinjeri koji ga prave žive sa njim. Senior developeri koji gledaju arhitekturske odluke mlađih kolega to gledaju kroz prizmu: „Ja ću ovo morati da održavam sledeće dve godine.“

U agencijskom modelu, tehnički dug koji tim napravi danas – klijent plaća sutra. I klijent ga plaća dosta skupo: sporiji razvoj novih feature-a, češći bugovi, skuplje održavanje. Ali za agenciju – i za developera koji je taj dug napravio – može proći jako dugo pre nego što se ta cena realizuje, a i kada se realizuje, nije direktno vezana za vašu godišnju procenu.

Ovo nije moralni sud. Ovo je opis ekonomske logike koja sistematski nagrađuje brzinu i kažnjava samo one koji snose buduće troškove svojih dana­šnjih odluka.

Rezultat je da developer koji provede nekoliko godina u agencijskom modelu razvija nešto što se može nazvati „debt-tolerant mindset“ (tolerancija prema tehničkom dugu) – mentalitet u kome je „radi dok radi“ prihvatljiv standard, a „radi ispravno“ luksuz koji možda jednom neće zadesiti.

Breadth bez depth: širina bez dubine

Jedna od najfrekventnijih odbrana agencijskog rada – i ona koja ima legitimnu osnovu – jeste raznolikost iskustva. U agenciji ste godišnje na tri, četiri, pet različitih projekata. Videli ste različite industrije, različite poslovne probleme, različite tehno­loške stack-ove. To mora biti dobro, zar ne?

Pa – da i ne.

Raznolikost iskustva je vrednija u ranoj fazi karijere, kada je nivo neznanja visok i kada svaka nova tehnologija ili domen donosi eksponencijalan prirast znanja. Ako tek počinjete, izloženost različitim kontekstima vam pomaže da razumete širi pejzaž industrije i izgradite bazičnu adaptabilnost.

Problem nastaje kada raznolikost ostaje jedini oblik rasta – kada se nikada ne dostigne tačka u kojoj idete duboko u nešto. A to je upravo ono što agencijski model strukturalno sprečava.

Zamislite analogiju: možete naučiti da plivate u deset različitih bazena. Ali ako ni u jednom niste bili duže od mesec dana, nikada nećete naučiti da ronite.​​

Depth (dubina) – duboko razumevanje arhitekture kompleksnog sistema, duboko poznavanje određenog domena, sposobnost da predvidite kako će sistem izgledati za godinu dana i da planirate prema tome – dolazi jedino od dugotrajnog rada na istom sistemu. I to je ono što agencijski model sistemski onemogućava.

Istraživanje o nedostatku senior developera u 2026. godini eksplicitno identifikuje ovaj mehanizam: „Ono što je nekad bila prednost pri zapošljavanju – dugogodišnje projektno iskustvo – može postati nedostatak jer tehnologije na tim projektima često ostaju zamrznute. Lojalnost danas nije dovoljna – ažurne veštine određuju karijernu vrednost“.​

Seniority paradox: senior u agenciji vs. senior u produktnoj firmi

Ovo je možda najkonkretniji i najosetljiviji aspekt cele teme, pa ga iznesimo direktno.

Titule u agencijskom modelu infliraju brže nego što to zaslužuje stvarni nivo znanja. Razlog je jednostavan: agencije imaju relativno plitku hijerarhiju, fluktuacija je visoka, a klijenti žele „senior“ developere zato što se ta titula podrazumeva kao signal kvaliteta.

Rezultat: developer koji je u agenciji sa četiri-pet godina iskustva nazvan senior developer – može i u sopstvenoj glavi prihvatiti taj status kao tačan opis svojih sposobnosti. A onda se prijavi za poziciju u ozbiljnoj produktnoj firmi i prođe kroz „proper“ tehnički intervju – sistemski dizajn, algoritmi, dubinska pitanja o konkretnim tehno­logijama – i otkriva da mu nedostaju fundamenti koje je pretpostavljao da ima.

Ovo nije teorija. Na Hacker News-u i Reddit-u postoje deseci niti u kojima se ovo iskustvo opisuje gotovo identičnim rečima: „Bio sam pet godina ‘senior’ u agenciji. Mislio sam da sam dobar developer. Pa sam se prijavio u [insert FAANG ili ozbiljnu produktnu firmu] i shvatio da ne znam kako da dizajniram sistem koji može da skalira na milion korisnika.“

Karijerijski put u produktnoj firmi izgleda jasno, prema podacima sa LinkedIn Pulse analize iz avgusta 2025.: Junior Developer → Senior Developer → Tech Lead → Engineering Manager → VP of Engineering – sa jasnom vertikalnom ekspanzijom kompetenci na svakom koraku.​

U agenciji, karijerni put izgleda: Junior Developer → Mid Developer → Senior Developer → Možda Tech Lead koji supervizira druge ljude koji rade iste stvari koje ste vi radili. Vertikalna ekspanzija kompetenci je zamućena jer posao suštinski ostaje isti – samo imate više iskustva u isporuci, ne nužno u tehničkoj dubini.

Produktna firma: kako izgleda s druge strane

Sada pogledajmo drugu stranu jednačine – i budimo jednako pošteni prema njenim manama kao što smo bili prema agencijskom modelu.

Ownership (vlasništvo) kao katalizator rasta

Najfundamentalnija razlika između agencije i produktne firme nije tehno­loška – ona je psihološka i motivacijska: u produktnoj firmi, vi ste deo tima koji poseduje sistem koji grade.

Ovo zvuči apstraktno, ali ima sasvim konkretne posledice. Kada vi i vaš tim posedujete arhitekturalne odluke – kada znate da će sistem koji dizajnirate danas biti vaš problem (ili vaš ponos) za dve godine – počinjete da razmišljate drugačije o onome što radite.

Počinjete da postavljate pitanja koja u agencijskom modelu ne postavljate:

• Zašto smo se odlučili za ovaj pristup umesto onog?

• Koja su tehno­loška rešenja primenljiva ovde i koja su trade-offovi?

• Šta se dešava sa ovim sistemom kada broj korisnika poraste deset puta?

• Koji tehnički dug smo napravili i kada planiramo da ga platimo?

Ova pitanja nisu luksuz u produktnoj firmi – ona su deo standardne radne kulture. I postavljanje tih pitanja, i traženje odgovora, i žuvanje sa odgovorima koji su komplikovani – to je mehanizam kroz koji developer zapravo raste.​

Dubina domene (domain depth) kao nevidljiva prednost

Jedan od najnedovoljno shvaćenih aspekata rada u produktnoj firmi je vremenski akumulirani domain knowledge (znanje o domenu).

Zamislite developera koji tri godine radi na fintech platformi – sistemu za obradu plaćanja. U prve šest meseci, on uči osnove: kako platni sistemi funkcionišu, regulatorni okvir, tehno­loška arhitektura. U sledećih šest meseci, počinje da razume nijanse: zašto određeni dizajnerski izbori postoje, koje greške su prethodnici napravili i zašto ih nije lako ispraviti, kako sigurnosne zahteve uskladiti sa performansama. U drugoj i trećoj godini, on razvija nešto što se ne može kupiti ni na jednom kursu: intuitivan osećaj za to koji pristup će raditi i koji neće, pre nego što uopšte napišete red koda.

Taj domain depth ima tržišnu vrednost koja je gotovo nevidljiva na CV-u, ali je enormna u praksi. Senior developer u fintech domenu koji razume regulatorne zahteve, bezbednosne implikacije i tehno­loške trade-offove – vredan je daleko više od developer koji je „bio na projektu“ i vidio fintech izbliza.

U agencijskom modelu, taj akumulativni domain knowledge ne postoji. Projekat se završi, idete dalje, i sve znanje koje ste stekli o specifičnom domenu postaje — u velikoj meri — zastarelo, jer niste tamo da vidite kako taj sistem živi, stari i evoluira.

Code quality (kvalitet koda) i inžinjerska kultura

U dobrim produktnim firmama, postoji nešto što u agencijama retko postoji u istom obliku: inžinjerska kultura koja vrednuje kvalitet koda kao intrinzičnu vrednost, a ne samo kao sredstvo za postizanje roka.

To se manifestuje kroz:

• Code review koji je stvarna razmena znanja, a ne formalnost

• Architecture Decision Records (ADR – dokumentacija o arhitekturnim odlukama) koja beleži zašto su određene odluke donete

• Refactoring sprints posvećene plaćanju tehničkog duga

• Internal tech talks (interne tehničke prezentacije) i kultura deljenja znanja

• Blameless post-mortems (analize grešaka bez optuživanja) kojima je cilj sistemsko učenje, ne kažnjavanje

Sve ovo zvuči kao soft benefiti. Ali konkretna posledica je direktna: developer koji provede tri godine u ovakvoj kulturi nauči više o tome kako se grade softveri – ne samo kako se pišu redovi koda – nego developer koji provede pet godina u agencijskom modelu u kome je svaki review površan, a svaki refactor „za kad bude vremena“ (tj. nikad).

Mentorstvo: ko te uči i koliko

Ovo je dimenzija koja je posebno važna za juniore i mid-level developere, i koja je retko eksplicitno navedena u razgovorima o agenciji vs. produktnoj firmi.

U dobroj produktnoj firmi, postoji tim koji radi na istom sistemu, koji ima akumulirani kontekst i koji ima intrinzičnu motivaciju da junior i mid-level developeri postanu bolji – jer su njihovi problemi manjeg obima kada njihovi kolege postanu sposobniji.

U agencijskom modelu, senior developer ima manje podsticaja za mentorstvo. Projekat traje ograničeno vreme, rokovi su pritisak, a „naučiti juniora“ košta više vremena nego što se u kratkom roku isplati. Mentorstvo je, u ekonomskoj logici agencijskog modela, trošak – ne investicija.

Ovo je potvrđeno i anegdotski i empirijski. U razgovoru sa iskusnim inžinjerima, konzistentna observacija je da je juniorima mnogo teže dobiti kvalitetno mentorstvo u agenciji jer nema strukturalnog podsticaja za njega. Produktne firme imaju taj podsticaj jer direktno profitiraju od razvoja sopstvenog tima.​

Srpski kontekst: zašto je ovo posebno relevantno ovde

Do sada smo govorili o generalnim principima koji važe globalno. Ali srpski IT kontekst ima neke specifičnosti koje ovu dinamiku čine posebno relevantnom – a za neke developere i posebno teškom.

Srpska IT industrija i outsourcing kao dominantni model

Srpska IT industrija je u zadnjoj deceniji doživela značajan rast, ali taj rast je u velikoj meri bio vođen outsourcing modelom. Prema dostupnim podacima za 2026. godinu, prosečna plata remote software developera u Srbiji iznosi između 40.000 i 60.000 USD godišnje, a senior developeri koji rade za zapadne klijente mogu dostići i više.

Ovaj model je ekonomski relevantan i razumljiv: srpski developeri koštaju 40-65% manje od ekvivalentnih developera u Zapadnoj Evropi i 60-75% manje od onih u SAD-u, a kvalitet rada je visok. To je bio recept za brzi rast industrije.​

Ali problem je taj što taj model – po svojoj definiciji – stavlja srpske developere u ulogu resursa za tuđi proizvod. Mi gradimo Airbnb funkcionalnost, Ali nismo Airbnb. Mi gradi fintech API, ali ne razumemo pun finansijski kontekst iza njega. Mi optimizujemo e-commerce checkout, ali nikad nismo bili vlasnici metrike konverzije.

U međuvremenu, produktne kompanije u Srbiji i regionu – Nordeus do akvizicije, Levi9 za neke projekte, ali i sve broj­nije domaće produkt startupe – nude drugačiji model. Plate su ponekad niže na kratki rok, a pritisak isporuke je drugačiji (ali nije manji). Međutim, mogućnost za tehnički rast je, strukturalno, veća.

Plafon plate i plafon znanja su isti plafon

Postoji jedna veoma konkretna manifestacija agencijskog karijernog plafona u srpskom kontekstu: ne samo da tehnički rast stagnira – plate stagniraju paralelno.

Evo zašto: u agencijskom modelu, vaša pregovaračka moć pri promeni posla direktno korelira sa vašim tehničkim nivoom. Developer koji je zaista narastao – koji može da dizajnira sisteme, koji razume arhitekturalene trade-offove, koji ima duboko domain znanje – ima pregovaračku poziciju za dosta višu platu.

Developer koji je pet godina isporučivao feature-e, ali nije rastao u dubini, može da pređe iz jedne agencije u drugu i dobije 10-15% više. Ali ne može da „skoči“ na kategoriju produktne firme koja plaća dvostruko više jer mu traži tehničke kompetence koje u agencijskom modelu nije imao gde da razvije.

Sat sa srpskim seniorim developerom za outsourcing koštа između 30 i 70 dolara prema dostupnim podacima za 2026. Senior developer u velikoj produktnoj firmi – čak i u Srbiji – može dostizati plate koje su daleko iznad tog raspona. Razlika nije u godinama iskustva; razlika je u vrsti iskustva.​

Burnout: tiha epidemija koju niko ne voli da pominje

Agencijsko okruženje nije samo tehnički problematično – ono je i emocionalno iscrpljujuće na način koji je specifičan.

Konstantno menjanje projekata znači konstantno menjanje konteksta. Svaki novi projekat zahteva period „onboarding“ (uvođenja) u kome ste manje produktivni nego što biste bili na poznatom sistemu. Svaki završetak projekta znači da gubite kontekst koji ste izgradili. A između svega, postoje klijenti koji imaju nerealna očekivanja, rokovi koji su pretijesni i scope creep koji je hroničan.

Harness-ova studija iz 2024. pokazuje da 52% developera navodi burnout kao primarni razlog zašto kolege napuštaju posao, a 62% je iskusilo scope creep koji ih prisiljava da rade više sa manje sigurnosti u ishod.​

Burnout u agencijskom kontekstu ima i specifičan psihološki oblik koji se retko imenuje: meaninglessness (besmisao). Developer koji isporuči projekat ne vidi šta taj projekat postiže – jer ga klijent odvede sa sobom. Ne vidi rast koji je napravila platforma koju je izgradio. Ne dobija feedback o tome da li je ono što je isporučio zaista rešilo problem. On je napravio widget za nečiji tuđi svet, a onda taj svet zatvorио vrata.

Nasuprot tome, developer koji radi na produktu koji koriste stvarni korisnici – koji može da vidi analytics (analitiku), koji sluša korisnički feedback, koji može da kaže „ja sam napravio feature koji koristi milion ljudi“ – ima vrstu smisla u poslu koja ima direktnu vezu sa karijernom motivacijom i dugoročnom posvećenošću.

Counterargument: da li je sve crno-belo?

Nije. I bio bi nepošteno prema čitaocu i prema temi da se pretvaramo da jeste.

Postoje agencije koje su izuzetci od svega što je opisano. I postoje produktne firme koje imaju sve mane agencije i nijednu njenu prednost.

Kada agencija zaista može biti dobro mesto

Na početku karijere, agencija ima specifičnu prednost: izloženost. Junior developer koji u dve-tri godine vidi pet-šest različitih projekata, industrija i tehno­loških stack-ova – razvija bazičnu adaptabilnost i širi horizontan pregled nego da je proveo iste dve-tri godine na jednom projektu u produktnoj firmi. Ova prednost je realna i vredi je prepoznati.

Ako agencija ima visoke tehničke standarde – strogi code review, kulturu dokumentacije, interne tehničke razgovore, i posvećenost refaktorovanju – ona može biti izuzetno dobro mesto za razvoj. Ali takve agencije su izuzeci, ne pravilo. I čak i u njima, suštinski problem ostaje: ne posedujete ono što gradite, i na kraju nikad ne vidite kako ono živi.

Ako ste specijalizovani konsultant u oblasti koja zahteva duboku ekspertizu – cloud migracije, data engineering, bezbednost, specifični enterprise sistemi – agencijsko ili konsultantsko okruženje može biti sjajan kontekst jer svaki novi angažman donosi novu dimenziju iste tehno­loške vertikale.

Ako namerno gradite široku mrežu kontakata i poslovnih iskustava, s ciljem da eventualno osnujete sopstvenu firmu – agencijsko iskustvo može biti vredna osnova. Ali i u tom slučaju, ono je sredstvo za cilj, ne cilj sam po sebi.

Mane produktnih firmi koje se ne smeju prećutati

Ni produktne firme nisu raj na Zemlji. Neke od njihovih specifičnih zamki:

Silo efekt: Kada previše duboko zaroniš u jedan sistem i jedan domen, možeš izgubiti sposobnost za horizontalnu adaptabilnost. Developer koji je pet godina radio isključivo na jednoj platformi – posebno ako se ta platforma ne ažurira agresivno – može biti tehnološki zastareo na specifičnom stack-u i van njega.

Legacy prison (zatočeništvo u starom kodu): Neke produktne firme imaju decenijama star legacy kod koji niko nije hteo ili smeo da dira. Raditi na takvom sistemu može biti jednako karijerno stagnantno kao rad u agenciji – samo iz drugog razloga.

Politika i birokratija: Veće produktne firme imaju procese, odbore za odobravanje arhitekturnih promena, komitete za sigurnost i menadžment koji razume biznis bolje nego tehno­logiju. Za developera koji želi autonomiju, ovo može biti jednako frustrirajuće kao rad za klijenta koji menja zahteve svake nedelje.

Sporiji karijerski napredak u smislu titule: Produktna firma koja ima stroge kriterijume za napredovanje – u kojoj je za Senior Developer titulu potrebno demonstrirati sistemski dizajn, mentorstvo i vlasništvo nad arhitekturnim odlukama – može izgledati sporija na kratki rok u poređenju sa agencijom koja seniority daje sa pet-šest godina iskustva, bez obzira na dubinu.

Razlika je u tome što sporiji napredak u produktnoj firmi znači napredak koji je stvaran – koji se bazira na realnom tehničkom nivou, a ne na inflacionoj dinamici titula.

Kako prepoznati: test za sopstvenu situaciju

Ovo je praktičan odeljak koji je namenjen onima koji se u ovom trenutku pitaju – „Ok, ali gde sam ja?“

Postoji pet pitanja kojima možete testirati sopstvenu karijernu situaciju, bez obzira gde radite:

Pitanje 1: Da li možete opisati jednu tehničku odluku u poslednjih šest meseci za čiji ishod ste vi bili odgovorni?

Ne tiket koji ste zatvorili. Ne feature koji ste isporučili. Arhitekturalna ili tehno­loška odluka – zašto je odabran ovaj pristup umesto onog, ko je tu odluku doneo i zašto, i koje su bile alternative – i da li ste vi bili deo toga.

Ako ne možete da navedete ni jednu takvu odluku, to je signal.

Pitanje 2: Da li razumete kako sistem koji gradite funkcioniše pod opterećenjem?

Možete li opisati šta se dešava kada vaša aplikacija dobije deset puta više korisnika nego inače? Koji deo sistema puca prvi? Kako ste to planirali? Da li postoje load testovi koji to potvrđuju?

Developeri u agencijskom modelu koji isporučuju feature-e za klijente retko imaju odgovor na ova pitanja – jer ta pitanja nisu njihov posao. Developer u produktnoj firmi koji ne može da odgovori na ova pitanja – ima problem.

Pitanje 3: Da li ste prošle godine nešto naučili što biste teško naučili bez ovog konkretnog posla?

Ne kursevi van posla. Ne YouTube tutorials. Ne lično istraživanje. Nešto što je struktura vašeg rada – projekti, kolege, problemi koje ste rešavali – ekskluzivno ponudila vam kao mogućnost učenja.

Ako je odgovor „teško“ ili „ne zaista“ – vaš radni kontekst nije motor vašeg razvoja.

Pitanje 4: Da li biste se prijavili za senior poziciju u ozbiljnoj produktnoj firmi?

Ne „da li biste dobili“ – da li biste se prijavili? I da li imate osećanje da biste mogli da odgovorite na sistemska dizajn pitanja?

Ako je odgovor „verovatno ne“ ili „bojim se da ne“ – to je konkretna informacija o tome gde se vaš karijerski razvoj nalazi.

Pitanje 5: Da li znate šta rade vaši korisnici sa onim što gradite?

Imate li pristup analytics-u, korisničkom feedbacku, production metrikama? Vidite li kako vaš kod živi u stvarnom svetu?

Ako je odgovor „ne“ – vi gradite za mrак. I to je signal o vrsti posla koji radite.

Šta uraditi: konkretni koraci za različite situacije

Ako ste junior ili mid developer u agenciji

Iskoristite agencijsko iskustvo za ono u čemu je zaista dobro – širina, adaptabilnost, izloženost – ali ga tretujte kao fazu, a ne kao destinaciju. Aktivno radite na sledećem:

Izgradite depth paralelno sa breadth-om: Dok radite na projektima u agenciji, izaberite jednu tehno­lošku vertikalu u kojoj ćete ići duboko sopstvenim tempom. Ne morate da čekate da vam projekt to da – možete izgraditi sopstveni open source projekat koji simulira sistem pod opterećenjem, pisati o tehničkim temama koje istražujete, ili doprinositi etabliranim open source projektima koji su dovoljno složeni da zahtevaju dubinsko razumevanje.

Nađite mentora van vaše firme: Zajednice poput lokalnih meetup-ova, Discord servera, LinkedIn mreže – daju vam pristup iskusnim developerima u produktnim firmama koji vam mogu dati feedback koji vaš tech lead u agenciji možda nema kapacitet ili motivaciju da vam da.

Intervjuišite aktivno: Čak i kada ne tražite posao, idi na intervjue svake šest meseci. Nije cilj da promenite posao – cilj je da dijagnostikujete praznine u svom znanju dok ima vremena da ih popunite. Sistematski dizajn intervjui su posebno vredna dijagnostička vežba za sve koji žele da razumeju gde im fali dubina.

Ako ste senior developer u agenciji i plafon je vidljiv

Ovo je teža situacija jer dolazi sa finansijskim i karijerskim pritiskom koji je stvaran. Ali ignorisanje plafona ne podiže ga.

Konkretni koraci:

Definirajte gde želite da budete za tri godine. Ne generičko „bolje plaćen“ ili „senior pozicija“ – konkretno. Da li želite da budete arhitekta sistema? Da radite na AI/ML infrastrukturi? Da uđete u engineering leadership? Svaka od tih putanja zahteva različit set kompetenci, i neke od tih kompetenci možete početi graditi već sada, čak i u agencijskom kontekstu.

Aktivno tražite internu promenu uloge. Mnoge agencije imaju projekte različitog profila – možete tražiti raspoređivanje na projekat koji je tehno­loški izazovniji, koji uključuje sistem na veću skalu, ili koji zahteva više arhitekturalnog razmišljanja. To nije garan­tovano, ali je moguće.

Gradite public portfolio tehničke ekspertize. Blog, GitHub, conference talks (izlaganja na konferencijama) – sve ovo gradi reputaciju koja je nezavisna od kompanije u kojoj radite i koja otvara vrata. Developer koji je napisao deset dobro istraženih tehničkih tekstova o distribuiranim sistemima — ima verodostojnost koja transcendira titulu „senior developer u XYZ agenciji.“

Ako razmišljate o prelasku u produktnu firmu

Ovo je dugoročni projekat koji zahteva pripremu – posebno ako dolazite iz agencijskog konteksta i nemate naviku na sistemski dizajn pitanja.

Počnite sa sistemskim dizajnom. Knjige poput „Designing Data-Intensive Applications“ Martina Kleppmann-a i „System Design Interview“ Alex Xu-a su praktički obavezni materijal. Nisu lako štivo, ali su direktna priprema za ono što ćete sresti na ozbiljnim tehničkim intervjuima.

Radite na LeetCode i algoritamskim zadacima – ali svesno, ne mehanički. Poenta nije da zapamtite rešenja, nego da razvijete sposobnost razmišljanja o efikasnosti koda, što je veština koja se u agencijskom modelu retko koristi.

Ciljajte startupe i mid-size produktne firme kao prvi korak, a ne FAANG odmah. Prijelaz direktno iz agencije u Meta ili Google je moguć, ali je za većinu ljudi previše velik skok. Mid-size produktna firma koja ima dobru inžinjersku kulturu – i koja ima kapacitet za mentorstvo junior-to-mid prelasku iz agencijskog konteksta – je realniji i plodniji prvi korak.

Budućnost: AI i šta ona menja za ovu kalkulaciju

Bilo bi nepotpuno završiti ovu analizu bez osvrtanja na kontekst koji se dramatično menja: veštačku inteligenciju i njene implikacije za rad developera.

AI i code monkeyji: prva linija automatizacije

Ako postoji jedna kategorija razvojnog rada koja je pod direktnom pretnjom od AI alatki, to je upravo onaj deo rada koji smo opisali kao „code monkey“ posao: primanje specifikacije, pisanje relativno standardizovanog koda, predavanje, primanje sledećeg tiketa.

GitHub Copilot, Cursor, Claude Artifacts i niz sličnih alatki već sada preuzimaju znatan deo boilerplate koda, rutinskih implementacija i standardnih patterns-a. Istraživanje Stack Overflow-a iz 2024. pokazuje da je usvajanje AI alatki u razvojnom radu masivno i rastuće.​

Šta to znači za agencijski model? Pritisak na cenu agencijskog rada raste jer se iste isporuke mogu postići sa manje developera ili sa juniorim developerima koji su asistiraju AI-om. Ekonomska prednost outsourcinga – jeftina radna snaga koja isporučuje – erodira paralelno s tim.

I šta to znači za code monkeyje? Oni su direktno u zoni automatizacije. Posao koji se sastoji od pretvaranja specifikacija u standardizovani kod – to je ono što LLM modeli rade sve bolje.

Šta AI ne može da zameni

Ali tu postoji i dobra vest, za sve koji su spremni da je čuju: ono što AI ne može da zameni je upravo ono što agencijski model ne razvija dovoljno – i što produktne firme razvijaju.

Prema istraživanjima o trendovima zapošljavanja u 2026. godini, tržište je dramatično polarizovano: oversupply (previše kandidata) za juniorske i generaliste pozicije, i genuine scarcity (stvarni deficit) za senior inžinjere koji:​

• Mogu da projektuju kompleksne sisteme u produkciji

• Razumeju AI-generisani kod, debuguju ga i preuzmu odgovornost za njega

• Imaju domain expertise koji im omogućava da postavljaju prava pitanja, ne samo da odgovaraju na tehničke zahteve

• Mogu da komuniciraju tehničke trade-offove menadžmentu i stakeholderima

Sve ovo su kompetence koje se razvijaju u produktnom okruženju, kroz vlasništvo, dubinu, mentorstvo i karijerni rast koji je nešto dublje od „isporučio sam tiket“.

Agencijski model je, dakle, u dvostrukom škripcu: sa jedne strane, AI erодira ekonomsku osnovu outsourcinga; sa druge, tržišna vrednost koja ostaje – duboka seniornost i domain expertise – nije ono što agencijski model primarno razvija.

Groblje ili poligon?

Naslov ovog teksta je namerno oštar. I, kao što smo videli, nije bez osnove – ali zaslužuje nuansu.

Agencija nije automatski groblje za svakog developera. Ona je groblje za one koji ne prepoznaju njene strukturalne ograničenja i ne rade aktivno na tome da ih zaobiđu. Ona je groblje za one koji prihvate „isporuču pa zabudi“ kao jedini mogući ritam razvoja. Ona je groblje za sve koji dozvole da comfort plate, relaksirani rokovi (kada ih ima) i nedostatak tehničke ambicije u okruženju postanu njihova sopstvena ambicija.

Ali agencija može biti i poligon – teren za vežbu, ne za stanovanje. Ako ste svesni njenih ograničenja i aktivno radite mimo nje na svom dubokom tehničkom razvoju, ona vam daje nešto legitimno: izloženost, adaptabilnost i mrežu kontakata. Uz uslov da to nije kraj priče.

Ono što ne smete je da dozvolite da pet ili šest ili deset godina prođe u agencijskom modelu a da sebe ne pitate barem jednom godišnje: da li sam dublje u nečemu nego što sam bio pre godinu dana? Da li razumem sistem koji gradim – njegov kontekst, njegovu arhitekturu, njegovu buduću evolutivnost – ili samo znam da ga napišem?

Jer code monkey nije sudbina. To je ishod – specifičnog sistema, specifičnih izbora i, najvažnije, specifičnog nedostatka pitanja koja su trebala biti postavljena ranije.

Pitajte ih sada.