Negde u Beogradu, Novom Sadu ili Nišu, u nekom coworking prostoru, sedi čovek koji je pre godinu i po dana radio u marketingu, a koji se danas na LinkedInu predstavlja kao „Full-Stack Web Developer & Digital Solutions Expert.“ Njegova putanja od marketinškog koordinatora do developera trajala je tačno koliko i Udemy kurs od 14 sati o Webflow-u – uz eventualni kratak izlet u Bubble „da nauči i backend“.
On pravi sajtove. Neki od njih zaista izgledaju dobro. Klijentima naplaćuje ozbiljne iznose. I – ono što ne prestaje da iritira ljude koji su proveli pet godina učeći C, algoritme, strukture podataka i arhitekturalne obrasce – on sebe naziva developerom.
S druge strane, u istom gradu, mladi inženjer koji ima solidno razumevanje memorijskog upravljanja, koji zna razliku između heap-a i stack-a, koji je implementovao custom authentication sistem od nule i koji je probdio noć debugujući race condition (stanje trke u izvršavanju niti) u multithreaded (višenitnoj) aplikaciji – taj inženjer dobija oferte od klijenata koji pitaju „zašto bi plaćali toliko kada mogu da dobiju sajt za duplo manje?“
Oba čoveka postoje. Oba su realni. I napetost između njih je jedna od najrelevantnijih i najneugodnijih tema u savremenom IT ekosistemu – tema koja se izbegava jer je direktna, jer povređuje osećanja, jer nema lagodnog „svi imaju pravo“ odgovora.
Ovaj tekst ne nudi lagan odgovor. Nudi provokativnu analizu koja ni jednu stranu neće u potpunosti zadovoljiti – što je, verovatno, znak da se bliži istini.
Definicije koje se izbegavaju: Ko je zapravo developer
Pre nego što se upustimo u debatu, moramo biti precizni u terminologiji. Jer deo problema jeste upravo to da termin „developer“ nije zaštićen, nije standardizovan i ne postoji certifikaciono telo koje bi proveravalo ko ga može koristiti.
Za razliku od termina „lekar“, „advokat“ ili „ovlašćeni računovođa“ – koji su zakonski regulisani i koji zahtevaju dokumentovanu stručnost – termin „developer“ (ili „web developer“, „software developer“) je potpuno slobodan. Svako se može nazvati developerom. Svako može staviti na vizit-kartu ili LinkedIn profil. Regulatornog tela koje bi proverilo osnovanost te tvrdnje – nema.
Ovo nije slučajnost. To je istorijsko nasleđe industrije koja je nastala van tradicionalnih profesionalnih okvira, u kojoj je meritokratija (ili barem njena ideja) bila fundamentalnija od formalnih kvalifikacija. U ranim danima web-a, developer je bio onaj ko zna da napravi ono što treba napraviti. Tačka. Bez obzira na formalno obrazovanje, bez obzira na sertifikate.
Ali to je bio svet u kome je „napraviti ono što treba napraviti“ podrazumevalo pisanje koda. Jer drugi način nije ni postojao.
No-code i low-code alati su promenili tu jednačinu. Sada je moguće napraviti funkcionalan, vizualno sofisticiran digitalni proizvod – sajt, mobilnu aplikaciju, automatizovani workflow, pa čak i složeniji SaaS (Software as a Service – softver kao usluga) prototip – bez ijedne linije ručno pisanog koda.
Pitanje koje industrija izbegava direktno postaviti: da li ta promena znači da se granica između „developera“ i „korisnika softverskih alata“ rastvorila, ili je samo postala nevidljivija?
Kratka istorija demokratizacije razvoja softvera: Nismo prvi put ovde
Argument koji no-code/low-code zagovornici najčešće koriste je argument istorijskog presedana: „I uvođenje PHP-a, WordPress-a, pa i samog HTML-a su u svoje vreme bili kritikovani kao ‘srozavanje standarda’.“
Ovo nije netačan argument, i zaslužuje ozbiljno razmatranje pre nego što ga odbacimo.
Kada je Tim Berners-Lee kreirao HTML i kada je web postao dostupan javnosti u ranim 90-ima, pisanje HTML-a je zahtevalo razumevanje strukture dokumenta, HTTP protokola (Hypertext Transfer Protocol – protokol za prenos hipertekstualnih dokumenata) i logike linkovanja. Tada su i to bile „prave“ veštine.
Kada je Dreamweaver uveden krajem 90-ih i kada je WYSIWYG (What You See Is What You Get – što vidiš to i dobijaš) uređivanje HTML-a postalo moguće, „pravi“ HTML koderi su gunđali da dolazi najezda amatera koji ne razumeju šta se dešava ispod haube.
Kada je WordPress u 2003. uveo upravljanje sadržajem bez potrebe za direktnim pisanjem PHP-a, slična kritika se ponovila: „WordPress programeri nisu pravi developeri.“
I evo nas ovde, 2026, sa Webflow-om, Bubble-om, Adalo-m i desecima sličnih platformi, i ista kritika se ponavlja treći, četvrti ili peti put u dvadeset godina.
Da li to znači da je kritika uvek bila pogrešna? Ili da je svaki put bila delimično tačna – da je svaki novi nivo apstrakcije zaista doneo i najezdu neisposebljenih korisnika koji su smanjili zahteve za prosečnom stručnošću, ali da je industrija u celini nastavila da raste i da pravi inženjeri nisu nestali?
Odgovor na ovo pitanje nije ni „da“ ni „ne“. On je „i da i ne“, i upravo u toj kompleksnosti leži suština debate.
Šta no-code i low-code alati zapravo jesu: Objektivna analiza bez romantizacije
Da bismo bili pošteni prema obe strane debate, moramo razumeti šta no-code i low-code alati zapravo mogu – i šta ne mogu.
No-code alati poput Webflow-a, Bubble-a, Wix-a, Squarespac-a, Airtable-a, Zapier-a i Make-a (bivši Integromat) su platforme koje korisnicima dozvoljavaju izgradnju digitalnih proizvoda kroz vizualne interfejse, drag-and-drop (prevuci i pusti) mehanizme i konfiguracione opcije, bez pisanja koda.
Low-code alati poput OutSystem-a, Mendix-a, Microsoft Power Platform-a i Retool-a su platforme koje kombinuju vizualne interfejse sa mogućnošću pisanja određene količine koda za specifičnu prilagodbu – oni su na spektru između no-code i full-code (potpunog kodiranja).
Što ovi alati zapravo mogu:
-
Izgraditi vizualno sofisticirane, responsivne (prilagodljive) web stranice i aplikacije u frakciji vremena koja bi bila potrebna za ručno kodiranje
-
Automatizovati poslovne procese i integracije između različitih platformi
-
Izgraditi funkcionalne MVP (Minimum Viable Product – minimalno izvediv proizvod) prototipe koji mogu biti testirani sa stvarnim korisnicima
-
Demokratizovati digitalni razvoj tako da stručnjaci u domeni – koji razumeju poslovni problem – mogu direktno kreirati rešenja bez intermedijara
Što ovi alati ne mogu ili ne mogu dobro:
-
Pružiti granularnu kontrolu nad performansama na nivou koji je potreban za zahtevne aplikacije
-
Garantovati bezbednost na nivou koji može zadovoljiti ozbiljne enterprise (poslovne) sigurnosne standarde bez ekstenzivne stručne procene
-
Omogućiti složenu logiku koja zahteva custom algoritme, specifičnu optimizaciju memorijskog korišćenja ili nestandardne arhitekturalne obrasce
-
Skalirati (rasti) ekonomično iznad određenog nivoa opterećenja bez arhitekturalnih problema koji su inherentni platformi
-
Migrirati lako na drugu platformu – vendor lock-in (zavisnost od jednog dobavljača) je ozbiljan i strukturni problem svih no-code platformi
Ovo nije napad na no-code alate. To je objektivna mapa onoga što oni jesu i što nisu.
Zašto je „alat je samo alat“ argument istinit i lažan istovremeno
Najuobičajeniji odgovor koji no-code zagovornici daju na kritiku glasi: „Pravi developer rešava probleme. Alat koji koristite nije relevantan.“
Ovaj argument je u jednoj dimenziji tačan: programiranje, u svojoj suštini, jeste rešavanje problema. Sposobnost da se razbije kompleksan problem na logičke komponente, da se definiše sekvenca koja vodi do rešenja, da se identifikuju edge case-ovi (rubni slučajevi) i da se oni adresiraju – to su mentalne sposobnosti koje su vredne nezavisno od toga koji se alat koristi da se to izvede.
U toj dimenziji, dizajner koji Webflow-om gradi efikasno rešenje za klijentov problem demonstrira sposobnost koja nije bezvredna.
Ali argument „alat je samo alat“ pada na kritici kada se suoči sa ovim pitanjem: šta se dešava kada alat ne može da uradi ono što je potrebno?
Programer koji radi u Pythonu, Javi ili Rust-u kada naiđe na ograničenje standardnih biblioteka – može da implementira sopstveno rešenje. Može da napiše custom modul, da optimizuje algoritam, da direktno manipuliše memorijskim allocations-ima (alokacijama memorije) ako je to potrebno. Ograničenje alata nije ograničenje sposobnosti inženjera, jer inženjer u krajnjoj instanci kontroliše alat.
No-code korisnik kada naiđe na ograničenje platforme – ne može da pređe granicu koju platforma definiše. On može da pronađe workaround (zaobilazno rešenje) unutar platforme, može da integriše drugi no-code alat, može da podigne ticket (zahtev) platformi i čeka da oni implementiraju feature. Ali on ne može da izađe iz okvira koje je vendor postavio.
Ovo je fundamentalna razlika. Nije u alatu. U kontroli nad alatom.
Stolar koji radi sa ručnom testerom i stolar koji radi sa CNC mašinom oba mogu napraviti nameštaj. Ali kada CNC mašina ne može da uradi određeni rez koji dizajn zahteva, samo stolar koji razume geometriju i koji može da uzme ručni alat i završi posao je stolar koji je potpuno u kontroli svog zanata.
Kvalitet softvera i cena nerazumevanja: Gde je ekonomska i bezbednosna cena
Ovde dolazimo do argumenta koji nije estetski ni identitetski – koji je čisto empirijski i koji ima merljive posledice.
Bezbednost: No-code platforme rukuju sigurnosnim aspektima aplikacija kroz sopstvene mehanizme koje korisnici platforme tipično ne razumeju detaljno. OWASP Top 10 (deset najkritičnijih sigurnosnih rizika web aplikacija prema organizaciji Open Web Application Security Project) – SQL injection (ubacivanje SQL naredbi), Cross-Site Scripting (XSS, unakrsna skripta), Broken Authentication (pokvarena autentifikacija), Insecure Direct Object References (nesigurne direktne reference objekata) – su kategorije ranjivosti koje developer koji piše kod mora aktivno da razume i adresira. No-code korisnik se na platformu oslanja da to uradi umesto njega, bez mogućnosti da verifikuje da je to urađeno ispravno.
Kada platforma ima bezbednosni propust – što se dešava – no-code korisnici su uniformno ranjivi, bez kapaciteta da individualno odgovore na ranjivost jer ne kontrolišu kod koji je vulnerabilan. Primeri su dokumentovani u svim većim no-code platformama.
Skalabilnost: No-code aplikacije koje su izgradile male timove i koje su radile dobro do određenog broja korisnika konzistentno prikazuju probleme sa skalabilnošću kada je prelaze kritičnu tačku. Database (baza podataka) dizajn koji je adekavatan za 100 korisnika a koji je katastrofalno loš za 10.000 korisnika – ovo je uobičajeni problem no-code MVP aplikacija koje pokušaju da postanu produkcijske aplikacije. Migracija sa no-code platforme na custom rešenje je, u praksi, gotovo uvek skuplja od inicijalne izgradnje custom rešenja.
Tehničko dugovanje: Technical debt (tehnički dug) – akumulacija lošiho arhitekturalnih odluka koje postaju sve skuplje za rešavanje tokom vremena – postoji u svakom softveru. Ali kod no-code aplikacija, taj dug je posebno teško servisirati jer nije u obliku koda koji može biti refaktorisan (restrukturiran). On je u obliku konfiguracije platforme koja se ne može direktno optimizovati.
Cena greške: No-code alati apstrahuju kompleksnost. To je i njihova vrednost i njihov rizik. Kada neko ko razume kompleksnost napravi grešku – on tipično razume zašto je greška nastala i kako je popraviti. Kada neko ko ne razume kompleksnost napravi grešku – on ne zna zašto je greška nastala, ne razume njenu prirodu i ne može je adresirati sistematski.
Plate inženjera: Da li no-code alati zapravo srozavaju kompenzaciju
Ovo je dimenzija teme koja je najosetljivija jer se tiče egzistencijalnih pitanja za IT profesionalce koji su investirali godine u učenje zanata.
Tvrdnja: no-code i low-code alati su proširili bazen „developera“ na način koji spušta prosečnu cenu rada u segmentima koji su ranije bili ekskluzivni za softvere inženjere – čime se spušta pregovaračka pozicija pravih inženjera, posebno na nižim nivoima iskustva.
Da li je ova tvrdnja empirijski podržana?
Odgovor je slojevit. Globalno tržište softvera raste konzistentno, potražnja za softverskim inženjerima i dalje prevazilazi ponudu u visokospecijalizovanim oblastima – cloud arhitektura, machine learning engineering, sistem programiranje, bezbednost, distributed systems (distribuirani sistemi). U tim oblastima, plate rastu.
Ali u segmentu koji je do pre pet godina bio solidno kompenzovan a koji je sada pod pritiskom – front-end web razvoj za standardne poslovne aplikacije, izgradnja jednostavnih mobilnih aplikacija, WordPress customizacija – pritisak je realan i merljiv.
Freelance platforme poput Upwork-a i Freelancer.com beleže konzistentno smanjenje prosečnih cena za standardne web development projekte koji su pre pet godina imali jasnu minimalnu cenu. Klijenti koji su ranije morali da plate developerima za izgradnju standardnog sajta sada dobijaju no-code alternativu koja je jeftinija i ponekad brža – i za njihov specifičan use case (slučaj korišćenja), ta alternativa je sasvim adekvatna.
To je realnost bez romantizacije. Za srednje-iskusnog web developera koji radi standardne projekte bez specijalizacije – tržišna pozicija je slabija nego što je bila pre pet godina.
Za senior inženjera (starijeg inženjera) koji radi na skalabilnim sistemima, koji razume distribuiranu arhitekturu, koji ima duboku domenu ekspretizu – tržišna pozicija je jača nego što je ikada bila, jer kompleksnost problema koje rešava ne može biti apstrahovana no-code alatima.
Digitalna ekonomija, izgleda, pojačava nejednakost i u sopstvenoj industriji: vrh profitira, sredina trpi.
Paradoks demokratizacije: Više developera, lošiji prosečni softver?
Postoji istraživački nalaz koji zaslužuje direktnu citaciju u ovoj debati.
Standish Group CHAOS Report, koji prati uspešnost softverskih projekata, konzistentno pokazuje da je između 60% i 70% softverskih projekata uspešno (na vreme, unutar budžeta, sa planiranim funkcionalnostima). Ova proporcija nije se dramatično poboljšala u decenijama uprkos proliferaciji alata koji su trebali olakšati razvoj softvera.
Nasuprot tome, postoji argument da demokratizacija alata bez demokratizacije razumevanja fundamentalnih principa (arhitektura softvera, upravljanje podacima, bezbednost, performanse) produkuje više projekata koji izgledaju uspešno kratkoročno a koji nose skrivene troškove koji se manifestuju dugoročno.
Šire gledano, kada IT odluke donose ili implementiraju ne-inženjeri koji ne razumeju tehničke implikacije tih odluka – čak i uz no-code alate koji „čine sve automatski“ – posledice su predvidive: loše migracije podataka, neočekivani sigurnosni propusti, skalabilnostni kolaps i tehnički dug koji je skuplje rešavati nego bi bilo skupo napraviti pravo rešenje od početka.
Ovo nije teorijsko. Ovo je scenarij koji IT konsultanti koji rade sa malim i srednjim preduzećima viđaju redovito: klijent koji je „uštedio“ izgradnjom sajta ili aplikacije u no-code alatu, a koji sada plaća 3-5 puta više da se napravi migracija na pravo rešenje jer je original srastao sa platformom do tačke nemogućnosti nezavisnog razvoja.
Odbrana no-code alata: Argumenti koji su stvarno ubedljivi
Do sada, ovaj tekst je bio relativno kritičan prema no-code ekosistemu. Poštena analiza zahteva da se iznesu argumenti koji su zaista ubedljivi za drugu stranu – ne karikaturalni argumenti koje je lako odbaciti, nego pravi.
Brzina prototipiranja kao vrednost: Za startup koji testira poslovnu hipotezu, brzina izlaska na tržište može biti važnija od arhitekturalne čistoće. No-code MVP koji je na tržištu za dve nedelje i koji testira pretpostavku može biti strateški superioran u odnosu na custom razvijenu aplikaciju koja izlazi za dva meseca. U tom kontekstu, no-code alat je pravo rešenje za pravi problem.
Demokratizacija inovacije u domenima koji su ranije bili isključeni: Postoje domeni – medicina, pravo, obrazovanje, socijalne usluge – u kojima stručnjaci imaju duboko razumevanje problema koji treba rešiti ali koji su bili zavisni od IT intermedijara da prevedu to razumevanje u digitalne alate. No-code platforme dozvoljavaju domainskim ekspertima (stručnjacima u domeni) da direktno implementiraju rešenja za probleme koje razumeju bolje od bilo kog spoljnog developera.
Interno poslovne automatizacije koje ne moraju biti savršene: Interni alat koji automatizuje repetitivni poslovni proces za tim od 10 ljudi, koji radi dovoljno dobro i koji je napravljen za dva dana u Airtable-u umesto za tri meseca u custom razvoju – taj alat je legitimno i racionalno poslovno rešenje. Insistiranje na custom razvoju za interno-korišćene alate niskog rizika je arhaično.
Fokus na problem, ne na tehnologiju: Krajnji korisnik softvera ne zanima se za arhitekturu. Njega zanima da li softver rešava njegov problem. Sa tog stanovišta, alat koji brzo i efektivno rešava problem ima legitimnu vrednost.
Ovi argumenti su stvarni. Problem nastaje kada se oni koriste kao generalni odgovor koji ignoriše kontekstualnu primenu – jer nisu svi projekti MVP startup prototipovi i nisu svi korisnici no-code platformi domejnski stručnjaci koji prave interni alat.
Ko zapravo jeste developer: Predlog definicije koja može zadovoljiti obe strane
Na kraju ove rasprave, korisno je ponuditi definiciju koja nije ni snobistička ni trivijalizujuća.
Developer – softverski inženjer – nije definisan alatom koji koristi. On nije definisan ni činjenicom da ručno piše kod. On je definisan razumevanjem koje stoji iza onoga što gradi.
Predlog operativne definicije:
Developer/softverski inženjer je neko ko:
-
Razume fundamentalne apstrakcije svog stack-a (skupa tehnologija) – šta se dešava „ispod haube“ na nivou koji mu dopušta da dijagnostikuje probleme koji prevazilaze površinsku grešku
-
Može da identifikuje arhitekturalne kompromise i donosi svesne odluke o njima – ne slepo prihvata default opcije alata
-
Razume bezbednosne implikacije svojih odluka i aktivno ih adresira
-
Može da skalira i migriše rešenje kada okolnosti to zahtevaju
-
Preuzima tehničku odgovornost za ono što isporučuje – uključujući odgovornost za probleme koji se pojave nakon isporuke
Prema ovoj definiciji: mogu postajati no-code korisnici koji jesu developeri – oni koji razumeju šta se dešava ispod platforme dovoljno da donose svesne odluke o ograničenjima i kompromisima. I mogu postojati, i postoje, „tradicionalni koderi“ koji nisu developeri – koji mehanički kopiraju Stack Overflow (tehnička platforma za pitanja i odgovore) odgovore bez razumevanja zašto kod koji paste (nalepljuju) radi ili ne radi.
Kriterijum nije alat. Kriterijum je razumevanje i odgovornost.
Budućnost debatе: AI koji kodira umesto svih nas
Ova debata ima i vremensku dimenziju koja je neizbežna: AI coding asistenti – GitHub Copilot, Cursor, Devin, Claude Sonnet za kodiranje, GPT-4o – već pišu značajne delove produkcijskog koda za ozbiljne inženjere u ozbiljnim kompanijama.
Ako je argument „pravi developer piše svaki red koda ručno“ – taj argument je već izgubio. Jer senior inženjeri u top kompanijama koriste AI assistente da generišu kod koji oni onda revidiraju, modifikuju i integrišu. To nije „varanje“. To je produktivno korišćenje alata.
I ako je taj model prihvatljiv – i on jeste – onda debata o no-code vs. code nije debata o alatima. Ona je debata o razumevanju i odgovornosti.
Generativni AI koji piše kod za inženjera koji razume šta kod radi i koji preuzima odgovornost za njegovu ispravnost – to je produktivni inženjer 2026. godine.
Generativni AI koji piše kod za korisnika koji ne razume šta kod radi i koji nema kapaciteta da verifikuje njegovu ispravnost – to je recept za katastrofalne sisteme koji izgledaju funkcionalno dok ne dođe do prvog ozbiljnog incidenta.
Ista logika važi za no-code platforme. Razlika nije u platformi. U razumevanju i odgovornosti koje korisnik platforme donosi.
Zaključak: Struka koja mora sama da postavi standarde pre nego što tržište to uradi
Na kraju, ovaj tekst nema niti može imati zaključak koji zadovoljava sve. Jer situacija je ono što jeste: alati su demokratizovani, bazen „developera“ se proširio, prosečni kvalitet softvera u segmentima koje pokrivaju no-code alati je nejednako distribuiran, i plate za standardni web development su pod pritiskom koji je realan.
Ono što industrija može da uradi – i što bi trebalo da uradi – jeste da insistira na distinkciji koja nije elitistička nego funkcionalna: razlika između korisnika softverskih alata i softverskih inženjera nije vrednosna hijerarhija. Ona je opis različitih kapaciteta koji su prikladni za različite zadatke.
Klijent koji gradi marketinški sajt ne treba softverskog inženjera. Njemu treba no-code dizajner koji razume komunikaciju i UX.
Klijent koji gradi finansijsku platformu na kojoj će se odvijati transakcije realnih korisnika sa realnim novcem ne treba no-code korisnika koji je naučio Bubble za mesec dana. Njemu treba inženjer koji razume bezbednost, skalabilnost i odgovornost.
Konfundiranje ove distinkcije – u oba smera – stvara probleme: inženjeri koji insistiraju na custom razvoju tamo gde no-code rešenje sasvim odgovara su skupi i spori bez razloga. No-code korisnici koji preuzimaju projekte za koje nemaju kapacitet su bezbednosni i finansijski rizik za klijenta koji ne zna razliku.
Termin „developer“ nije ni zaštićen ni beskoristan. On je nedefinisan – i to je problem koji industrija mora da adresira, ne tržište. Jer tržište ga je već adresiralo na način koji ne odgovara ni inženjerima ni korisnicima softvera koji ne znaju što kupuju.
Industrija koja ne definiše sopstvene standarde dobiće standarde koje joj nameću oni koji žele da iskoriste odsustvo definicije. I to se, u 2026. godini, već dešava – svaki dan, svaki klik, svaki novi LinkedIn profil koji dodaje „Developer“ iza marketinškog koordinatora koji je završio 14-satni Webflow kurs.
Jedino pitanje je da li će struka odgovoriti na vreme.
