Tencent intervjuer: "Zašto Claude Code ne koristi RAG za pretragu koda, već grep?" Ja: "Zato što... i sam ne znam", on je zaćutao.

Da li ste se ikada zapitali?

Pretraga koda u Claude Code-u je i brza i precizna, kako to zaista radi?

Proveo sam celo jutro, pažljivo proučavajući podcast glavnog inženjera Anthropic-a Borisa Chernyja, rad naučnog tima Amazona, argumente sa zvaničnog Cursor bloga, kao i izvorni kod Claude Code-a, i sve to raščlanio od početka do kraja.

Vežite sigurnosne pojaseve, polazimo~

01. Kako Claude Code zaista pretražuje kod?

Prvo da odgovorimo na osnovno pitanje: koje alate koristi Claude Code pri analizi codebase-a?

Odgovor je jednostavan — tri alata: Glob, Grep, Read.

Da li ste iznenađeni, da li vam se sviđa?

• Glob odgovara za match po obrascu imena fajla, na primer **/*.java pronalazi sve Java fajlove. Rezultati su sortirani po vremenu izmene.
• Grep pretražuje unutar fajlova, ispod haube koristi ripgrep (alat za pretragu visokih performansi pisan u Rust-u). Na primer, ako želimo da nađemo u kom fajlu se koristi @Transactional anotacija, Grep brzo vraća rezultat.
• Read čita sadržaj konkretnog fajla. Može čitati ceo fajl ili navođenjem opsega linija pročitati samo deo. podržava slike, PDF, Jupyter Notebook, pokrivenost je široka.

Nema vektorske baze, nema Embedding modela, nema procesa gradnje indeksa, nema strategije Chunk shrednje.

Kada Claude Code dobije zadatak, prvo koristi Glob da pogleda strukturu direktorijuma, zatim Grep da pretraži ključne reči, i konačno Read da pročita relevantne fajlove.

Anthropic je interno dao ovoj metodi ime: Agentic Search.

Osnovna ideja je:

Ne prvo graditi bilo kakav indeks, već dozvoliti Agentu da tokom izvršenja zadatka, na osnovu trenutnog konteksta i cilja, dinamički odlučuje šta da pretražuje, kako da pretražuje, i šta da radi nakon pretrage.

Ova tri alata imaju još jednu ključnu osobinu: svi su read-only alati sa isConcurrencySafe = true, mogu se paralelno izvršavati. Claude Code često istovremeno pokreće više Grep pretraga, odjednom skenira više ključnih reči, efikasnost je na maksimumu.

02. Pet problema RAG-a u pretrazi koda

Da bismo razumeli zašto Claude Code ne koristi RAG, prvo moramo da razjasnimo kakve probleme RAG zapravo ima u pretrazi koda.

Prvo: kod nije prirodni jezik, semantička sličnost ovde ne važi.

Osnovna logika RAG-a je pretvaranje teksta u vektore, a zatim korišćenje kosinusne sličnosti za pronalaženje "semantički najbližeg" sadržaja.

Ova logika je sjajna u scenarijima prirodnog jezika, na primer "kako obraditi autentifikaciju korisnika" i "proces prijave korisnika" su semantički blizu.

Ali kod je drugačiji.

createD1HttpClient i buildD1HttpClient su semantički blizu, ali u codebase-u to mogu biti dve potpuno različite funkcije. Mi tražimo ono precizno ime funkcije, a ne "približno" ime funkcije.

Obrnuto, handleAuth i validateJwtToken izgledaju semantički nepovezano, ali ova druga je možda ključna logika koju prva interno poziva. Vektorska sličnost nam neće pomoći da pronađemo ovakav odnos poziva, ali jednostavna grep pretraga validateJwtToken će je precizno locirati.

U svetu koda, precizno podudaranje je mnogo važnije od semantičkog podudaranja.

Ime promenljive, potpis metoda, putanja import-a, ili se potpuno podudaraju, ili je to pogrešno mesto.

Nema "okoordinano tačno".

Drugo: trošak sinhronizacije indeksa je visok

Svi koji pišu kod znaju da se kod neprestano menja.

Upravo promenjeno ime metode, u RAG indeksu je i dalje staro ime. Dodat novi fajl, u indeksu ga nema. Obrisana klasa, i dalje je u indeksu.

Da bi se indeks i kod održali u realnom vremenu sinhronizovanim, potrebno je uraditi inkrementalna ažuriranja, praćenje fajlova, obradu konflikata. Složenost izrade svega ovoga je veća i od samog RAG-a.

A grep prirodno ne postoji taj problem, uvek pretražuje sadržaj fajlova na disku u ovom trenutku. Kod se promenio, grep rezultati prate promenu, ne treba mu nikakav mehanizam sinhronizacije.

Treće: bezbednost i privatnost

RAG zahteva Embedding model za generisanje vektora.

Ovaj model ili radi lokalno (troši računarske resurse), ili poziva remote API (sadržaj koda se šalje na eksterni server).

Codebase je "veoma osetljiv", zasigurno ne želimo da šaljemo kod bilo kojoj third-party usluzi radi generisanja Embedding-a. Lokalno postavljanje Embedding-a opet zahteva visoke troškove procesorskog kapaciteta.

grep direktno pretražuje lokalni disk. Sa stanovišta sigurnosti, ova prednost je devastirajuća.

03. Šta ripgrep čini toliko moćnim

Kada se pomene grep, prva pomisao je verovatno GNU grep na Linux-u.

Claude Code ne koristi to, već ripgrep, moderan alat za pretragu pisan u Rust-u.

Autor ripgrep-a se zove Andrew Gallant, proveo je dve i po godine na Rust engine-u za regularne izraze. Ovaj engine koristi SIMD instrukcije za ubrzanje, jednostavno rečeno, koristi vektorske računske jedinice CPU-a za match teksta, brzina pretrage može da priđe granici memorijske propusnosti.

Uglavnom, u srednjem codebase-u sa desetinama hiljada fajlova, ripgrep-u treba oko 200 milisekundi za pretragu celog teksta.

A za isti zadatak pretrage, kroz RAG proces:

Prvo pošaljite tekst upita Embedding modelu radi generisanja vektora (jedan mrežni round-trip), zatim pretražite vektorsku bazu sa KNN (još jedan mrežni round-trip), a onda rezultat možda još rerangirate (još jedan poziv modela). Čitav lanac ima najmanje 8 koraka, četiri-pet servisa.

ripgrep ima i još nekoliko osobina koje su posebno pogodne za Agente.

On podrazumevano rekurzivno pretražuje ceo direktorijum, automatski preskače fajlove navedene u .gitignore i binarne fajlove, a izlaz rezultata uključuje ime fajla i broj linije. To su upravo informacije koje su Agentu najpotrebnije pri analizi koda.

Grep alat Claude Code-a iznad ripgrep-a dodaje još jedan sloj zaštite. Podrazumevano vraća najviše 250 linija (putem head_limit kontrole), da spreči da jedna pretraga vrati nekoliko hiljada linija koda i razbije kontekstni prozor. Ako ripgrep ima timeout ali ima delimične rezultate, odbaciće poslednju nepotpunu liniju i vratiti već dobijeni deo. Tek ako uopšte nema rezultata, izbacuje se greška timeout-a.

Ovaj dizajn filozofija "vrati koliko god možeš" oštro se razlikuje od RAG-ovog "ili uspeh ili neuspeh".

04. Šta kaže Anthropic zvanično

Izvor informacija za ovaj deo su originalne reči Borisa Chernyja (glavnog inženjera Claude Code-a) iz podcasta Latent Space od 7. maja 2025. Drugi gost u ovoj epizodi bila je Catherine Wu, takođe ključni inženjer Claude Code-a.

Boris je rekao sledeće: Rane verzije Claude Code-a zaista su koristile RAG.

Koristili su Voyage Embedding model i napravili lokalni vektorski indeks. Efekat je bio "ok". Ali kasnije su isprobali drugi način, što je već pomenuti Agentic Search sa Glob + Grep + Read. Pokazalo se da ovaj način na svim pokazateljima potpuno nadmašuje RAG.

Boris je izričito rekao "outperformed everything, by a lot" (nadmašio sve, i to sa velikom razlikom).

Priznao je da se ova procena uglavnom zasniva na "internim vibes", odnosno intuiciji i utisku, uz neke podatke iz internih benchmark-ova.

Boris je naveo ključne razloge za odustajanje od RAG-a.

Prvo je performansa. Agentic Search ima viši kvalitet pretrage. Ovde "kvalitet" nije samo preciznost, već i upotrebljivost rezultata pretrage. grep vraća precizne linije koda i putanje fajlova, Agent ih može odmah iskoristiti; RAG vraća gomilu "relevantnih" isečaka koda, Agent mora još jednom da ih razume i filtrira.

Drugo je jednostavnost. RAG zahteva održavanje sinhronizacije indeksa, obradu inkrementalnih ažuriranja, upravljanje životnim ciklusom vektorske baze. Agentic Search ne zahteva nikakvu predobradu, otvorite codebase i odmah počnete da pretražujete, bez "inicijalizacije indeksa".

05. Potvrda iz Amazonovog papira

U decembru 2025, Amazonov naučni tim objavio je rad pod naslovom: "Keyword search is all you need: Achieving RAG-Level Performance without vector databases using agentic tool use".

Njihov metod je: izgraditi standardni RAG sistem (vektorska baza + Embedding + retrieval + generacija) i Agent sistem sa samo alatom za pretragu ključnih reči, a zatim na istim Q&A zadacima uporediti performansu oba.

Zaključak je: Agent sistem zasnovan na pretrazi ključnih reči može postići preko 90% performansi tradicionalnog RAG sistema.

Rad ima i ključan nalaz: za strukturirani tekst sa preciznim simbolima kao što je kod, pretraga ključnih reči je zapravo bolja od semantičke pretrage. Zato što su konvencije imenovanja koda obično konzistentne, imena funkcija, promenljivih i klasa već nose dovoljno semantičkih informacija, pa nije potrebno dodatno semantičko razumevanje.

06. Protivargument Cursor-a

Ovde će neko možda pitati: ako je grep toliko dobar, zašto Cursor i dalje koristi vektorsku pretragu?

To je dobro pitanje.

Cursor je istrenirao sopstveni Embedding model, izgradio kompletan pipeline indeksa, i koristi Turbopuffer kao vektorsku bazu. Njihovi A/B test rezultati pokazuju: nakon dodavanja semantičke pretrage, tačnost Agenta se znatno poboljšala.

U velikim codebase-ima sa preko 1000 fajlova, poboljšanje je još izraženije, stopa zadržavanja koda (procenat koda koji Agent napiše, a korisnik zadrži) se povećala za 2.6%.

Nekoliko ključnih razlika.

Prvo, Cursor je proizvod na nivou IDE-a, kada korisnik radi u IDE-u, codebase je relativno stabilan, pritisak sinhronizacije indeksa nije tako veliki. A Claude Code je CLI alat, korisnik može u svakom trenutku preći na različite codebase-ove.

Drugo, Cursor koristi hibridnu pretragu, i grep i vektorsku pretragu, ne samo vektorsku pretragu. Njihov zaključak je "najbolje je koristiti ih zajedno", a ne "vektorska pretraga je bolja od grep-a". Ovo obrnuto dokazuje da je grep neophodna osnovna sposobnost.

07. LLM je najbolji Reranker

U arhitekturi Agentic Search-a, LLM sam po sebi deluje kao Reranker.

Tok rada tradicionalnog RAG-a je: Embedding → vektorska pretraga → Rerank → generacija.

Rerank korak postoji da nadoknadi nedostatak preciznosti vektorske pretrage, "Top K" rezultati koje vrati vektorska pretraga često sadrže nevezane stvari, pa je potreban precizniji model da ponovo rangira.

Ali u arhitekturi Claude Code-a, rezultati koje grep vraća su deterministički, pretraga createD1HttpClient će vratiti samo linije koda koje sadrže taj tačan string. Nakon što Agent dobije ove precizne rezultate pretrage, koristi sopstveno rezonovanje LLM-a da proceni koji su rezultati korisni, koji fajl treba dalje čitati, koje ključne reči treba još tražiti.

U ovom režimu, LLM ne radi jednostavan Rerank, već razumevanje + odlučivanje + akcija.

On prilagođava strategiju pretrage na osnovu rezultata prve runde, na primer kada otkrije poziv ključne funkcije, prati poziv da pronađe definiciju pozvane funkcije. Ova višekrugna iterativna sposobnost pretrage je nešto što "jednokružni" režim RAG-a ne može da postigne.

RAG je kao da odete u biblioteku i zamolite knjižničara da vam nađe knjige; knjižničar na osnovu opisa nađe nekoliko "možda relevantnih" i stavi ih na sto, da li su tačne, morate sami da listate da biste saznali.

A Agentic Search je kao da sami odete u biblioteku, prvo pogledate spisak spratova (Glob za strukturu direktorijuma), a zatim idete na odgovarajući sprat da pretražite police (Grep sadržaj), kada nađete, otvorite i pogledate (Read fajl), ako nije dobro, promenite ključnu reč i tražite dalje.

09. Kako napisati biografiju

Naziv projekta: PaiCLI platforma za inteligentnu analizu koda

Kratak opis projekta: Alat za analizu koda zasnovan na Agentic Search arhitekturi, koji koristi grep + LLM umesto tradicionalnog RAG preuzimanja za efikasnu analizu i razumevanje velikih codebase-ova.

Ključne odgovornosti:

• Na osnovu ripgrep-a implementirao full-text pretragu koda na nivou koda, podržava regularne izraze i Glob šeme podudaranja, vreme jedne pretrage je kontrolisano ispod 200ms
• Dizajnirao Agent strategiju višekruzne iterativne pretrage, kroz lanac alata Glob→Grep→Read postupno fokusira kontekst koda, tačnost pretrage preko 95%
• Implementirao pametni mehanizam odsecanja rezultata pretrage (head_limit + partial results), potrošnju tokena jedne pretrage kontrolisao ispod 6K, izbegava preliv konteksta