Key Takeaways – šta je najbitnije u ovom tekstu:

• „AI Engineer“ je tokom poslednjih nekoliko godina postao jedan od najbrže rastegljivih naziva radnog mesta u IT industriji.
• U jednom oglasu AI Engineer trenira modele, radi fine-tuning, optimizuje inference i razume statističko učenje.
• U drugom pravi Retrieval-Augmented Generation – RAG (generisanje potpomognuto pretraživanjem), vector search (vektorsku pretragu), evaluacije i AI agente.
• U trećem uglavnom povezuje gotov Large Language Model – LLM (veliki jezički model) sa postojećom aplikacijom.
• A u četvrtom je praktično backend developer koji koristi OpenAI, Anthropic ili Gemini API.

Sve četiri osobe danas mogu na LinkedIn profilu da imaju isto zvanje: AI Engineer.

To ne znači da je profesija izmišljena. Naprotiv. Tokom 2026. sve je jasnije da se formira ozbiljan novi inženjerski sloj između tradicionalnog Software Engineering-a, Machine Learning Engineering-a i Data Engineering-a. Google, na primer, u aktuelnim Cloud AI Engineer ulogama traži iskustvo sa agent orchestration-om, RAG arhitekturama, multimodalnim sistemima, enterprise AI platformama, bezbednošću, governance-om i cloud infrastrukturom.

Istovremeno, domaći oglasi pokazuju vrlo sličnu sliku. Delta Holding pod nazivom AI Engineer traži rad sa LLM-ovima, agentima, RAG sistemima, klasičnim ML modelima, evaluacijom, monitoringom, troškovima, ERP integracijama i produkcionim deployment-om. Drugi oglas za AI Engineer / Tech Lead eksplicitno kaže da kandidat nije odgovarajući ako „samo integriše AI API-je bez razumevanja ponašanja sistema“.

Tu se nalazi odgovor na pitanje iz naslova. AI Engineer jeste ozbiljna profesija. Ali naziv se trenutno koristi toliko široko da sam po sebi gotovo ništa ne govori o stvarnoj dubini znanja osobe koja ga nosi.

Zato moramo razdvojiti najmanje šest stvari:

• Machine Learning Engineering;
• LLM Application Development;
• RAG Engineering;
• Agent Engineering;
• Prompt/Context Engineering;
• klasični Backend Engineering.

Jer čovek koji zna da pozove LLM API može napraviti AI funkciju. Ali to još ne znači da zna da napravi AI sistem koji pouzdano radi u produkciji. A upravo tu počinje pravi engineering.

Najpre neprijatno pitanje: koliko koda je potrebno da postanete „AI Engineer“?

Tehnički? Vrlo malo.

Danas možemo napisati nekoliko desetina linija Python-a ili JavaScript-a, poslati prompt modelu i dobiti impresivan rezultat. Napravimo jednostavan web interfejs. Dodamo tekstualno polje. Pošaljemo poruku API-ju. Prikažemo odgovor. Aplikacija koristi veštačku inteligenciju.

Da li smo upravo napravili AI proizvod? Da.
Da li smo zbog toga postali AI Engineer? Tu već nastaje problem.

Ako bismo istu logiku primenili na druge oblasti, developer koji je integrisao Stripe API postao bi fintech engineer, a onaj ko pozove Google Maps API – geospatial engineer. Očigledno nije baš tako. API integration je legitimna softverska veština. Ali korišćenje AI servisa i AI Engineering nisu automatski ista stvar. Granica se vidi tek kada demo prestane da bude demo.

Demo radi za pet minuta. Produkcija počinje šestog minuta.

Napraviti chatbot koji odgovara na pitanje nije teško.

Napraviti chatbot koji:

• koristi samo dozvoljene podatke;
• zna kada ne zna odgovor;
• pravilno citira izvore;
• ne otkriva podatke drugog korisnika;
• radi sa hiljadama dokumenata;
• vraća odgovor dovoljno brzo;
• ne košta 12 evra po jednoj korisničkoj sesiji;
• preživljava promenu modela;
• ima evaluaciju kvaliteta;
• ima monitoring;
• ima fallback;
• radi kada provider vrati grešku;
• ima audit trail;

već je druga priča. Tu više ne pričamo o promptu. Pričamo o sistemskom inženjerstvu.

Jedan savremeni oglas za AI Platform Engineer u Beogradu, recimo, traži production-grade AI services, RAG infrastrukturu, agente, LLM evaluations, AI Safety, guardrails, MCP, FastAPI, AsyncIO, Docker, CI/CD, observability i Kubernetes. To je teško nazvati „developerom koji zna da pozove API“. Ali je isto tako teško nazvati istim poslom kao Machine Learning Engineer-a koji trenira i optimizuje modele.

Zato je potrebno napraviti razliku.

1. Machine Learning Engineer: ovo je i dalje „pravi ML“

Machine Learning Engineer – MLE nije nova profesija nastala sa ChatGPT-em. Postojala je mnogo pre generativne AI.

Tipičan ML Engineer radi sa:

• training pipeline-ovima;
• feature engineering-om;
• model selection-om;
• klasifikacijom;
• regresijom;
• forecasting-om;
• recommendation sistemima;
• anomaly detection-om;
• model evaluation-om;
• deployment-om;
• inference-om;
• monitoringom model drift-a.

U ozbiljnijim ulogama potrebni su: Python, NumPy, Pandas, scikit-learn, PyTorch, TensorFlow ili JAX, statistika, verovatnoća, optimizacija, MLOps.

Pogledajmo aktuelnu OpenAI poziciju Machine Learning Engineer-a za Implicit Signals. Opis uključuje supervised fine-tuning, distillation, evaluaciju, deployment, production inference, batching, caching, throughput, latency, compute utilization i cost optimization. Takođe se eksplicitno traži procena accuracy-ja, calibration-a, generalization-a i measurement bias-a.

To je Machine Learning Engineering. Čovek koji samo koristi GPT API nije automatski u istoj kategoriji. I ne treba da bude.

2. LLM Application Engineer: softverski inženjer oko velikog modela

Ovo je verovatno jedna od najvažnijih novih kategorija. LLM Application Engineer uglavnom ne trenira foundation model. On koristi gotov model: GPT, Claude, Gemini, Llama, Mistral, ili neki drugi. Ali oko njega pravi proizvod.

Tu ulaze:

• promptovi,
• structured outputs,
• tool calling,
• context management,
• API integracije,
• business logic,
• authentication,
• backend,
• caching,
• streaming,
• rate limiting,
• fallback modeli,
• logging,
• cost control.

Aktuelni oglas kompanije Quectel u Beogradu upravo koristi naziv LLM Application Engineer i traži povezivanje poslovnih potreba sa AI aplikacijama, agentima, RAG-om, workflow-ima, Python-om, LangChain-om, LangGraph-om, API-jima i sistemskim integracijama. Ovo je možda najbliže onome što mnoge kompanije danas nazivaju „AI Engineer“. I tu nema ničeg neozbiljnog. Ali to je više Software Engineering around AI nego klasični Machine Learning Research. Važno je razlikovati te dve stvari.

3. RAG Engineer: mnogo više od „ubaci PDF u vector database“

RAG je možda oblast u kojoj je marketing napravio najveću štetu.
Tutorial obično izgleda ovako: uzmite PDF, podelite ga na chunkove, napravite embeddings, stavite ih u vector database, pronađite pet najbližih, pošaljite ih LLM-u.
Gotovo. Imate RAG.

Tehnički – da.
Produkcijski – tek ste počeli.

Pravi RAG Engineering uključuje pitanja:

• Kako radimo chunking? Po karakterima? Po tokenima? Po semantičkim celinama?
• Kako tretiramo tabele? Kako dokumente sa više nivoa naslova?
• Kako rešavamo metadata filtering?
• Dense retrieval ili hybrid search? Da li koristimo BM25? Da li treba reranker? Koliki je top_k?
• Kako merimo retrieval recall? Da li je problem retriever ili generator?
• Kako sprečavamo korisnika da kroz retrieval dođe do dokumenta za koji nema dozvolu?
• Kako pratimo verziju dokumenta? Šta radimo kada se knowledge base promeni?

Googleova aktuelna referentna arhitektura za enterprise RAG obuhvata managed datastore, agent orchestration i kompletan end-to-end dataflow – daleko od ideje da je RAG samo nekoliko embeddings poziva.

Na ITNetwork-u smo već u tekstu „RAG i optimizacija: kako da sprečite AI da halucinira podatke o vašoj firmi“ analizirali upravo tu razliku između generičkog modela i sistema koji mora da bude grounded (zasnovan) na kontrolisanom izvoru podataka.

I ovde vredi napraviti jednu važnu korekciju česte marketinške tvrdnje: RAG ne „eliminiše“ hallucinations. Može ih značajno smanjiti. Može poboljšati grounding. Može omogućiti citiranje. Ali sistem i dalje može: izvući pogrešan dokument, pogrešno interpretirati relevantan dokument, kombinovati delove na pogrešan način, ili generisati zaključak koji izvor ne podržava.
Zato RAG bez evaluacije nije engineering. To je demo.

4. Agent Engineer: sada stvari postaju ozbiljno komplikovane

Chatbot daje odgovor. Agent pokušava da uradi nešto. Ta razlika je ogromna.

Agent može: napraviti plan, pozvati alat, pretražiti bazu, pozvati API, otvoriti fajl, napraviti izmenu, proveriti rezultat, odlučiti koji je sledeći korak.

AWS u aktuelnoj dokumentaciji generativne agente opisuje upravo kroz context-aware planning, prompt context, memory, RAG i druge mehanizme koji omogućavaju više koraka i dugotrajnije stanje. Tu nastaje nova kategorija rada: Agent Engineering.

Nije dovoljno napisati: „Ti si agent. Uradi zadatak.“ Moramo projektovati: tool layer, permissions, state, memory, workflow, retry logiku, timeout, termination conditions, human approval, fallback, observability, audit log.

I onda dolaze neprijatna pitanja. Šta ako agent pozove isti alat 700 puta? Šta ako uđe u loop? Šta ako pošalje email pogrešnoj osobi? Šta ako tool result sadrži prompt injection? Šta ako dobije pristup podacima koje korisnik ne sme da vidi? Šta ako akcija nije reverzibilna?

Na ITNetwork-u smo u tekstu „AI agenti i budućnost agilnih razvojnih timova: od asistenta do autonomnog izvršioca“ razdvojili nivoe autonomije upravo zato što agent koji piše nacrt dokumentacije nije isti bezbednosni problem kao agent koji može da izvrši finansijsku transakciju. Tu prompt engineering više nije dovoljno ni približno dobar opis profesije.

Agent Engineering nije samo LangGraph tutorial

I ovde će se verovatno pojaviti ista inflacija titula.
Napravite tri node-a u LangGraph-u. Jedan planner. Jedan tool. Jedan final answer. Na LinkedIn-u: Agentic AI Engineer.

Ali pravi produkcijski agentic system može zahtevati: distributed state, concurrency, idempotency, message queues, credentials management, sandboxing, permissions, traceability, rollback, rate limiting, budget limits, observability.
Drugim rečima: mnogo klasičnog Software Engineering-a.

Aktuelne pozicije za agentic systems upravo zato često zahtevaju pet ili šest godina prethodnog softverskog ili AI/ML iskustva, production Python, evaluaciju, RAG, agent orchestration, security i governance. To je važan signal. Agent Engineering ne zamenjuje Software Engineering. On ga dodatno komplikuje.

5. Prompt Engineering: profesija ili veština?

Ovo će izazvati komentare. Pre nekoliko godina Prompt Engineer izgledao je kao kandidat za novu veliku profesiju. Pojavljivali su se spektakularni naslovi o šestocifrenim platama. Danas je situacija drugačija. Prompting je i dalje veoma važan. Ali sve manje izgleda kao samostalna inženjerska disciplina. Sve više izgleda kao osnovna veština unutar šireg posla.

Zašto? Jer produkcijski kvalitet retko zavisi samo od jedne „savršene formulacije“. Zavisi od: system prompt-a, context-a, modela, temperature, structured output schema-e, retrieval-a, tools-a, memory-ja, evaluacije, guardrails-a.

Zato se sve više govori o Context Engineering-u. Dobar sistem ne pokušava samo da smisli bolju instrukciju. Pokušava da modelu u pravom trenutku pruži: pravi podatak, pravu istoriju, pravi alat, pravo pravilo, u odgovarajućoj količini. Prompt je samo jedan deo toga.

Ako vam je čitava profesija „znam da napišem dobar prompt“, teren postaje klizav. Modeli postaju bolji u razumevanju običnog jezika. Ono što je 2023. zahtevalo pažljivo promptovanje, 2026. često radi uz mnogo jednostavniju instrukciju. Modeli takođe sve više sami razlažu zadatak, planiraju, traže dodatni kontekst, biraju alate.

To ne znači da prompting nestaje. Ali njegov relative value (relativna vrednost) opada u odnosu na: architecture, evaluation, data quality, integration, security, domain knowledge. Čovek koji zna da napiše sjajan prompt može napraviti dobar rezultat. Čovek koji razume ceo sistem može napraviti pouzdan proizvod. To nije isto.

6. Backend Engineer koji koristi AI: možda najpotcenjenija kategorija

Sada dolazimo do vrlo interesantnog dela. Veliki deo „AI Engineering-a“ danas je zapravo dobar Backend Engineering sa novom vrstom dependency-ja.

Potreban vam je: API, auth, database, cache, queue, retry, webhooks, logging, monitoring, CI/CD, Docker, cloud, security. A onda između svega toga imate LLM.

Drugim rečima, ako imate odličnog backend developera koji dobro razume AI sisteme, možda ste mnogo bliže ozbiljnom AI proizvodu nego sa nekim ko zna napredne prompting trikove, ali ne zna kako radi produkcijski servis.

Aktuelni oglasi to potvrđuju. Delta traži Python, FastAPI, SQL, Docker, Git, CI/CD i cloud uz LLM/RAG/agent znanje. HCS traži full-stack capability kada je potrebno. AI Platform Engineer pozicije traže FastAPI, AsyncIO, Pydantic, Kubernetes i observability. Zato je možda najtačnija definicija mnogih današnjih AI Engineer-a: Software Engineer specijalizovan za probabilističke AI komponente.

Tu je reč „probabilističke“ važnija nego što izgleda

Klasična funkcija 2 + 2 uvek treba da vrati 4.
LLM sistem ne funkcioniše potpuno tako. Isti input može proizvesti različit output. Model se promeni, rezultat se promeni. Prompt se malo promeni, rezultat se promeni. Dodamo dokument u RAG, rezultat se promeni.

Zato testiranje AI sistema zahteva drugačiji mentalni model. Ne proveravamo samo „Da li funkcija radi?“, nego:

• Koliko često radi dovoljno dobro?
• Na kojim slučajevima pada?
• Da li novi prompt popravlja jednu kategoriju, ali kvari drugu?
• Da li novi model vredi dodatnog troška?
• Da li quality raste dovoljno da opravda latency?

Tu ulaze Evals – evaluacije AI sistema. I upravo su evaluacije možda jedna od najvažnijih granica između eksperimenta i AI Engineering-a.

Ako nemate evals, kako znate da je nova verzija bolja?

Recimo da promenite prompt. Probate pet pitanja. Deluje bolje. Deploy. To nije naročito robustan inženjerski proces.

Ozbiljniji sistem ima evaluation dataset. Na primer: 500 realnih pitanja. Za svako postoje: expected behavior, reference answer, criteria, failure class. Nova verzija se pokrene nad tim skupom.
Merimo: correctness, groundedness, relevance, refusal behavior, tool accuracy, latency, cost. Tek tada možemo reći: nova verzija je bolja.

Aktuelni poslovi pod nazivom AI Engineer upravo sve češće eksplicitno zahtevaju evaluation frameworks, monitoring i feedback loops. To nije prompting. To je engineering.

„Radi kod mene“ je posebno opasna rečenica kod AI sistema

Klasičan bug možemo često reprodukovati. Kod LLM aplikacija incident može zavisiti od: model version-a, prompt version-a, retrieval rezultata, tool output-a, conversation state-a, temperature, provider-a.

Ako ništa od toga ne logujete, teško je utvrditi šta se dogodilo. Kod agentic sistema problem postaje još ozbiljniji. Na ITNetwork-u smo nedavno otvorili upravo pitanje „Da li znate šta su vaši AI agenti radili juče?“, analizirajući zašto identitet, traceability i evidencija ljudskog odobrenja postaju kritični kada agent više nije samo chatbot već izvršava akcije. AI Engineer koji ne razmišlja o observability-ju pravi sistem koji će biti vrlo zanimljiv kada prvi put ozbiljno pogreši.

AI Engineer mora da razume cenu, ne samo kvalitet

Još jedna razlika između prototipa i produkcije. Demo koristi najbolji model. Zašto? Jer imamo 20 upita dnevno. Produkcija ima 200.000. Odjednom svaki dodatni token ima cenu. Latency ima cenu. Context window ima cenu. Reranking ima cenu. Pet agentic koraka umesto dva imaju cenu.

Sada treba odlučiti: da li za svaki task koristiti frontier model? Da li neka pitanja mogu na manji model? Da li cache-ujemo odgovore? Da li možemo smanjiti context? Da li batching pomaže? OpenAI-jev ML Engineering opis posla upravo production inference posmatra kroz throughput, latency, compute utilization i cost.

Ako vaš agent reši problem fantastično, ali svaki korisnički zahtev košta 4,70 dolara, možda nemate proizvod. Imate vrlo zanimljiv demo.

Security: trenutak kada „AI wrapper“ postaje pravi sistem

Jednostavna AI aplikacija deluje bezazleno. Korisnik napiše pitanje, model odgovori. Ali kada uvedemo RAG i agente, model dobija pristup: fajlovima, bazama, CRM-u, email-u, internim API-jima, možda produkcionim akcijama.

Sada imamo potpuno novu attack surface (površinu napada). Prompt injection više nije samo: „Ignoriši prethodno uputstvo.“ Može postati: „Uzmi poverljive podatke iz povezanog sistema i pošalji ih napadaču.“

Agent Engineer zato mora da razume: least privilege, authentication, authorization, sandboxing, tool permissions, input validation, data exfiltration, secret management. Jedna aktuelna Applied AI Engineer pozicija eksplicitno traži prompt-injection screening, sprečavanje tool misuse-a, zaštitu od data exfiltration-a i risk-stratified pristup alatima.
Ovo nije prompt trik. Ovo je security engineering.

Gde se onda završava Backend, a počinje AI Engineering?

Verovatno ne postoji savršeno oštra granica. I to je u redu. Sličan problem imamo i sa: DevOps Engineer, Platform Engineer, Cloud Engineer, Data Engineer. Profesije se preklapaju. Dobro je zamisliti spektar:

Svi mogu legitimno raditi „AI“. Ali nisu ista profesija.

A gde je Data Scientist?

Data Scientist tradicionalno je fokusiran na analizu podataka, statističko modelovanje, eksperimente, predikcije i interpretaciju. Machine Learning Engineer češće uzima model i pretvara ga u pouzdan produkcijski sistem. AI Engineer u generativnom kontekstu često kreće sa već gotovim foundation modelom i pravi aplikativni sistem oko njega.

Granice se naravno preklapaju. Ali reći „Svi oni rade AI“ otprilike je isto kao reći „Svi rade web“ za frontend, backend i DevOps. Tačno, i gotovo beskorisno.

Najveći problem naziva „AI Engineer“ jeste što skriva senioritet

Junior može za vikend da napravi impresivan LLM demo. To je jedna od stvari koje ovu tehnologiju čine fantastičnom. Ali demo skriva veliku količinu kompleksnosti. Možete napraviti RAG bez razumevanja information retrieval-a. Agenta bez razumevanja distributed systems-a. AI aplikaciju bez razumevanja security-ja. I neko vreme će raditi.

Problem dolazi kasnije kada treba: skalirati, debugovati, optimizovati, auditiovati, kontrolisati trošak, garantovati prava pristupa. Zato će možda najveća razlika između junior i senior AI Engineer-a biti ista kao kod klasičnog softvera: junior zna kako da napravi da radi. Senior razmišlja: „Kako ovo može da se pokvari?“

Da li AI Engineer mora da zna matematiku?

Odgovor je: zavisi šta pod AI Engineer podrazumevamo. Ako trenirate i optimizujete ML modele – da, ozbiljno razumevanje linearne algebre, verovatnoće, statistike i optimizacije je veoma važno. Ako gradite LLM aplikacije nad komercijalnim API-jima, možete biti izuzetno produktivni bez toga da ručno izvodite backpropagation.

Ali to ne znači da matematika nema vrednost. Razumevanje probabilističkog output-a, embedding prostora, similarity funkcija, evaluation metrika, precision/recall odnosa može praviti ogromnu razliku. Dakle, ne morate znati matematiku da pozovete GPT API, ali matematičko i ML znanje apsolutno povećava vaš plafon kao AI inženjera.

Mora li AI Engineer da zna da trenira LLM?

Ne. Velika većina kompanija nikada neće trenirati foundation model od nule. Niti bi trebalo. Cena compute-a, podataka i stručnosti ogromna je. Njihov posao biće da postojeće modele pretvore u korisne, bezbedne, merljive i ekonomski opravdane proizvode. To je legitiman engineering. Web developer ne mora da napravi browser engine, a Backend developer ne mora da napiše PostgreSQL. Ipak, morate razumeti dovoljno sloja ispod sebe da znate njegova ograničenja.

„Wrapper“ nije uvreda – dok znate da pravite wrapper

Termin AI wrapper koristi se pomalo podrugljivo. Ponekad je kritika opravdana, ali ponekad nije. Mnogo vrednih softverskih proizvoda su, u suštini, pametni slojevi preko drugih sistema. Problem nije wrapper. Problem je ako je jedina vrednost proizvoda: jedan prompt + jedan API call + novi logo.

Dobar AI proizvod može koristiti isti model kao konkurencija, ali imati potpuno drugačiju vrednost zbog proprietary data, workflow integracije, UX-a, evaluacije, domain knowledge-a, security-ja i distribution-a. Model nije uvek proizvod. Često je komponenta.

Možda će „AI Engineer“ završiti kao „Web Developer“

Ranih godina weba, naziv „webmaster“ pokrivao je skoro sve (HTML, server, dizajn, SEO). Kasnije se tržište specijalizovalo na Frontend, Backend, Full-stack, DevOps.

Možda se upravo to događa sa AI Engineering-om. Danas govorimo: AI Engineer. Za nekoliko godina verovatno ćemo mnogo preciznije koristiti: LLM Engineer, RAG Engineer, Agent Engineer, AI Platform Engineer, AI Safety Engineer, AI Evaluation Engineer, Inference Engineer, ML Engineer. Već sada vidimo takvu fragmentaciju na tržištu rada. Nazivi polako sustižu stvarni posao.

Šta bi ozbiljan AI Engineer trebalo da zna 2026?

Ne mora biti ekspert za sve, ali za produkcijski LLM/AI engineering očekuje se solidna osnova u:

• Software Engineering: Python, API design, Git, Testing, CI/CD, Docker, Databases.
• LLM fundamentals: Tokeni, Context window, Temperature, Structured outputs, Tool calling.
• RAG: Embeddings, Chunking, Vector search, Metadata, Hybrid retrieval, Reranking, Evaluation.
• Agents: State, Tools, Memory, Planning, Permissions, Termination, Human-in-the-loop.
• Evals: Golden datasets, Regression evaluation, Groundedness, Correctness, Latency, Cost.
• Production: Logging, Tracing, Monitoring, Fallback, Rate limiting, Caching.
• Security: Prompt injection, Access control, Secrets, Data leakage, Tool abuse.
• Business: Znati kada NE treba koristiti AI.

Ovo poslednje će verovatno razlikovati ozbiljnog inženjera od AI entuzijaste

Nije svaki problem AI problem. Ako rezultat mora biti 100% deterministički, obična funkcija možda je bolja. Ako postoji pet jasnih pravila, rules engine možda je bolji. Dobar AI Engineer ne pokušava da stavi LLM svuda. On ume da kaže: „Ovde je običan kod bolji.“ To je znak zrelosti profesije.

AI Engineering i AI-native Software Development nisu ista stvar

Na ITNetwork-u smo u tekstu „AI-native Software Development: kako izgleda Agile kada je AI ugrađen u ceo razvojni ciklus“ napravili važnu razliku. Developer koji koristi AI coding agent za pisanje funkcija, testova i refactoring nije automatski AI Engineer. On može biti Java developer koji koristi AI-native development workflow. AI Engineer je osoba čiji je predmet inženjeringa sam AI sistem ili AI funkcionalnost proizvoda.

Agentic AI dodatno će zaoštriti razliku

Što agenti postaju sposobniji, sve će manje biti dovoljno „povezati model“. Agent dobija cilj, alate, dozvole, podatke, memoriju, mogućnost akcije. AI Engineer polako dobija odgovornost za nešto između backend sistema, workflow engine-a, ML komponente i digitalnog izvršioca.

A Joombooz ugao: klijenta ne zanima titula – zanima ga radi li sistem

Sa poslovne strane, klijentu nije naročito važno da li osoba ima naziv AI Engineer, Prompt Engineer, ili LLM Developer. Njega zanima: Da li sistem radi? Da li štedi vreme? Koliko košta? Da li su podaci bezbedni? Šta se dešava kada pogreši? Na Joombooz-u smo naglasili da vrednost ne dolazi iz toga što neko „koristi AI“, već iz toga da razume gde ga ima smisla primeniti. Titula ne pravi inženjera. Odgovornost za sistem pravi inženjera.

Hoće li AI Engineer biti jedna od glavnih IT profesija narednih godina?

Vrlo verovatno – ali možda ne dugo pod tim imenom. Sada smo u fazi konsolidacije. Kompanijama treba neko ko ume da uzme poslovni problem, izabere odgovarajući model, poveže ga sa podacima, napravi RAG, postavi evaluacije i deployuje sistem. Tržište rada već pokazuje tu potrebu. Ali kako se disciplina razvija, verovatno će postati preširoka za jedan naziv.

A šta ćemo sa ljudima koji samo pozivaju API?

I to je potpuno legitimno. Nije svaki projekat istraživački laboratorijski sistem. Ponekad kompaniji zaista treba poziv API-ja, dobar prompt, nekoliko poslovnih pravila i jednostavan interfejs. Overengineering nije znak stručnosti. Ali važno je biti pošten prema nivou kompleksnosti. Napraviti GPT wrapper za vikend i nazvati sebe „Senior AI Engineer“ slično je kao napraviti WordPress sajt i proglasiti se Distributed Systems Architect-om.

Kako bih ja razlikovao „API developera“ od pravog AI Engineer-a?

Postavio bih mu nekoliko pitanja:

• Kako meriš kvalitet sistema?
• Šta radiš kada model halucinira?
• Kako razlikuješ retrieval failure od generation failure-a?
• Šta se događa kada promenimo model?
• Kako kontrolišeš cenu?
• Kako modelu daješ prava pristupa?
• Kako sprečavaš prompt injection kroz eksterni dokument?
• Kako reprodukuješ produkcionu grešku?

Ako osoba ima dobre odgovore – imamo ozbiljan razgovor. Ako odgovor glasi: „Koristimo LangChain“, nismo još odgovorili ni na jedno pitanje. Framework nije znanje.

Budućnost profesije: manje promptovanja, više sistemskog razmišljanja

Mislim da će se do kraja decenije dogoditi zanimljiv obrt. U budućnosti će veliki deo optimizacije prompta i konteksta biti apstrahovan i automatizovan. Tada će ljudski AI Engineer sve više raditi na sistemskoj arhitekturi, podacima, rizicima, integracijama i ekonomici. Što modeli postaju pametniji, AI Engineer će morati manje da „priča sa AI-jem“, a više da projektuje sistem u kome AI bezbedno radi.

AI će možda sam napisati većinu AI integracije

Ako je vaš jedini posao napraviti API poziv, to je vrsta posla koju AI coding agent već odlično automatizuje. Najslabija verzija AI Engineer pozicije može biti među prvima koju AI učini manje vrednom. Ali što se krećemo ka bezbednosti, evaluaciji i produkcionoj pouzdanosti, odgovornost raste.

Srbija ima zanimljivu priliku

Aktuelni oglasi u Srbiji već pokazuju da se tržište pomera od generičkog „AI iskustva“ ka konkretnim produkcionim zahtevima (RAG, agenti, evaluacija). Backend developer sa dobrim sistemskim znanjem, Python-om, cloud-om, RAG-om i evaluacijom može postati veoma tražen profil, jer kompanije traže nekoga ko može da kaže: „Da, ovo možemo pustiti stvarnim korisnicima.“

AI Engineer jeste stvaran – ali LinkedIn titula nije dokaz

Verovatno ćemo još neko vreme gledati inflaciju naziva. Neki će graditi izuzetno kompleksne produkcione sisteme, neki će praviti odlične jednostavne automatizacije, a neki će imati samo odličan LinkedIn headline.

Ali ispod marketinških naziva polako nastaje vrlo jasna podela rada. Machine Learning Engineer radi bliže modelu. LLM Application Engineer gradi proizvod oko modela. RAG Engineer rešava grounding i retrieval. Agent Engineer gradi sisteme koji mogu da planiraju i deluju. Backend Engineer gradi infrastrukturu na kojoj sve to opstaje.

Nijedan od njih sam po sebi nije „pravi AI“, dok su ostali lažni. Pravo pitanje je dubina odgovornosti. Pozvati API zaista jeste lako. Napraviti sistem koji koristi isti API, a zatim pouzdano služi deset hiljada korisnika, pretražuje hiljade dokumenata, meri kvalitet, prati cenu i bezbedno otkazuje kada nešto krene naopako – nije. Tu počinje engineering.

AI Engineer je ozbiljna nova profesija onoliko koliko je osoba iza te titule ozbiljan inženjer. Najbolji AI Engineer narednih godina verovatno neće biti čovek koji zna najviše promptova. Biće onaj koji najbolje razume kada koristiti model, kada koristiti običan kod, kako kontrolisati rizik i kako napraviti da sistem radi i onda kada demo više niko ne gleda.

FAQ

Šta je AI Engineer?
AI Engineer je širok naziv za inženjera koji projektuje, razvija, integriše i održava AI sisteme u produkciji. U praksi može obuhvatati LLM aplikacije, RAG, agente, klasični ML, evaluaciju, deployment i AI platform infrastrukturu.

Da li je AI Engineer isto što i Machine Learning Engineer?
Ne nužno. Machine Learning Engineer češće radi sa treniranjem, evaluacijom, optimizacijom, deployment-om i inference-om samih modela, dok mnogi AI Engineer-i koriste gotove foundation modele i grade aplikativni sistem oko njih.

Da li je developer koji koristi OpenAI API AI Engineer?
Samo korišćenje API-ja nije dovoljno da definiše profesiju. Ako osoba pored integracije projektuje RAG, evaluaciju, monitoring, sigurnost, agentske workflow-e i production infrastrukturu, naziv AI Engineer ima mnogo više smisla.

Šta radi LLM Application Engineer?
Gradi aplikacije u kojima je LLM važna komponenta: upravlja context-om, promptovima, structured outputs, tool calling-om, RAG-om, integracijama, evaluacijama i produkcionim ponašanjem sistema.

Šta radi RAG Engineer?
Projektuje retrieval pipeline: chunking, embeddings, vector ili hybrid search, metadata filtering, reranking, grounding, permissions i evaluaciju kvaliteta pretraživanja.

Da li RAG potpuno sprečava hallucinations?
Ne. RAG može smanjiti hallucinations i poboljšati grounding, ali pogrešan retrieval ili pogrešna interpretacija izvora i dalje mogu proizvesti netačan odgovor.

Šta radi Agent Engineer?
Projektuje AI sisteme koji mogu da planiraju više koraka, koriste alate, čuvaju state i memory i izvršavaju akcije. Pored LLM znanja mora da rešava permissions, observability, failure handling, loops, security i human approval.

Da li je Prompt Engineer još uvek relevantna profesija?
Prompting je i dalje relevantna veština, ali sve više postaje deo šireg LLM/AI Engineering-a. Fokus se pomera ka Context Engineering-u, evaluacijama, RAG-u i arhitekturi sistema.

Šta je Context Engineering?
Context Engineering je projektovanje informacija koje model dobija u trenutku izvršenja: system instructions, istorija, podaci, retrieved dokumenti, tool rezultati, memory i druga ograničenja potrebna za kvalitetan odgovor.

Mora li AI Engineer da zna matematiku?
Zavisi od oblasti. Za Machine Learning Engineering duboko znanje statistike i linearne algebre je važno. Za LLM Application Engineering može se raditi i sa manje matematičke dubine, ali razumevanje ML principa značajno povećava kvalitet rada.

Mora li AI Engineer da zna da trenira LLM od nule?
Ne. Većina kompanija neće trenirati foundation modele. Veliki deo AI Engineering-a odnosiće se na pretvaranje postojećih modela u pouzdane poslovne proizvode.

Šta su AI Evals?
AI Evals predstavljaju sistematske evaluacije ponašanja modela ili kompletnog AI sistema kroz definisane test slučajeve i metrike poput correctness-a, groundedness-a, retrieval kvaliteta, latency-ja i troška.

Zašto je Backend Engineering važan za AI?
Zato što AI aplikacija u produkciji i dalje zahteva API-je, baze, autentifikaciju, caching, queues, error handling, CI/CD, monitoring i security. LLM ne uklanja klasične softverske probleme.

Šta je LLMOps?
LLMOps predstavlja skup procesa za deployment, verzionisanje, evaluaciju, monitoring, observability i upravljanje LLM aplikacijama, slično ulozi MLOps-a kod tradicionalnih Machine Learning sistema.

Da li će Agent Engineering postati posebna profesija?
Vrlo verovatno. Već postoje pozicije posebno fokusirane na Agentic Systems, agent orchestration, RAG, tools, memory, evals i bezbedno izvršavanje akcija.

Koja znanja su najvažnija za AI Engineer-a?
Za produkcijske LLM sisteme posebno su važni Software Engineering, Python, API-ji, baze, RAG, evaluacija, agentic workflows, cloud, observability, security i sposobnost procene kada AI uopšte nije najbolje rešenje.

Kako prepoznati ozbiljnog AI Engineer-a?
Ne po broju framework-a na CV-ju, već po tome da li ume da objasni kako meri kvalitet, kontroliše hallucinations, testira agente, štiti podatke, prati troškove, reprodukuje greške i odlučuje kada koristiti LLM, ML ili klasični kod.

Hoće li AI Engineer zameniti Backend Engineer-a?
Ne. Pre će se uloge delimično preklapati. Mnogi AI Engineer-i će zapravo biti snažni Software/Backend Engineer-i sa dodatnim znanjem o probabilističkim modelima, RAG-u, agentima i evaluaciji.

Ima li potražnje za AI Engineer-ima u Srbij?
Da. Aktuelni oglasi u Srbiji traže AI Engineer, LLM Application Engineer, AI Platform Engineer i Agentic Systems profile sa produkcionim iskustvom u RAG-u, agentima, evaluaciji, cloud-u i backend razvoju.