Šta firme u Srbiji zapravo traže od AI inženjera

Prošle nedelje sam imao tri razgovora sa osnivačima iz Beograda i Novog Sada. Sva tri puta, pitanje koje je stvarno mučilo ljude nije bilo "znaš li LangChain", nego "možeš li ovo da postaviš tako da radi i kad mi ne gledamo". To je razlika koju vidim već neko vreme — firme su prešle fazu eksperimenta i sad traže nekoga ko zna da pretvori demo u sistem koji ne pada.

Pišem ovo iz ugla nekoga ko poslednjih godina gradi autonomne pipeline-ove (sadržaj, SEO, integracije, RAG), pa znam i kako izgleda kad nešto stvarno radi 24/7, i kako izgleda kad pukne u 3 ujutru zato što je neko zaboravio retry policy. Ovo nije lista tehnologija. Ovo je ono što sam video da firme ovde zaista mere kad odlučuju koga da angažuju.

Razlika između "umem da pozovem API" i "umem da napravim sistem"

Najveća zabluda na tržištu je da je AI inženjering pisanje promptova. To je možda 10% posla. Ostalo je klasična softverska arhitektura, samo sa nedeterminističkim komponentama u sredini.

Konkretno, kad firma kaže "treba nam AI agent koji odgovara klijentima", ono što stvarno traže je:

• sistem koji ne halucinira odgovore koje nemamo u bazi
• logovanje svakog poziva (cena, latencija, ulaz, izlaz) da znamo kad nešto pukne
• fallback kad LLM provider padne ili vrati timeout
• način da neko netehnički može da update-uje pravila bez deploy-a
• granica troška — da nas jedan bug ne košta 2000 evra preko noći

Inženjer koji misli da je posao "napiši prompt i pošalji API call" ostavlja firmu da sama rešava sve gore. Inženjer koji isporuči sistem koji pokriva svih pet stvari — taj se zadržava i preporučuje.

Praktično, evo razlike na primeru jednog endpoint-a koji zove LLM:

# Verzija koja "radi" na demou
def answer(question):
    return openai.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": question}]
    ).choices[0].message.content

# Verzija koju firma može da pusti u produkciju
async def answer(question, user_id, trace_id):
    if not await rate_limiter.allow(user_id):
        return FALLBACK_RATE_LIMIT
    
    cached = await cache.get(hash(question))
    if cached: return cached
    
    try:
        async with timeout(8):
            response = await llm.call(
                prompt=build_prompt(question),
                max_tokens=500,
                trace_id=trace_id
            )
        await log_call(trace_id, user_id, question, response, cost=response.cost)
        await cache.set(hash(question), response.text, ttl=3600)
        return response.text
    except (TimeoutError, ProviderError) as e:
        await alert_if_threshold(e)
        return FALLBACK_GENERIC

Druga verzija nije "lepša" — ona je ono što razlikuje sistem od skripte. Firme u Srbiji koje su već prošle prvi krug PoC-eva ovo prepoznaju iz daleka.

Rezultati u satima i evrima, ne u promptovima

Drugi filter koji vidim: firme više ne plaćaju za "implementirao sam AI rešenje". Plaćaju za merljivu uštedu. Najjača rečenica u CV-u AI inženjera danas glasi otprilike ovako:

"Automatizovao sam X proces — ranije je trajao Y sati mesečno, sad traje Z; godišnja ušteda je W evra."

Ja sam, na primer, na jednoj analitičkoj migraciji isporučio između 30 i 60 hiljada evra godišnje uštede, a na ekosistemu od četiri povezane automatizacije skinuo 73+ sata mesečno operativnog rada sa 192% ROI u prvoj godini. To su brojevi koje sam ja merio sa klijentom, ne marketing.

Suština: ako ne znaš da formulišeš svoj rad u jedinicama koje finansijski direktor razume, ti nisi inženjer koji rešava problem — ti si trošak koji se opravdava. Ovo je posebno bitno za srpsko i regionalno tržište gde su budžeti manji nego u Berlinu ili Londonu, pa svaka stavka mora da se brani.

Pre nego što počneš projekat, traži tri broja:

1. Koliko sati mesečno trenutno troši tim na ovo?
2. Koliko košta jedan sat tog tima (puni trošak, ne neto plata)?
3. Koja je cena greške kad se proces uradi pogrešno?

Bez ova tri broja, ne možeš da dokažeš vrednost. Sa njima, razgovor postaje konkretan i ti dobijaš mandat da ideš dublje.

Domenski kontekst je vredniji od još jednog framework-a

Ovo je nešto što vidim svaki put kad neko iz inostranstva pokušava da uđe na regionalno tržište i ne uspeva. Tehnologija je svuda ista — Claude API u Beogradu radi isto kao u Cirihu. Ali znati kako funkcioniše naplata u srpskoj agenciji, kako izgleda Zendesk workflow regionalnog ISP-a, ili zašto e-fakture imaju specifične edge case-ove — to je ono što razdvaja inženjera koji isporuči nešto upotrebljivo od onog koji isporuči generički chatbot.

Kad gradim RAG sistem za firmu, prvih nedelju dana skoro nikad ne pišem kod. Pričam sa ljudima koji rade taj posao. Pitam:

• Koje pitanje ti klijenti najviše puta postave?
• Šta najčešće odgovoriš pogrešno kad si umoran?
• Postoji li dokument koji svi tvrde da imaju, a stvarno niko ne čita?
• Šta bi se desilo ako AI odgovori pogrešno na ovo pitanje?

Ti odgovori određuju arhitekturu. Bez njih biraš vector DB na osnovu Twitter trendova umesto na osnovu stvarne potrebe. Firme to osete na prvi sastanak. Inženjer koji postavlja prava domenska pitanja deluje kao partner. Inženjer koji odmah priča o embeddings dimenzionalnosti deluje kao prodavac.

Sposobnost da kažeš "nemoj AI ovde"

Možda kontraintuitivno, ali jedan od najboljih signala ozbiljnog AI inženjera je da ume da odbije AI rešenje kad nije pravo.

Veliki broj problema koje firme pakuju kao "treba nam AI" su zapravo:

Ne znači da AI nije rešenje za ostatak — znači da na ovim primerima AI dodaje cenu, kompleksnost i tačku otkaza tamo gde deterministički sistem radi posao za desetinu para.

Kad klijentu kažem "ovde nam ne treba LLM, ovo se rešava sa cron job-om za 4 sata rada", izgubim možda kratkoročan prihod, ali dobijem nekoga ko mi se vraća sa ozbiljnijim projektima. To je dugoročni model koji radi u regionu gde se ljudi poznaju i preporuke putuju brzo.

Operativna disciplina: monitoring, troškovi, granice

Ovo je deo koji devetnaest od dvadeset ponuda za "AI inženjera" potpuno preskoči. Sistem koji radi u produkciji mora da ima:

Praćenje troškova po pozivu. Ne mesečno — po pozivu, sa atribucijom na korisnika ili workflow. Bez ovoga, prvi put kad neki bug napravi rekurzivni poziv, dobijaš račun od 4000 dolara i nemaš pojma odakle je došao.

Granice (token rationing). Hard cap na dnevnu potrošnju po korisniku/workflow-u. Kad se pređe — sistem se gasi, ne nastavlja "samo malo više".

Strukturisano logovanje. Svaki LLM poziv loguje trace_id, model, input tokens, output tokens, cenu, latenciju, ishod. Bez ovoga, debug u produkciji je gađanje u mraku.

Evaluacioni set. Skup od bar 50-100 realnih primera sa očekivanim ishodom, koji se vrti pre svakog promene prompta ili modela. Bez ovoga, "popravio sam prompt" znači "pokvario sam tri druga slučaja, ali još ne znam koja".

Fallback strategija. Šta se dešava kad Anthropic ili OpenAI padne (a padaju)? Drugi provider? Cache prethodnih odgovora? Graceful degradation? Mora postojati plan.

Ako AI inženjer pri intervjuu ne pomene ništa od ovoga — gradi ti demo, ne sistem. Razlika između ta dva u troškovima održavanja je 5-10x posle prve godine.

Komunikacija sa netehničkim stejkholderima

Skoro svaki AI projekat u srpskoj firmi prolazi kroz nekoga ko ne razlikuje embedding od JSON-a. To je realnost. CEO, finansijski direktor, šef operacije — ti ljudi donose odluku da li projekat ide dalje.

Inženjer koji ne ume da objasni šta gradi, zašto traje koliko traje, i šta su realna ograničenja — neće dobiti nastavak projekta, bez obzira koliko je kod elegantan. Ovo je veština koja se uči i većina inženjera je podcenjuje jer deluje "ne-tehnički".

Konkretno, ono što radim:

• Pre nego što počnem rad, šaljem jednostranični dokument sa: šta gradim, šta NE gradim, kako će se meriti uspeh, šta su rizici. Klijent potpisuje. Više nema "ja sam mislio da ćeš i ovo".
• Svake nedelje šaljem kratak email sa: šta je gotovo, šta sledi, na šta čekam, koji je trošak do sad. Tri stavke svaka. Ako traje 5 minuta da se napiše, predugo je.
• Kad nešto pukne, prvi sam koji to javi. Sa objašnjenjem šta se desilo i šta sam uradio. Klijenti ne mrze probleme — mrze iznenađenja.

Ova vrsta komunikacije je razlika između inženjera kog firma zove jednom i onog kog zove svaki put kad treba nešto autonomno.

Šta bih ja uradio na tvom mestu

Ako si inženjer u Srbiji ili regionu i hoćeš ozbiljno da uđeš u AI prostor — evo iskrenog redosleda:

1. Sagradi jedan kompletan autonomni sistem od početka do produkcije. Ne tutorial, ne PoC. Nešto što zaista radi sedmicama bez tebe. Naučićeš više iz tih grešaka nego iz deset kurseva.
2. Meri sve. Vreme, cenu, broj uspešnih poziva, broj fallback-ova. Ti brojevi su tvoj CV.
3. Nauči da pišeš i pričaš o tome. Blog post, LinkedIn post, video — nije bitno format, bitno je da postoji javni trag tvog razmišljanja. Firme angažuju ljude o kojima mogu nešto da pročitaju.
4. Specijalizuj se za jedan domen. B2B SaaS, e-commerce, fintech, podrška, sadržaj — bilo koji. Generalisti rade za satnicu. Specijalisti rade za projekat.
5. Reci "ne" kad treba. Tvoja prva godina kao ozbiljnog AI inženjera definisaće se brojem projekata koje si odbio jer nisu pravi fit, ne brojem koje si prihvatio.

Ako si firma i razmišljaš da angažuješ AI inženjera — pitanja na intervjuu koja stvarno razdvajaju ljude:

• "Pokaži mi sistem koji si pustio u produkciju i još radi. Koliko košta mesečno? Kako pratiš da radi?"
• "Kad si poslednji put rekao klijentu da mu AI nije rešenje?"
• "Kako bi me ubedio da projekat ima ROI pre nego što ga počneš?"
• "Šta se dešava ako Anthropic padne na 6 sati?"

Ako odgovori budu maglovita, znaš odgovor.

Zatvaranje

Tržište AI inženjera u Srbiji i regionu sazreva brže nego što mnogi misle. Faza "stavi ChatGPT na sajt" je prošla. Sada se traže ljudi koji razumeju i kod i biznis, i koji isporučuju sisteme koji rade sami, sa brojevima koji se mogu odbraniti pred upravom.

Ako gradiš ozbiljan AI projekat i tražiš nekoga ko ovo radi iz prakse, javi se preko lazar-milicevic.com/#contact. Najkorisnije je kad pošalješ konkretan problem, ne uopšteno pitanje — onda mogu da kažem da li je AI prava alatka za to ili nije.