Intervjuer se nasmejao: "Ove nedelje hocemo samo Loop Engineering, ne Prompt Engineering." Ja: "Samo /loop /goal, ko to ne zna!"

Prompt Engineering, Context Engineering, Harness Engineering — brzina stvaranja novih reči u AI krugovima brža je i od iteracija velikih modela.

Evo, Loop Engineering je upravo izašao.

Neki kažu da je Prompt Engineering manuelni menjač, a Loop Engineering automatski.

Ali po meni, sve je to jedno te isto, važi.

Samo što više ne pišemo jednostavan Prompt pa kad LLM odgovori kucamo sledeću, već nastojimo da napišemo složeniji skup promptova koji tera Agent-a da potroši malo više tokena.

Oh, ne.

Umesto toga, nastojimo da maksimalno iscedimo sposobnost LLM-a, pustimo ga da se sam okreće u petlji, sam pronalazi informacije, sam proverava rezultate, sam prilagođava plan — dok ne postigne cilj.

01. Šta je Loop Engineering

U periodu Prompt Engineering-a, svi su proučavali „kako napisati dobar Prompt" — formulacije, format, neprestano doterivanje kvaliteta jednog unosa.

U periodu Context Engineering-a, fokus se sa onoga „šta napisati" prebacio na „šta model treba da vidi". CLAUDE.md, RAG, sažimanje, upravljanje prozorom konteksta — ključno pitanje postalo je kako u ograničeni prozor konteksta ugurati najvrednije informacije.

Kasnije je Harness Engineering počeo da posmatra Agent-a kao inženjerski sistem za dizajn, obuhvatajući integraciju alata, persistenciju stanja, organizaciju pod-Agenta, sa fokusom na čitav okvir izvršenja.

Loop Engineering stoji iznad Harness-a i rešava kako da se ovaj sistem sam okreće.

Petlja se može sama pokrenuti, zna gde da traži informacije, nakon što završi jedan krug zna kako da proveri rezultate, ako ne uspe zna da li da pokuša ponovo, svaki krup zapisi napredak na određeno mesto, a takođe zna i kada da stane i prepusti čoveku.

Harness je infrastruktura, a Loop je način dizajniranja koji tera infrastrukturu da automatski radi.

02. Šest komponenti petlje

Po mom mišljenju, šest komponenti petlje su: zakazani zadaci, Worktree, Skill, MCP, pod-Agent, Memory.

Ovih šest komponenti čine kompletan tehnički stack Loop Engineering-a. Ne može ni jedna da nedostaje — bez bilo koje od njih ne može se govoriti o pravoj petlji.

Zakazani zadaci

U Claude Code-u, komanda /loop je okidač zakazanih zadataka.

/loop 5m /code-review znači da se na svakih 5 minuta pokreće pregled koda.

Tradicionalni cron izvršava determinističke skripte (izvrši skriptu A, izlaz u datoteku B), dok zakazani zadatak u petlji pokreće sesiju Agent-a.

Agent samostalno odlučuje šta će dalje raditi na osnovu trenutnog konteksta.

Worktree

Worktree dozvoljava kreiranje više radnih direktorijuma pod istim repozitorijumom, gde svaki radni direktorijum odgovara nezavisnoj grani.

U scenariju petlje, jedan Agent menja kod u worktree A, dok drugi Agent radi pregled u worktree B — njihove operacije nad datotekama se ne mešaju.

Bez izolacije, paralelne operacije više Agenta neizbežno dovode do sukoba datoteka.

Claude Code nudi parametar --worktree za pokretanje izolovane instance, a pod-Agent takođe podržava konfiguracionu stavku isolation: 'worktree'.

Kada se omogući, Agent radi u nezavisnom Git worktree-u i izmene ne utiču na glavni radni direktorijum. Ako Agent nije napravio nikakve izmene, worktree se automatski čisti, bez ostavljanja beskorisnih grana.

# Pokrenite Claude Code u izolovanom worktree-u
claude --worktree "Popraviti problem memorijskog curenja iz issue #42"

Skill

Skill je paket veština. Jedna datoteka SKILL.md uz opcionalni direktorijum references/ beleži radne norme, komande za izgradnju, standarde pregleda i načine obrade uobičajenih problema.

Bez Skill-a, Agent ne zna koji alat za izgradnju projekat koristi, ne zna kako se pokreću testovi, ne zna preference stila koda. Skill persistira ove informacije, omogućavajući da svaki krug petlje kreće od iste baze znanja.

I Claude Code i Codex koriste isti Skill format; kada se jednom napiše, Skill mogu direktno koristiti oba alata.

Tipična struktura Skill-a je sledeća.

.claude/skills/daily-review/
├── SKILL.md          # Glavna datoteka: strategija pregleda, format izlaza, kriterijumi
└── references/
    ├── coding-style.md    # Projektna pravila kodiranja
    └── common-bugs.md     # Lista cestih istorijskih bagova

Kada se u svakom krugu petlje učita Skill, Agent zna „po kom standardu pregleda", umesto da „pregleda po osećaju".

MCP

MCP je konektor koji omogućava petlji da izvršava stvarne operacije preko sistema.

Bez MCP-a, Agent može samo da čita i piše lokalne datoteke i izvršava lokalne komande. Sa MCP-om, Agent može da kreira PR, ažurira udaljene zadatke, šalje IM poruke, pretražuje bazu podataka, upravlja pretraživačem.

MCP je postao de facto standard za ekosistem alata Agent-a. Kada se jednom MCP server napravi, i Claude Code i Codex ga mogu priključiti, bez potrebe za zasebnim razvojem plagina za svaki alat.

Cilj petlje često nije samo izmena koda, već uključuje i slanje PR-a, obaveštavanje tima, ažuriranje alatki za upravljanje projektima. Sve ove operacije se obavljaju putem MCP-a.

Na primer, petlja koja se svakog jutra u 9 sati pokreće, skenira sve zastarele zavisnosti u repozitorijumu, automatski kreira PR za nadogradnju, a zatim obaveštava tim u Feishu da pregleda. Ovde „kreiranje PR-a" zahteva GitHub MCP, „slanje Feishu poruke" zahteva Feishu MCP, dok Agent sam preuzima odlučivanje i organizaciju.

pod-Agent

Jedan Agent je zadužen za izmenu (maker), drugi za pregled (checker). Nikada se ne dešava da onaj koji menja sam ocenjuje svoj rad — to je osnovna zdravorazumska pretpostavka u inženjerstvu.

U petlji se ovo razdvajanje ostvaruje putem pod-Agenta.

Mehanizam pod-Agenta u Claude Code-u za svaki podzadatak pokreće nezavisnu ReAct petlju, sa filtriranim registrom alata. Nakon što pod-Agent završi, rezultat se vraća glavnom Agentu na objedinjavanje. U kombinaciji sa worktree izolacijom, više pod-Agenta može paralelno menjati kod bez sukoba.

// maker-checker patern u Workflow skripti
const fix = await agent('Popravi ovu sigurnosnu ranjivost', {
  label: 'maker',
  isolation: 'worktree'
})

const review = await agent('Pregledaj ovo resenje, proveri da li unosi nove probleme', {
  label: 'checker',
  agentType: 'code-reviewer'
})

Maker menja kod u izolovanom okruženju, a checker nezavisno pregleda rezultat izmene. Dva Agent-a se ne ometaju, a ni njihove ocene se ne mešaju.

Memory

Memory je mehanizam kojim petlja održava stanje između krugova.

Model nema memoriju.

Na početku svakog razgovora, sav kontekst iz prethodnog kruga nestaje. Ako petlji u 3. krugu treba da zna šta je izmenjeno u 1. krugu, ta informacija mora biti zapisana izvan modela — na primer u datotečni sistem, bazu podataka ili drugo eksterno skladište.

Datoteka CLAUDE.md i direktorijum memory u Claude Code-u jedna su od implementacija Memory-ja. Na kraju svakog kruga, Agent može zapisati ključne zaključke u datoteke; pri sledećem pokretanju čita te datoteke i može nastaviti od prethodnog napretka.

Memory je među šest komponenti onaj koji se najlakše previdi, a takođe i ključ za to da li petlja može zaista da „akumulira iskustvo". Bez Memory-ja, svaki krug petlje je nezavisan — može se ponavljati, ali ne može učiti iz prošlih izvršenja.

Tipičan scenario: petlja u 1. krugu skenira 10 bagova, popravi 3, a preostalih 7 zapiše u memory/pending-bugs.md. Pri pokretanju 2. kruga čita ovu datoteku i nastavlja da popravlja preostalih 7, umesto da ponovo skenira sve i ponovo otkriva iste bagove.

03. /loop u Claude Code-u

/loop je ugrađena komanda zakazanih zadataka u Claude Code-u, sa sledećom sintaksom.

/loop <interval> <prompt ili slash komanda>

Interval podržava minute (m) i sate (h), podrazumevano 10 minuta, najmanji interval 1 minut. Bez navođenja intervala, /loop /code-review znači izvršavanje na svakih 10 minuta.

Tri stvarna scenarija

Scenarij 1, zakazani pregled koda

/loop 30m /code-review --fix

Svakih 30 minuta skenira trenutni diff, pronalazi potencijalne bagove i tačke optimizacije, a što može automatski popravi — to i radi. Pogodno za održavanje kvaliteta koda tokom dugotrajnog razvoja.

Scenarij 2, praćenje CI statusa

/loop 5m Proveri CI status trenutne grane, ako ima neuspešnih job-ova, analiziraj uzrok i pokusaj popravku

Svakih 5 minuta proverava CI pipeline, i ako otkrije neuspeh, automatsi vrši istragu. Nakon slanja PR-a ne morate da posmatrate CI panel, Agent će pratiti u pozadini.

Scenarij 3, skeniranje tehničkog duga

/loop 4h Skeniraj TODO i FIXME komentare dodate u poslednja 4 sata, organizuj ih u listu i zapisi u docs/tech-debt.md

04. Upotreba Loop-a za odgovaranje na GitHub Issue

PaiAgent je projekat organizacije tokova rada, sličan Coze i dify-ju. Pošto na GitHub-u ima nekih issue-a koji nisu odgovoreni, možemo iskoristiti komandu /loop u Claude Code-u da Agent automatski odgovori na te issue-e.

Sva tri pitanja su veoma jednostavna:

• #6 „Da li je ovaj projekat zavrsen ili je jos uvek u toku?"
• #5 „Koja je razlika u odnosu na PaiFlow"
• #4 „Da li je moguce raditi sekundarni razvoj?"

Ali za tačan odgovor potrebno je poznavanje pozadine projekta.

Upravo je to scenario pogodan za preuzimanje petljom: visoka učestalost ponavljanja, jasna pravila i jasni kriterijumi završetka (issue je tačno odgovoren).

Pokretanje jednom komandom

/loop 30m Proveri open issue u repozitorijumu itwanger/PaiAgent, za issue bez odgovora generisi tacan odgovor na osnovu README-a projekta i postojecih informacija i postavi komentar. Preskoci one na koje je vec odgovoreno, ne komentarisati duplo.

Rastavljajući ovu komandu, svaki deo odgovara jednom elementu dizajna petlje.

30m je frekvencija otkucaja srca, na svakih 30 minuta budi Agent-a.

Onaj deo na prirodnom jeziku je opis zadatka — šta Agent radi u svakom krugu: skenira issue → procenjuje da li je odgovoreno → generiše odgovor → šalje.

„Preskoci one na koje je vec odgovoreno" je mehanizam protiv ponavljanja. Bez te rečenice, Agent bi u svakom krugu ponovo komentarisao sve open issue-e.

Proces izvršenja Agent-a

Nakon što se Agent pokrene, stvarni proces izvršenja izgleda ovako.

Prvi korak: preko GitHub CLI-ja povlači sve naslove, telo i postojeće komentare open issue-a. Ovaj korak zavisi od MCP-a ili komandne linije, što odgovara MCP komponenti od šest.

gh issue list --repo itwanger/PaiAgent --state open
gh issue view 6 --repo itwanger/PaiAgent --json title,body,comments

Drugi korak: Agent procenjuje koji issue zahtevaju odgovor. #3 i #1 već imaju komentare vlasnika, preskaču se; #6, #5, #4 nemaju nijedan odgovor i označavaju se kao na čekanju.

Snimak ekrana je iz druge demonstracije, svi issue su obradjeni

Treći korak: Agent čita README i informacije o repozitorijumu projekta. Potrebno je da zna šta je PaiAgent, koje tehničke stackove koristi, kakav je odnos sa PaiFlow-om, da li dozvoljava sekundarni razvoj — sve te informacije pružaju dokumenti projekta. Ovaj korak odgovara Skill komponenti od šest — persistencija projektnog znanja.

Kvalitet znanja direktno određuje kvalitet odgovora.

Četvrti korak: generiše odgovor i šalje jedan po jedan.

gh issue comment 6 --repo itwanger/PaiAgent --body "Projekat je jos uvek u kontinuiranom razvoju..."
gh issue comment 5 --repo itwanger/PaiAgent --body "PaiAgent i PaiFlow imaju razlicito pozicioniranje..."
gh issue comment 4 --repo itwanger/PaiAgent --body "Naravno, PaiAgent je open source projekat..."

Sva tri komentara su poslata u jednom krugu petlje.

Efekat odgovora

Pogledajte odgovore koje je Agent stvarno poslao.

Odgovor na #6 — pitanje o napretku projekta: Agent je tačno objasnio da je projekat u kontinuiranom razvoju, naveo završene ključne funkcije (vizuelni editor, DAG engine, LangGraph4j engine, Skills sistem, integracija više modela) i dao linkove na tutorijale.

Odgovor na #5 — pitanje o razlici između PaiAgent i PaiFlow: Agent je na nivou arhitekture razdvojio dva projekta — PaiAgent je laka monolitna arhitektura pogodna za učenje, PaiFlow je arhitektura mikroservisa namenjena enterprise produkcionom okruženju. Ovu informaciju je Agent izveo kombinovanjem README-a i istorijskog odgovora vlasnika u #3.

Odgovor na #4 — pitanje o mogućnosti sekundarnog razvoja: Agent je potvrdio da je moguće i dao predloženi tok Fork → razvoj → zadržavanje reference.

Ova tri odgovora nisu šablonsko odmeravanje, već su generisana na osnovu stvarnog stanja projekta.

Koje je komponente ova petlja iskoristila

Da se vratimo na šest komponenti.

• Zakazani zadaci: /loop 30m pruža otkucaj srca na svakih 30 minuta
• MCP: preko GitHub CLI-ja čita issue, šalje komentare, povezuje eksterne sisteme
• Skill/projektno znanje: README i metapodaci repozitorijuma pružaju Agentu kontekst potreban za odgovore
• Memory: Agent proverom postojećih komentara procenjuje da li se ponavlja, izbegavajući da jedan issue bude odgovoren više puta

Worktree i pod-Agent u ovom scenariju nisu korišćeni — jer ne obuhvataju paralelne izmene koda niti zahtevaju razdvajanje čitanja i pisanja.

Još jedan korak dalje

Ovaj demo je samo najprostiji nivo. Može se uraditi mnogo više.

Prvo, dodati Skill datoteku issue-reply-guide.md koja definiše ton odgovora, format, koja pitanja treba proslediti na ručnu obradu — Agent onda ne samo da odgovara na pitanja, već odgovara po vašim standardima.

Drugo, dodati Memory, omogućavajući Agentu da pamti informacije poput „#5 pitaoca zanima arhitektonski izbor". Kada sledeći put uđe slično pitanje, Agent može direktno citirati prethodni odgovor, umesto svaki put da polazi od početka.

Treće, dodati pod-Agenta, jednog zaduženog za klasifikaciju issue-a (bug report, feature request, usage question), drugog za generisanje odgovora. Ocena klasifikacionog Agent-a određuje koju strategiju će koristiti Agent za odgovore — na pitanja o upotrebi citira dokumentaciju, a pri potvrdi bagova daje korake za istragu.

Počevši od jedne /loop komande, postepeno dodajući komponente, granice moći petlje se tako proširuju.

05. Cena petlje

Pre nego što uđete u petlju, tri pitanja morate jasno da razmotrite.

Potrošnja tokena

Kada se petlja pokrene, to više nije model naplate „jedno pitanje, jedan odgovor". Agent će neprestano čitati kontekst, pozivati alate i proveravati rezultate, a ponekad će pokrenuti i više pod-Agenta koji rade istovremeno.

Drugim rečima, iako je ovo moćno, ako je loše dizajnirano, može sagoreti ogromnu količinu tokena.

Na primer, Agent u petlji pozove MCP alat sa bagom, pa u roku od 5 minuta pokuša 400 puta. Alat svaki put vrati grešku, a Agent svaki put pomisli „još jedan pokušaj bi trebalo da uspe". Petlja bez mehanizma prekida jeste mašina za trošenje novca.

Nekoliko sredstava za kontrolu troškova.

• Postavite razuman maksimalan broj iteracija za petlju, sprečavajući Agent-a da se vrti u krugu neuspeha
• Svaki krug izvršenja /loop ima nezavisan prozor konteksta, bez neograničenog akumuliranja konteksta između krugova

Granice bezbednosti

Agent u petlji ima dozvole za čitanje i pisanje datoteka, izvršavanje komandi i može imati i pristup eksternim sistemima koje mu je dao MCP. Loše dizajnirana petlja može u 3 ujutru automatski gurnuti nepregledani kod u produkciono okruženje.

Koji scenariji su pogodni za Loop

Scenariji pogodni za petlju imaju nekoliko zajedničkih osobina — visoka učestalost ponavljanja, jasna pravila i automatizovana sredstva provere.

• Pregled koda: na svakih N minuta skenira diff, linter i testovi služe kao provera
• Popravljanje CI: nakon pada CI automatski analizira logove i pokušava popravku, prolazak testova je provera
• Sinhronizacija dokumentacije: kod se promenio, automatski se ažurira dokumentacija, diff se može proveriti
• Nadogradnja zavisnosti: automatski kreira PR za nadogradnju i pokreće testove
• Skeniranje bezbednosti: periodično proverava poznate ranjivosti