Medium · AI inženjering, Razvoj softvera · Nacrt

Obrazac četiri petlje: kako voditi autonomne agente za kodiranje bez odstupanja

Kako zadržati disciplinu u AI inženjerstvu kad agenti rade brže nego što možete da pregledate — uključujući i trenutke kad autor te discipline sam od nje odstupi.

Prvi put objavljeno na Medium-u 12. maja 2026; poslednja izmena 13. maja 2026. Pročitajte na Medium-u↗. 17 min čitanja.

Kako zadržati disciplinu u AI inženjerstvu kad agenti rade brže nego što možete da pregledate — uključujući i trenutke kad autor te discipline sam od nje odstupi.

Ovo je istraživački članak, a ne recept. Njegova vrednost nije u tome što je Obrazac četiri petlje već dokazan, nego u tome što daje jezik za stvaran oblik neuspeha: autonomni agenti mogu biti zauzeti, lokalno u pravu, a da proizvod ipak ne pomere napred.

Ako ste više od nedelju dana pokretali agente za programiranje na pravoj bazi koda, verovatno ste naleteli na isti zid kao i ja. Agenti su produktivni — isporučuju commit-e, prolaze CI, ažuriraju dokumentaciju. Repozitorijum raste. Testovi se dodaju. Grade se novi mehanizmi.

A onda zastanete, pogledate svoj proizvod i shvatite: ništa zapravo nije postalo bolje.

Agenti su zauzeti. Rezultat je stvaran. Ali korisničko iskustvo je otprilike tamo gde je bilo pre mesec dana. Baza koda je veća, doktrina deblja, metaarhitektura elegantnija — a funkcija koju ste hteli da isporučite i dalje ne radi od početka do kraja.

Ovaj članak opisuje obrazac do kojeg sam došao za vođenje autonomnih agenata za programiranje tako da proizvod zaista napreduje. To nije čarobni štapić. To je disciplina. I — važno — to je disciplina koju sam u istoj sesiji u kojoj je nastao ovaj članak više puta uhvatio da kršim. I to je deo ovde: oblici neuspeha koji prežive čak i kad pravila napišete.

Oblik neuspeha

Patologija ima ime: pokretanja u neutralnom zanošenju. „Pokretanje“ (fire) je jedno izvršavanje petlje agenta. Pokretanje u neutralnom zanošenju je ono u kojem agent radi, isporučuje commit-e, prolazi CI, a ne menja ništa što korisnik može da vidi ili izmeri.

Uobičajeni oblici:

• Inflacija doktrine. Agent piše novi vodič stila, novo arhitektonsko pravilo, novu konvenciju imenovanja. Baza koda se ne menja; raste doktrina koju će čitati budući agenti. Posle nekoliko nedelja svaka nova sesija troši 20% prozora konteksta na čitanje pravila koja ne služe nijednoj funkciji.
• Razmnožavanje stubova. Agent isporučuje „funkciju“ — novi ekran, tip entiteta, API krajnju tačku. Oblik je tačan (datoteka postoji, šema je validna, CI je zelen). Ponašanje je prazno: ekran nema podataka, entitet nema metode, krajnja tačka vraća 404 na stvarne ulaze. Površina proizvoda raste u širinu, a ostaje plitka.
• Mehanizam bez merenja. Agent gradi okvir za testiranje, sloj osmotrivosti, CI kapiju. Okvir radi. Ništa od onoga što bi on uhvatio nikad se ne aktivira. Izlaz okvira: zelena kvačica, svaki put, na proizvodu koji je pokvaren.
• Preuređivanje plana. Agent menja mapu puta, preklasifikuje prioritete, dodaje nove stavke u backlog. Mapa puta raste. Rad isporučen prema njoj ostaje mali.

Svaki od ovih oblika deluje produktivno jer agent ZAISTA isporučuje commit-e. Pokretanje je „uspešno“ u trivijalnom smislu — nije pao, CI je bio zelen, diff je spojen. Ali merljivo stanje platforme se nije promenilo. Pomnožite to s 50 pokretanja nedeljno i dobijate skupu traku za trčanje.

Disciplina u nastavku postoji da bi ovaj oblik neuspeha bilo nemoguće sakriti.

Arhitektura četiri petlje

Odbacite obrazac „jednog velikog agenta“. Jedna petlja koja pokušava da radi sve (implementaciju, recenziju, nadzor, testiranje s korisničke strane) zanosi se, jer se prioriteti takmiče, a nema razdvajanja odgovornosti koje bi to sprečilo.

Četiri petlje, svaka sa zatvorenom odgovornošću:

• Petlja implementatora — radi svakih 60 minuta. Uzima stavku iz backloga; isporučuje kod + testove + dokumentaciju u jednom PR-u. Ne sme: da recenzira sopstveni PR; da zaobilazi CI kapije.
• Petlja recenzenta — radi svakih 30 minuta. Botom recenzira svaki PR prema pravilima discipline; odobrava ili traži izmene. Ne sme: da otvara nov rad na funkcijama; da menja pravila koja sprovodi.
• Petlja analitičara — radi svakih 90 minuta. Otkrivanje zanošenja, revizije dokumentacije, istraživanje industrije, predlozi za backlog. Ne sme: da piše produkcijski kod; da direktno menja mapu puta.
• Petlja testera u ulozi korisnika — radi svaka 4 sata. Prolazi kroz isporučeni proizvod kao korisnik iz domena bez ikakvog razvojnog znanja; ocenjuje ga; podnosi nalaze. Ne sme: da popravlja ono što nađe; da recenzira sopstvene nalaze.

Svaka petlja radi u sopstvenoj sesiji. Komuniciraju preko datotečnog sistema (git za zajedničko stanje; datoteke s uputstvima po petlji za primopredaju). Ne pozivaju jedna drugu direktno.

Ortogonalnost je važna. Implementator ne može sam sebi da stavi pečat; recenzent ne može da radi sopstvenu implementaciju; analitičar ne može da isporuči izmene koje predlaže; tester ne može da popravi ono što ocenjuje. Svaka petlja je prinuđena da koristi rezultate drugih petlji.

To je isto razdvajanje koje ima zdrav ljudski inženjerski tim — programer, recenzent, QA, operacije — kodifikovano za agente. Petlje nisu „fleksibilnije“ od ljudi. One su krutije. U tome je poenta.

Zakon konvergencije

Paralelizam bez napretka gori je od nikakvih agenata. Da bi se došlo do napretka, potrebno je čvrsto pravilo:

Svako pokretanje završava u jednom od tri stanja: KONVERGENTNO (isporučeno merljivo poboljšanje platforme uz dokaz pre/posle), IZRIČITO NEUTRALNO (namerno ništa nije urađeno, uz navedeni razlog) ili REGRESIVNO (nešto je pogoršano — zahteva trenutno vraćanje izmene i zapisanu pouku). Pokretanje koje je radilo i nešto uradilo, ali nije dalo merljivu promenu, jeste NEUTRALNO ZANOŠENJE i oblik je neuspeha koji petlja recenzenta označava kao kršenje discipline.

„Merljivo“ nosi težinu. Potrebna je kanonska matrica stanja koju svaka petlja čita pri hladnom startu: ocene oblasti funkcija, stope uspeha, dubine redova, kašnjenje isporuke — šta god da su primarne ose Vašeg proizvoda. Pokretanje je konvergentno ako se neka ćelija u toj matrici poboljšala I nijedna se nije pogoršala. Poboljšanje mora biti potkrepljeno dokazom pre/posle u telu PR-a.

U praksi:

• Primer konvergentnog. „Radni prostor X je s ocene F prešao na ocenu B (pre: bez liste, bez dugmeta za kreiranje; posle: vidljivo 93 entiteta i dugme za kreiranje radi). Snimak ekrana pre priložen; snimak posle priložen. Matrica stanja ažurirana.“
• Primer izričito neutralnog. „Samo istraživanje — uzrok još nije poznat; popravka u ovom pokretanju nije moguća. Nalazi zabeleženi u analysis/…“
• Primer regresivnog. „Pokušao Y; pokvario Z. Vraćen commit ABC. Pouka zapisana.“

Petlja recenzenta sprovodi ovo na svakom PR-u. PR-ovi koji ne spadaju u jedno od tri stanja dobijaju REQUEST_CHANGES. Autor mora ili da pronađe merljivo poboljšanje, ili da ga preklasifikuje kao neutralno uz razlog, ili da vrati izmenu.

Samo ovo pravilo hvata otprilike 80% problema zanošenja. Za ostalo treba još.

Pravilo otplate

Pravila se gomilaju. Svako novo pravilo koje budući agent mora da pročita jeste porez na budžet konteksta svakog budućeg pokretanja. Zato:

Dodavanje novog dokumenta doktrine, definicije agenta, stavke backloga ili koraka procesa ZAHTEVA ukidanje bar jednog postojećeg (obrisati ga, spojiti s drugim ili arhivirati). Neto složenost ne sme da raste bez izričitog odobrenja operatera. Izuzetak: ako nova stavka konvergencijom zamenjuje više starih, to je neto-negativno i prihvatljivo.

To je pravilo koje lično najčešće kršim. Teško je brisati stvari koje ste sami napisali. Ali alternativa je dokument doktrine čije čitanje na početku svake sesije traje 30 minuta — što znači da ga agenti preletaju, što znači da ga ne slede, što znači da se zanose.

Petlja recenzenta proverava svaki PR: da li je dodao nove datoteke doktrine ili stavke backloga? Ako jeste, da li je ukinuo nešto ekvivalentne težine? Ako nije, REQUEST_CHANGES uz poruku: „convergence-discipline: ovaj PR dodaje N novih stavki doktrine, a ukida 0. Ili ukinite jednu, ili dokumentujte zašto je neto dodavanje opravdano merljivim poboljšanjem koje stiže u ovom PR-u.“

Pravilo zabrane isporuke stubova

Disciplina konvergencije hvata zanošenje po pokretanju. Ne hvata zanošenje po artefaktu. Jedno pokretanje može isporučiti 10 artefakata, od kojih 3 rade a 7 su stubovi, u zbiru se računati kao „konvergentno“ i tiho povećavati broj stubova na platformi.

Pravilo po artefaktu:

Svaki artefakt koji isporučite — krajnja tačka, ekran, vidžet, mogućnost, definicija agenta, odeljak priručnika, bilo šta — MORA biti u jednom od tri stanja: RADI(proveren od početka do kraja testom, izlazom smoke testa ili snimkom ekrana u telu PR-a), SPREMNO ZA RAD(praznina je izričito imenovana, a stavka za dovršetak stavljena u red u istom PR-u), ili STUB-S-REDOM(izričita oznaka status:stub plus navedena stavka za dovršetak plus objašnjenje čitljivo operateru kad se do njega stigne). STUB-BEZ-REDAje kršenje discipline.

Klasičan prekršaj: isporuka ekrana s vidžetom „Red nije dostupan — Pokušaj ponovo“. Oblik vidžeta je u redu; podaci iza njega ne postoje; nijedna stavka za dovršetak nije stavljena u red. Korisnik udara u zid bez objašnjenja i bez puta napred.

Suptilniji prekršaj: isporuka datoteke dokumentacije s markdown vezama ka susednim datotekama koje ne postoje. Cilj veze trebalo bi da bude stub-s-redom datoteka, ali nije ni to — to je praznina. Recenzentov proveravač veza obara CI; kapija isporuke odbija; platforma staje. Upravo taj oblik neuspeha isporučio sam u sesiji u kojoj je nastao ovaj članak — a petlja analitičara ga je uhvatila u roku od nekoliko sati. Više o tome u nastavku.

Univerzalni protokol hladnog starta

Svaka petlja, na početku svakog pokretanja, pre bilo kakvog rada izvodi istih šest provera:

• Sinhronizuj se s aktuelnom glavnom granom. Povuci. Vidi šta je stiglo od prethodnog pokretanja.
• Pročitaj kanonsku matricu stanja. Kakvo je merljivo stanje platforme upravo sada?
• Proveri kašnjenje isporuke. Koji SHA je u produkciji, a koji na glavnoj grani? Najčešće usko grlo je upravo ovde.
• Proveri zdravlje kapije isporuke. Jesu li nedavne isporuke uspele? Ili test kapija odbija puštanja?
• Proveri zaostatak recenzija. Koliko je otvorenih PR-ova? Koliko su stari?
• Proveri CI signal. Jesu li nedavna izvršavanja na glavnoj grani zelena?

Plus sedma u petlji za nadzor:

1. Proveri rezervu ograničenja brzine. Koliki deo tekućeg obračunskog perioda je potrošen? Kolika je brzina potrošnje?

Posle provera svaka petlja primenjuje svoja pravila odgovora u prioritetnom redosledu usidrenom u obrazloženju: dostupnost pre ispravnosti, kapija isporuke pre sadržaja, glavni CI pre backloga, backlog pre novog rada, metrika platforme pre doktrine.

Ovo zvuči birokratski. Zapravo je suprotno — oduzima agentu slobodu da loše bira. Petlja suočena sa „kapija isporuke odbija, četiri PR-a nepregledana, CI crven, backlog raste, oblast funkcija s najnižom ocenom je F“ više ne mora da razmišlja o prioritetu. Protokol odlučuje: prvo kapija isporuke.

Trinaest invarijanti robusnosti

Protokoli za ispitivanje stanja su po prirodi krhki. Provere ističu, datoteke nedostaju, mreže otkazuju. Zato:

• I-1. Svaka provera ima tvrdo ograničenje vremena (10 sekundi podrazumevano, 30 sekundi za SSH).
• I-2. Svaka provera ima degradirani rezervni put (neuspeh provere ne znači neuspeh pokretanja).
• I-3. Rešavanje sukoba po prioritetu usidrenom u obrazloženju, a ne po prvom poklapanju.
• I-4. Otkrivanje zastarelog stanja (starije od 24 sata pokreće novi obilazak).
• I-5. Oporavak od pada pri hladnom startu (ostavljene otvorene grane, istekle brave, neuneto stanje).
• I-6. Konkurentnost zasnovana na zakupu. Svaki tip petlje drži sopstvenu datoteku zaključavanja. Dva istovremena pokretanja istog tipa petlje ne mogu se sudariti.
• I-7. Podrazumevano nečinjenje jednako je izričito neutralnom uz prikaz. Tiha pokretanja bez radnje nisu moguća.
• I-8. Dnevnik revizije po pokretanju. Rezultati provera, odluka, radnja, verifikacija — sve zabeleženo.
• I-9. Verifikacija posle radnje je obavezna. Neuspela verifikacija znači VRATI, a ne pokušaj ponovo.
• I-10. Ograničenje troška po pokretanju (200.000 tokena). Petlje koje pobegnu su ograničene.
• I-11. Uljudno ustupanje na prekid operatera. STOP datoteka usred pokretanja znači čist izlaz, bez poluzavršenog stanja.
• I-12. Bezbedno pokretanje od nule. Radi pri prvom pokretanju ikada, kad datoteke stanja još ne postoje.
• I-13. Izolacija radnog stabla. Svaka petlja radi u sopstvenom git radnom stablu (worktree) — zaseban radni direktorijum, isti zajednički .git repozitorijum. Bez toga se dve petlje koje dele radno stablo sudaraju pri svakom checkout-u i pull-u. Nemojte ovu lekciju učiti na teži način; podesite je od početka.

I-13 je ona koju sam dodao posle ove sesije. Ostalih dvanaest sam imao kako treba. Obrazac sudara koji I-13 sprečava opisan je u odeljku „Šta i dalje kvari ovaj obrazac“ u nastavku.

Matrica modela i režima razmišljanja

Moderne platforme za agente za programiranje dopuštaju da birate veličinu modela I režim razmišljanja (normalno nasuprot produženom razmišljanju s izričitim budžetom zaključivanja). Razlika u ceni između najjeftinije i najskuplje opcije je otprilike 60×. Ako se za svaku aktivnost podrazumeva „najpametniji model s najdubljim razmišljanjem“, trošite novac na rutinski rad kojem dubina ne koristi.

Mapiranje aktivnosti na model:

• Rutinska botovska recenzija PR-a — manji model, normalno razmišljanje. Poređenje s obrascem prema pravilima; nije potrebno novo zaključivanje.
• Recenzija koda značajne izmene — najveći model, produženo razmišljanje (16k+ tokena). Suptilna ispravnost traži dubinu.
• Provera stanja pri hladnom startu — manji model, normalno razmišljanje. Mehanički posao; dubina je uzaludna.
• Sinteza preko više polova, poput otkrivanja zanošenja — manji model, produženo razmišljanje (~8k tokena). Poređenje više izvora ima koristi od malo više zaključivanja.
• Uzrok zastoja konvergencije — najveći model, produženo razmišljanje (16k tokena). Dijagnostika otkaza na nivou sistema.
• Arhitektonska odluka koja se okamenjuje — najveći model, produženo razmišljanje (16k+ tokena). Pogrešna arhitektura košta nedelje; platite dubinu.
• Rutinsko otklanjanje grešaka poznatih obrazaca — manji model, normalno razmišljanje. Posao pretrage.
• Novo otklanjanje grešaka duže od 30 minuta — najveći model, produženo razmišljanje (16k+ tokena). Dubina se isplati.
• Bezbednosna revizija — najveći model, produženo razmišljanje (16k+ tokena). Suptilno zaključivanje o modelu pretnji.

Podrazumevano: manji model + normalno razmišljanje. Prelazite na više kad dubina zaista pomaže. Nikad ne podrazumevajte „najveći + najdublji za svaki slučaj“ — najveća stavka troška u svakom sistemu agenata su podagenti koji nasleđuju model roditelja, a trebalo bi da ga zamene nečim jeftinijim.

Granica između agenta i operatera

Najvažnije pravilo: agenti ne prebacuju tiho posao na ljudskog operatera.

Kad autonomni sistem za programiranje nešto ne može — stručnost iz domena, pozicioniranje na tržištu, testiranje sa stvarnim korisnicima, odluke o poslovnom modelu — javlja se iskušenje da se u dokumentaciju upiše „operater treba da…“. To nije pošteno. To je prebacivanje najtežih delova upravo u trenutku kad je operater najmanje spreman da ih preuzme (rano u životu proizvoda, kad još nema MVP-a).

Šta agenti HOĆE da isporuče: podizanje ocena funkcija od pokvarenog do radnog; dizajnersko doterivanje; konkurentske analize iz javnih izvora; dubinu integracija; UX testiranje pre prvih kupaca (preko petlje testera u ulozi korisnika); tokove uvođenja; funkcije izveštavanja.

Šta samo operater može da odluči: stratešku prednost (koja funkcija je najvažnija za tržište koje poznaje); poslovni model; konačni estetski izbor između dva usklađena dizajna; izričito odobrenje zaobilaženja (kad agent kaže „ovaj test je nestabilan, mogu li da ga zaobiđem“); preklasifikaciju nivoa prioriteta.

Testiranje sa stvarnim kupcima se ODLAŽE, ne prebacuje. Dovođenje stvarnih korisnika pre MVP-a troši dobru volju na pokvaren proizvod. Petlja testera u ulozi korisnika ga zamenjuje dok se ne dostigne prag MVP-a. Tada dolaze stvarni korisnici da pronađu ono što je simulirani tester propustio.

Ovu granicu operateri najviše moraju da sprovode. Bez nje, sistem agenata postaje nešto što traži pažnju operatera, umesto nečega što radi posao.

Jedna kanonska datoteka stanja

Sve četiri petlje, sva pravila discipline, svi protokoli — beskorisni su ako ne postoji zajednička definicija toga „kakvo je stanje platforme upravo sada“.

Jedna datoteka. Tabela trendova samo za dodavanje. Svaki red je snimak u vremenu. Kolone su metrike do kojih je proizvodu stalo: ocene funkcija po oblastima, stope uspeha, broj blokatora, dubine redova.

Svaka petlja čita ovu datoteku pri hladnom startu. Konvergentna pokretanja je ažuriraju. Pokretanja u neutralnom zanošenju ne. Posle nedelju-dve, trend u ovoj datoteci JESTE odgovor na pitanje „da li agenti proizvode konvergenciju“.

Ako 7 uzastopnih snimaka ne pokazuje pomak, petlja recenzenta javlja: „konvergencija je zastala — pauzirajte petlje, potreban je metarazgovor.“ Datoteka je sigurnosni ventil koji hvata slučaj u kojem svako pojedinačno pokretanje tvrdi da je produktivno, a zbir nije.

Šta i dalje kvari ovaj obrazac

Ovo je odeljak kojeg prvobitni nacrt ovog članka nije imao. Dodavanje me je koštalo jednu sesiju zanošenja.

Zanošenje autora

Osoba (ili agent) koja piše pravilo rutinski ga prekrši pre nego što se mastilo osuši. Isporučio sam disciplinu po artefaktu koja kaže „svaki artefakt se isporučuje kao RADI, SPREMNO ZA RAD ili STUB-S-REDOM“ — a u istoj sesiji isporučio sam stablo dokumentacije sa 16 visećih markdown veza koje ne spadaju ni u jedno od tih stanja. Petlja analitičara ga je uhvatila u roku od nekoliko sati. Bio sam autor pravila koje je označilo moj sopstveni prekršaj.

Zaključak: samosprovođenje discipline ne radi. Petlje recenzenta i analitičara nisu poželjan dodatak; one su jedino što hvata zanošenje autora. Gradite ih prve. Pravila koja sami napišete neće Vas vezivati bez spoljašnjeg sprovođenja.

Sudari na zajedničkom radnom stablu

Ako sve četiri petlje pokrećete iz istog fizičkog direktorijuma, sudariće se pri svakoj git operaciji. Jedna petlja uradi git checkout <branch>, a git status druge petlje odjednom prijavljuje drugu stvarnost. Napola spojeni commit-i pripisuju se pogrešnoj sesiji. Nepraćene datoteke se pojavljuju i nestaju zavisno od toga koju je granu poslednja petlja checkout-ovala.

Rešenje je invarijanta I-13 iznad: svaka petlja radi u sopstvenom git radnom stablu. Poseban radni direktorijum, zajednička .git baza. Komanda git worktree add je jedan red i trajno rešava čitavu klasu neuspeha.

Ovo sam naučio tako što sam se više puta sudarao sa sopstvenom petljom analitičara dok sam u istom direktorijumu vodio glavnu sesiju direktno kao operater.

Zamke pokretača

Tri zamke na koje ćete naleteti pre nego što petlje i počnu da se pokreću.

• Zamka 1: Višeredni promptovi se odsecaju. Prosleđivanje argumenata procesu na Windowsu prekida se na prvom novom redu. Uputstvo od 3.300 znakova prosleđeno kao pozicioni argument izvršnoj datoteci agenta stiže do nje kao prvih 70 znakova. Koristite zastavicu za ulaz iz datoteke (--append-system-prompt-file <path> ili ekvivalent) ili prosledite preko stdin-a — bilo šta što ne stavlja nove redove u argv.
• Zamka 2: Slash komande postoje samo u korisničkom interfejsu. Ako Vaše uputstvo traži od agenta da kao prvu radnju pozove /rename "Dev /loop", on to ne može. Slash komande obrađuje korisnički interfejs, a ne agent. Umesto toga postavite ime sesije pri pokretanju (većina platformi ima zastavicu -n ili --name) i potpuno izbacite tu direktivu.
• Zamka 3: Prosleđivanje izvornih argumenata u PowerShell-u 5.1 nije pouzdano. Razmaci, apostrofi i kose crte u vrednostima argumenata mogu se unakaziti kad ih PS 5.1 predaje izvornoj izvršnoj datoteci u režimu -File. Dijagnoza je nedvosmislena: ručno pozivanje iste izvršne datoteke iz interaktivnog PowerShell-a radi; pozivanje preko cmd → powershell -File script.ps1 -Param "value" ne radi. Rešenje: izbacite PowerShell sloj; neka cmd direktno pozove izvornu izvršnu datoteku.

Sve tri sam doživeo u jednoj sesiji. Nijedna nije egzotična — nosive su za svako postavljanje na Windows hostu. Nijedna nije dokumentovana u README datotekama platformi za agente. Odvojite dan da ih pronađete.

Razmimoilaženje troška i vrednosti

Ista sesija koja je proizvela ovaj članak koštala je otprilike 157 dolara u računskoj snazi izraženoj kroz cene API-ja (stvarna pretplata je fiksna; iznos u dolarima je ono što bi isti rad koštao uz plaćanje po potrošnji). Sesija je proizvela devet spojenih pull request-ova doktrine, infrastrukture i procesa. Proizvela je nula poboljšanja proizvoda vidljivih korisniku. Popravka proizvoda koju sam commit-ovao rano u sesiji nikad nije stigla do produkcije jer je kapija isporuke odbila — zbog 15 testova koji padaju plus 16 visećih markdown veza koje sam isporučio.

To je razmimoilaženje troška i vrednosti rečeno otvoreno. Disciplina koju opisujem u ovom članku izgrađena je upravo tokom te sesije. Merljivo stanje platforme se nije poboljšalo. Infrastruktura koja će budućim sesijama omogućiti da ga poboljšaju sada postoji — a treba da budete iskreni prema sebi (i svom operateru) kad je to trgovina koju ste napravili.

Pravilo discipline konvergencije, primenjeno retroaktivno, označilo bi celu sesiju kao NEUTRALNO ZANOŠENJE. To je pravilo koje radi kako je zamišljeno. Ono vam kaže i nešto neprijatno: sesija sazdana da proizvede članak o disciplini teško može da istovremeno proizvede i napredak proizvoda, jer je svaki minut utrošen na doktrinu minut koji nije utrošen na funkciju. Planirajte u skladu s tim.

Šta ovo NEĆE učiniti

Iskrene granice onoga što disciplina može i ne može da isporuči:

• Podići će svaku oblast funkcija od pokvarene do radne. Neće dostići apsolutno najvišu ocenu bez metoda tokova rada na nivou domena plus verifikacije promene stanja.
• Isporučiće estetiku spremnu za produkciju preko kapije dizajnerskog sistema. Neće stvoriti prvobitni estetski temelj — dizajnerski jezik bira operater.
• Sastaviće konkurentske analize ravnopravnosti funkcija iz javnih izvora. Neće odlučiti o strateškom pozicioniranju prema etabliranim igračima — to je operaterovo poznavanje tržišta.
• Sprovodiće UX testiranje pre prvih kupaca preko simuliranog agenta „glupog korisnika“. Neće pronaći stvarne bolne tačke kupaca — stvarni korisnici dolaze posle MVP-a.
• Održaće konvergenciju po poznatoj ceni. Neće Vas odvesti od MVP-a do „najboljeg na tržištu“ — za to su potrebni ulazi koje petlje nemaju.

Imenovanje onoga što se neće desiti deo je discipline. Bez toga operateri očekuju više nego što sistem može da isporuči i gube poverenje kad on ostane ispod očekivanja.

Šta košta

Sesija s četiri petlje koja radi 8 sati dnevno u tempu koji poštuje matricu košta otprilike koliko mesečni budžet za alate jednog inženjera srednjeg ranga. Stvarna pretplata je fiksna; ograničenje su granice brzine po obračunskom periodu, a ne dolari.

Sve podrazumevano na najveći model s najdubljim razmišljanjem? Otprilike 5–7× toliko. Disciplina matrice je razlika između održivog autonomnog inženjerstva i računa koji pobegne.

Cena po sesiji mnogo više varira. Sesija koja isporučuje čistu doktrinu — poput one iz koje je nastao ovaj članak — troši budžet bez poboljšanja proizvoda. To nije rasipanje ako će se doktrina isplatiti kroz konvergenciju u budućim sesijama, ali JESTE rasipanje ako doktrina stoji nesprovedena.

Petlja recenzenta je ono što doktrinu čini isplativom. Bez nje se doktrina gomila kao mrtav teret.

Lekcija koju stalno iznova učim

Svaki put kad ovom sistemu dodam novo pravilo, agenta ili proces, dodajem teret budućnosti. Pravilo discipline konvergencije jedino je neto-negativno po teretu — prisiljava svako drugo dodavanje da se isplati merljivim poboljšanjem.

Patologija koju sam opisao na početku ovog članka — „agenti su produktivni, ali proizvod se ne pomera“ — neuspeh je discipline, a ne alata. Agenti rade tačno ono što im kažete: isporučuju commit-e, prolaze CI, ažuriraju dokumentaciju. Samo im nije rečeno da commit-i moraju da pomeraju merljivu osu.

Kad im to kažete, uz izričita pravila po pokretanju i po artefaktu, uz jednu kanonsku datoteku stanja, uz razdvajanje odgovornosti kroz četiri petlje, uz iskrenu granicu onoga što mogu samo ljudi i uz izolaciju radnog stabla da se ne sudaraju — agenti postaju korisni.

Ne magični. Korisni. Ponekad.

To „ponekad“ je deo koji je prvobitni nacrt ovog članka propustio. Disciplina je cilj. Čak i kad je zapisana, čak i kad su pravila izričita, čak i kad petlja recenzenta radi, Vi (i Vaši agenti) ćete se zanositi. Zanošenje se hvata — za to služi petlja analitičara — ali se ne sprečava. Mehanizam je samoispravljajući, a ne samosprečavajući.

Ta razlika je važna. Literatura o alatima za AI inženjerstvo prepuna je „magičnih“ tvrdnji. Stvarnost je ovakva: mali skup disciplinovanih obrazaca, strogo sprovođenih od strane drugih agenata (a ne samodisciplinom), koji autonomne agente teraju da većinu vremena rade pravi posao, a ostatak vremena zanošenje biva uhvaćeno i ispravljeno. Sve ostalo je pozorište.

Ako pokrećete agente za programiranje na pravoj bazi koda i vidite oblike neuspeha koje sam opisao, gornji obrasci mogu pomoći. Nisu novi; većina su kodifikacija onoga što dobri inženjerski timovi već rade. Novina je u tome što ih čine nosivim za autonomne petlje u kojima nema čoveka u neposrednoj blizini koji bi ih podrazumevano sprovodio — i u imenovanju oblika neuspeha koji prežive i disciplinu.

Dodatak. Podsetnik

Ova stranica je potpuna kopija priče onako kako je objavljena na Medium-u. Pročitajte na Medium-u↗. Ilustracije su generisane pomoću AI.