Šef: „Upravo sada, Alibaba potpuno zabranjuje Claude, da li da pratimo trend?” Ja: „Upravo sam ozbiljno učio osnove Claude Code-a, nemoj da pretpostaviš.”
Otkrio sam.
Kada pišemo Claude Code, svi traže Codex, a kada pišemo Codex, svi traže Claude Code.
Zato moj savet je da prelistate istorijske članke, zapravo sam već napisao prilično o Claude Code-u i Codex-u.
Naravno, video za Claude Code će vam takođe pomoći da pripremite.
Otkriće 2.
Većina ljudi ima poimanje Claude Code-a koje se i dalje zaustavlja na „terminal Agent koji može da čita i piše kod”. Ali on može da radi mnogo više od toga. Ako ga želite zaista savladati, morate duboko da prekopate po osnovi.
Da li ste razmišljali?
Nakon što u terminalu pritisnemo Enter, šta radi Claude Code? Koja je razlika u odnosu na tradicionalni CLI?
01. Razlika između CC i tradicionalnog CLI-ja
Ponašanje tradicionalnog CLI-ja je determinističko.
grep pretražuje tekst, curl šalje zahtev, git upravlja verzijama. Šta svaka komanda radi, kako radi, u kom formatu izbacuje izlaz, pre izvršenja je već utvrđeno. Ulaz isti, izlaz sigurno isti.
Način rada Claude Code-a je potpuno drugačiji.
On prima deo prirodnog jezika, sam odlučuje koje alatke treba da pozove, prema trenutnoj situaciji planira redosled izvršenja, a zatim kontinuirano iterira dok zadatak ne bude završen.
Obratite pažnju na reči „kontinuirano iterira”.
Tekstualno kratak opis.
Korisnički unos ulazi u Query Loop → poziva API modela → model vraća instrukciju za poziv alatke → izvršava alatku → rezultat izvršenja se dodaje u kontekst → kontekst se ponovo prosleđuje modelu → model odlučuje da li da nastavi sa pozivom alatke ili da završi. Uslovi za kraj su: model se sam zaustavi, spoljašnje ograničenje okine (budžet tokena istrošen, maksimalan broj rundi, korisnik prekida) itd.
Ceo sistem počiva na šest jezgara:
- Query Loop, centar sistema, pokreće petlju Agent-a
- Tool System, registracija, raspoređivanje i izvršenje alatki
- Tasks, jedinica pozadinskog rada, uglavnom pod-Agent
- Memory, persistirani kontekst van sesija, podeljen na nivou projekta, korisnika, tima, pri pokretanju sesije LLM filtrira memoriju relevantnu za trenutni razgovor i ubacuje u kontekst
- Hooks, korisnički definisani hook-ovi životnog ciklusa, podržavaju shell komande, jednokratne LLM pozive, višekratne razgovore Agent-a, HTTP webhook, četiri načina izvršenja
Zapravo, svi Agent alati, bilo terminal ili desktop, rade slične stvari.
02. Query Loop
Query Loop je jezgro celog Claude Code-a.
Suštinski je asinhroni generator (async generator).
Možda vam async generator nije poznat, ali ako ste koristili Python yield ili Java Iterator, princip je isti. Jednostavno, on ne procesira sve rezultate odjednom pa vrati, već tokom rada proizvodi događaje prema van.
U pseudokodu otprilike ovako:
for await (const event of query(input)) {
render(event)
}Spoljašnja strana potroši jedan događaj, pa unutrašnja strana proizvede sledeći.
Ovaj mehanizam donosi tri prednosti.
Prvo. Ako ste koristili TCP klizeći prozor, ovaj koncept će vam biti posebno poznat. Kada prijemnik ne može da obradi, pošiljalac ne može neograničeno da šalje podatke.
Generator režim Query Loop-a je isti princip. Kada UI rendering ne može da prati brzinu izlaza modela, generator se automatski pauzira. Da je callback, brzina proizvodnje događaja unutra je potpuno van kontrole spolja, akumulacija poruka znači katastrofu.
Drugo. Korisnik pritisne Ctrl+C, ili se budžet tokena potroši, tada model možda još radi, alatka možda još izvršava.
Da je callback, otkazivanje znači da ručno pratiš svaki registrovani callback i jedan po jedan ukidaš, propustiti jedan znači curenje memorije. Ali generator samo jednom pozove .return().
Treće. Query Loop vraća 6 razloga za prekid.
- Normalan završetak (end_turn)
- Korisnik prekinuo (user abort)
- Budžet tokena istrošen (budget exhaustion)
- Intervencija Stop Hook-a (hook intervention)
- Maksimalan broj rundi (max turns)
- Nepovratna greška (unrecoverable error)
Pozivalac nakon što dobije povratnu vrednost uradi pattern matching, i tačno zna zašto se petlja zaustavila, ne mora da proverava razne globalne flag-ove. Da je callback, da li je korisnik otkazao, alatka pala ili sistem crkao, postaje nejasno.
Pošto razumemo dizajn generatora, hajde da u potpunosti prođemo putanju zahteva. Uzmimo instrukciju „dodaj obradu grešaka funkciji za prijavu”.
- Korisnik u terminalu unese zadatak, pritisne Enter
- Poruka se predaje Query Loop-u
- Query Loop poziva API modela
- Model strimovano vraća sadržaj i instrukcije za poziv alatke
- Model ukazuje na poziv Read alatke za čitanje funkcije prijave
- Rezultat izvršenja se dodaje u istoriju poruka, okida sledeća iteracija
- Model ukazuje Agent-u da pozove Edit alatku za izmenu koda
- Model procenjuje da je zadatak završen, ne generiše više pozive alatki, generator vraća Terminal
Uobičajena implementacija Agent-a to radi ovako, model prvo kompletno izbaci jedan odgovor, Agent pogleda odgovor i vidi pozive alatki u njemu, pa počne da izvršava alatke, nakon završetka alatki rezultat se vraća modelu.
Claude Code ne radi tako.
Ima StreamingToolExecutor, čim vidi da su parametri poziva jedne alatke već generisani, i ta alatka je deklarisala konkurentnu bezbednost, može prvo da je izvrši, ne čeka da model završi sav sledeći sadržaj. Model još uvek generiše sledeće tokene, datoteka je možda već pročitana.
Koja je cena ovog pristupa?
Ako model kasnije promeni prethodni rezultat, onda su prethodni izvršeni pozivi alatki uzaludni. Ali u stvarnom radu se to retko dešava, tokeni su već izašli, kasnije je velika verovatnoća da će se nastaviti na toj odluci. Claude Code mogućim troškom malog broja izgubljenih ciklusa zamenjuje smanjenje overall latencije.
Ali nisu sve alatke pogodne za spekulativno izvršenje.
Read, Grep i ovakve operacije samo za čitanje deklarisale su konkurentnu bezbednost, mogu da rane. Write, Bash i ovakve alatke koje menjaju stanje moraju serijski da čekaju.
To vodi sledećem pitanju, kako je organizovan sistem alatki?
03. Sistem alatki i pod-Agent
Alatka je ono što Agent može da uradi u svetu računara.
Čitanje datoteka, pokretanje shell komandi, izmena koda, pretraživanje sadržaja veba, sve su alatke.
Tradicionalni pristup je napraviti centralni menadžer, objedinjeno registruje alatke, raspoređuje zadatke, radi provere dozvola. Claude Code je drugačiji, svaka alatka sama deklariše sve o sebi.
Svaki Tool implementira interfejs u 5 dimenzija.
- Identity, kako se zovem, šta mogu da radim
- Schema, koje parametre prihvatam (definicija JSON Schema)
- Execution, moja logika izvršenja
- Permissions, koji nivo autorizacije je potreban pre upotrebe mene
- Rendering, kako se proces i rezultat prikazuju u terminalu
Ako ste pisali kod Spring okvira, možete uporediti, pomalo liči na pristup @Component plus custom anotacija Spring-a.
Komponenta sama deklariše svoju sposobnost, kontejner je zadužen samo za skeniranje i raspoređivanje, bez centralne tabele konfiguracije.
Logika batch obrade izvršenja alatki je takođe promišljena.
Kada model jednom vrati više poziva alatki, sistem prvo grupiše, deklarisane konkurentno bezbedne idu u konkurentnu grupu i startuju istovremeno, nedeklarisane idu u serijsku grupu i izvršavaju se jedan po jedan.
Nazad na sposobnost kompozicije Agent-a.
Svaki Task Claude Code-a prati stanje mašine: pending → running → completed | failed | killed.
Zadužen za kreiranje Task-a je AgentTool. AgentTool radi sledeće: generiše novu instancu Query Loop-a. Obratite pažnju, u pitanju je isti Query Loop, samo ova nova instanca ima nezavisnu istoriju poruka, nezavisan set alatki, nezavisan režim dozvola.
To znači da su multi-Agent i glavni Agent u Claude Code-u više instanci iste Agent petlje.
Glavni Agent pokreće Query Loop, Sub-agent takođe pokreće Query Loop, samo su im istorija poruka izolovana, dozvole različite.
Napomena: Pod-Agent podrazumevano ima režim dozvola bubble. Bubble je balon, zamislite sliku balona u vodi koji stalno ide prema površini. Kada Sub-agent naiđe na opasnu operaciju (na primer brisanje datoteke, izmena git istorije), mora da prijavi, konačno korisnik odlučuje.
Podseća na Java model delegiranja roditelju.
04. Režim dozvola
Claude Code može na mašini da izvrši bilo koju shell komandu, može da menja datoteke, pokreće pod-procese, šalje mrežne zahteve, menja git istoriju. Bez sistema dozvola koji kontroliše Agent-a, posledice su nezamislive.
Njegova kontrola dozvola nije zasnovana na kontrolnim tačkama.
U kodu nema if (hasPermission('write_file')) ovakve uslovne procene. Definiše skup režima dozvola, sve odluke o dozvolama idu kroz rutiranje režima.
Iz izvornog koda, ukupno postoji 7 nivoa režima, poređani od najliberalnijeg do najstrožeg.
| Režim | Ponašanje |
|---|---|
bypassPermissions | Sve propušta, bez provere (samo za interni test) |
dontAsk | Sve operacije propušta ali beleži log |
auto | Lagani LLM klasifikator na osnovu konteksta razgovora procenjuje propuštanje ili odbijanje |
acceptEdits | Izmena datoteka automatski odobrena, ostale između zahtevaju potvrdu korisnika |
default | Standardni interaktivni režim, izmene zahtevaju potvrdu korisnika |
plan | Režim samo za čitanje, sve operacije pisanja blokirane |
bubble | Odluka se prijavljuje nadređenom Agent-u |
Od ovih 7, bypass, dontAsk, acceptEdits, plan su statičke strategije, logika ukucana. default je ljudska potvrda. bubble je bacanje nagore.
Zanimljiv je režim auto (ja obično koristim ovaj režim, da ne bih stalno potvrđivao).
Unutrašnja implementacija auto režima nije hardkodirano pravilo, već pokreće lagani LLM klasifikator. Ulaz ovog klasifikatora je kompletni kontekst trenutnog razgovora, izlaz je binarna procena: da li je trenutna operacija u skladu sa originalnom namerom korisnika.
Na primer, korisnik kaže „pomozi mi da refaktorišem obradu grešaka modula login”. Agent želi da izmeni login.ts, klasifikator procenjuje da je u skladu sa namerom korisnika, propušta.
Agent želi da pročita test datoteku da vidi pokrivenost testova, takođe propušta.
Ali ako Agent želi da obriše config.yaml ili izmeni SSH konfiguraciju, klasifikator otkriva da korisnik nikada nije spomenuo te datoteke, odbija.
Suštinski, auto režim je između „potpuno ručna potvrda” i „potpuno otvorene dozvole”, dodatni sloj automatskog odobravanja.
Koristi sposobnost semantičkog razumevanja LLM-a da proceni razumnost operacije, mnogo fleksibilnije od hardkodiranih pravila. Cena je što svaka provera dozvole zahteva dodatni poziv modela, ali klasifikator koristi laki model, latencija je pod kontrolom.
Rešavanje dozvola ima i sloj prioriteta dizajna.
Sistem prvo proverava da li je korisnik u Hooks konfigurisao pravilo koje odgovara trenutnoj operaciji. Ako pogodi Hook pravilo, izvršava direktno po Hook-u, ne ulazi u procenu režima dozvole. Tek kada ne pogodi nijedan Hook, ide u logiku rutiranja režima dozvole.
To daje korisniku precizan ulaz za prepisivanje.
Operacije kojima verujete upišite u Hook i propustite direktno, bez svake potvrde. Operacije koje Hook ne pokriva, i dalje su pod kontrolom režima dozvole. Opseg pokrivanja je lokalni, strategija podmetanja je globalna.
ending
U eri AI-ja, sudbina svakog pojedinca je različita.
Neki uz pomoć AI-ja uzleću, neki se muče, neki ispadaju.
Po mom ličnom iskustvu, nema potrebe da budete previše strogi prema sebi, jer algoritam, kad vas voli, ludo vas voli, sve što uradite je u redu.
Kad vas ne voli, koliko god se trudili ne pomaže.
Malo je osećaj više sile, baš kao Fable 5.
Kad može da se koristi, koristite, kad ne može, insistediranje ne pomaže.
Procenjujem da će Opus 4.6 i GPT-5.5 možda biti najvrhunskiji modeli koje možemo da uživamo duži period.
Bar nekoliko meseci.
Koračajte i cenite, iskoristite ove dane, potrošite kvotu.