Inženjering korištenja: korišt. Codexa u svijetu usmj. na agente

Tokom proteklih pet mjeseci, naš tim je sprovodio eksperiment: razvijanje i isporuka interne beta verzije softverskog proizvoda s 0 linija ručno napisanog koda.

Proizvod ima unutrašnje dnevne korisnike i vanjske alfa testere. Isporučuje se, implementira, kvari i popravlja. Ono što je drugačije jeste da je svaka linija koda—logika aplikacije, testovi, CI konfiguracija, dokumentacija, observabilnost i interni alati—napisana od strane Codexa. Procjenjujemo da smo ovo izgradili za otprilike desetinu vremena koje bi bilo potrebno da se kod napiše ručno.

Ljudi upravljaju. Agenti izvršavaju.

Namjerno smo odabrali ovo ograničenje kako bismo izgradili ono što je bilo potrebno da se brzina inženjerskog rada poveća za redove veličine. Imali smo nekoliko sedmica da isporučimo ono što je na kraju postalo milion linija koda. Da bismo to postigli, morali smo razumjeti šta se mijenja kada primarni zadatak tima za softversko inženjerstvo više nije pisanje koda, već dizajniranje okruženja, određivanje namjere i izgradnja povratnih petlji koje omogućavaju Codex agentima da obavljaju pouzdan posao.

Ova objava govori o tome šta smo naučili izgradnjom potpuno novog proizvoda sa timom agenata—šta se pokvarilo, šta se nadovezalo i kako maksimalno iskoristiti naš jedini zaista oskudan resurs: ljudsko vrijeme i pažnju.

Prvi commit u prazni repozitorij napravljen je krajem augusta 2025.

Početni scaffold—struktura repozitorija, CI konfiguracija, pravila formatiranja, postavke menadžera paketa i aplikacijski okvir—generisan je pomoću Codex CLI koristeći GPT‑5, vođen malim skupom postojećih predložaka. Čak je i početna datoteka AGENTS.md koja usmjerava agente kako da rade u repozitoriju bila napisana od strane Codexa.

Nije postojao prethodno napisan ljudski kod na koji bi se sistem mogao osloniti. Od samog početka, repozitorij je bio oblikovan od strane agenta.

Pet mjeseci kasnije, repozitorij sadrži oko milion linija koda u logici aplikacije, infrastrukturi, alatima, dokumentaciji i internim programerskim alatima. Tokom tog perioda, otprilike 1.500 pull requestova je otvoreno i spojeno, uz mali tim od samo tri inženjera koji vode Codex. Ovo se prevodi u prosječni protok od 3,5 PRs po inženjeru dnevno, i iznenađujuće, protok se povećao kako je tim narastao na sada sedam inženjera. Važno je napomenuti da ovo nije bio rezultat radi rezultata: proizvod su interno koristile stotine korisnika, uključujući i svakodnevne interne napredne korisnike.

Tokom procesa razvoja, ljudi nikada nisu direktno doprinijeli nijednim kodom. Ovo je postala osnovna filozofija tima: bez ručno pisanog koda.

Nedostatak praktičnog ljudskog kodiranja uveo je drugačiju vrstu inženjerskog rada, fokusiranu na sisteme, potporu i iskorištavanje.

Rani napredak bio je sporiji nego što smo očekivali, ne zato što Codex nije bio sposoban, već zato što okruženje nije bilo dovoljno precizno definirano. Agentu su nedostajali alati, apstrakcije i unutrašnja struktura potrebni za napredak ka ciljevima visokog nivoa. Primarni zadatak našeg inženjerskog tima postao je omogućiti agentima da obavljaju korisne zadatke.

U praksi, to je značilo raditi po principu dubinskog pristupa: razlagati veće ciljeve na manje gradivne blokove (dizajn, kod, pregled, test, itd.), poticati agenta da izgradi te blokove i koristiti ih za otključavanje složenijih zadataka. Kada nešto ne uspije, rješenje gotovo nikada nije bilo „više se potruditi.” Budući da je jedini način za napredak bio da Codex obavi posao, ljudski inženjeri su uvijek preuzimali zadatak i pitali: „Koja sposobnost nedostaje i kako je učiniti čitljivom i provedivom za agenta?”

Ljudi komuniciraju sa sistemom gotovo u potpunosti putem upita: inženjer opisuje zadatak, pokreće agenta i omogućava mu da otvori pull request. Da bismo doveli PR do završetka, upućujemo Codex da lokalno pregleda vlastite promjene, zatraži dodatne specifične recenzije od agenata, kako lokalno tako i u oblaku, odgovori na sve povratne informacije koje daju ljudi ili agenti, te iterira u petlji dok svi agenti recenzenti ne budu zadovoljni (u suštini, ovo je Ralph Wiggum Loop⁠(otvara se u novom prozoru)). Codex koristi naše standardne razvojne alate direktno (gh, lokalne skripte i vještine ugrađene u repozitorij) za prikupljanje konteksta bez potrebe da ljudi kopiraju i lijepe u CLI.

Ljudi mogu pregledati pull request, ali nisu obavezni to činiti. Vremenom smo gotovo sav napor oko pregleda usmjerili na to da se obavlja između agenata.

Kako se protok koda povećavao, naše usko grlo postao je kapacitet ljudske QA. Budući da su ljudsko vrijeme i pažnja bili fiksna ograničenja, radili smo na dodavanju više mogućnosti agentu tako što smo učinili da su UI aplikacije, logovi i metrički podaci aplikacije direktno čitljivi za Codex.

Na primjer, omogućili smo da aplikacija bude pokrenuta po git worktree, tako da je Codex mogao pokrenuti i upravljati jednom instancom po promjeni. Također smo povezali Chrome DevTools Protocol u runtime agenta i razvili vještine za rad s DOM snimcima, snimkama ekrana i navigacijom. Ovo je omogućilo Codexu da reproducira greške, validira ispravke i direktno razmišlja o ponašanju korisničkog interfejsa.

Učinili smo isto za alate za nadzor. Logovi, metrike i tragovi su dostupni Codexu putem lokalnog observability stacka koji je privremen za bilo koje radno stablo. Codex radi na potpuno izoliranoj verziji te aplikacije—uključujući njene logove i metrike, koji se brišu nakon što se taj zadatak završi. Agenti mogu upititi logove koristeći LogQL i metrike koristeći PromQL. Uz ovaj dostupni kontekst, upiti poput „osiguraj da se pokretanje usluge završi za manje od 800 ms“ ili „nijedan span u ova četiri kritična korisnička putovanja ne prelazi dvije sekunde“ postaju izvodivi.

Redovno viđamo da pojedinačna pokretanja Codexa rade na jednom zadatku duže od šest sati (često dok ljudi spavaju).

Upravljanje kontekstom je jedan od najvećih izazova za efikasnost agenata u velikim i složenim zadacima. Jedna od najranijih lekcija koje smo naučili bila je jednostavna: dajte Codexu mapu, a ne priručnik s uputama od 1.000 stranica.

Pokušali smo s “jednim velikim AGENTS.md⁠(otvara se u novom prozoru)” pristup. Nije uspjelo na predvidljive načine:

• Kontekst je ograničen resurs. Ogromna datoteka s uputama potiskuje zadatak, kod i relevantnu dokumentaciju—tako da agent ili propušta ključna ograničenja ili počinje optimizirati za pogrešna.
• Previše uputa postaje ne-upute. Kada je sve „važno“, ništa nije. Agenti na kraju lokalno prepoznaju obrasce umjesto da namjerno navigiraju.
• Truhli odmah. Monolitni priručnik pretvara se u groblje zastarjelih pravila. Agenti ne mogu utvrditi šta je još uvijek tačno, ljudi prestaju održavati datoteku, koja tiho postaje privlačna smetnja.
• Teško je provjeriti. Jedan jedini blob ne omogućava mehaničke provjere (pokrivenost, svježina, vlasništvo, unakrsne poveznice), pa je odstupanje neizbježno.

Dakle, umjesto da tretiramo AGENTS.md kao enciklopediju, tretiramo ga kao spisak sadržaja.

Baza znanja repozitorija smještena je u strukturiranom direktoriju docs/ koji se tretira kao sistem evidencije. Kratki AGENTS.md (otprilike 100 linija) se ubacuje u kontekst i prvenstveno služi kao mapa, s uputama na dublje izvore istine drugdje.

Dokumentacija dizajna je katalogizirana i indeksirana, uključujući status verifikacije i skup osnovnih uvjerenja koja definišu operativne principe usmjerene na agenta. Dokumentacija arhitekture⁠(otvara se u novom prozoru) pruža pregled domena i slojevitost paketa na najvišem nivou. Dokument o kvaliteti ocjenjuje svaku domenu proizvoda i arhitektonski sloj, prateći praznine tokom vremena.

Planovi se tretiraju kao artefakti prvog reda. Efemerni lagani planovi koriste se za male promjene, dok se složen rad bilježi u izvršnim planovima⁠(otvara se u novom prozoru) s dnevnicima napretka i odluka koji se pohranjuju u repozitorij. Aktivni planovi, dovršeni planovi i poznati tehnički dug su verzionirani i smješteni zajedno, omogućavajući agentima rad bez oslanjanja na vanjski kontekst.

Ovo omogućava postepeno otkrivanje: agenti počinju sa malom, stabilnom početnom tačkom i uče gdje da traže dalje, umjesto da budu preplavljeni odmah na početku.

Mi ovo provodimo mehanički. Namjenski linteri i CI poslovi provjeravaju da je baza znanja ažurirana, međusobno povezana i pravilno strukturirana. Ponavljajući agent za „doc-gardening“ skenira zastarjelu ili prevaziđenu dokumentaciju koja ne odražava stvarno ponašanje koda i otvara pull request za ispravke.

Kako se baza koda razvijala, Codexov okvir za dizajnerske odluke takođe je morao evoluirati.

Budući da je repozitorij u potpunosti generisan od strane agenta, prvo je optimiziran za Codexovu čitljivost. Na isti način na koji timovi nastoje poboljšati navigabilnost svog koda za nove inženjerske zaposlene, cilj naših inženjera bio je omogućiti agentu da razmišlja o cijeloj poslovnoj domeni direktno iz repozitorija.

Iz perspektive agenta, sve čemu ne može pristupiti u kontekstu dok efektivno radi ne postoji. Znanje koje se nalazi u Google Docs-u, chat nitima ili u glavama ljudi nije dostupno sistemu. Lokalni artefakti repozitorija, koji su verzionirani (npr. kod, markdown, šeme, izvršni planovi), su sve što može vidjeti.

Saznali smo da smo trebali sa vremenom dodavati sve više i više konteksta u repo. Ona Slack diskusija koja je uskladila tim oko arhitektonskog uzorka? Ako agent ne može otkriti, to je nečitljivo na isti način kao što bi bilo nepoznato novom zaposleniku koji se pridruži tri mjeseca kasnije.

Davanje Codexu više konteksta znači organizirati i izložiti prave informacije kako bi agent mogao rezonovati o njima, umjesto da ga preopteretimo ad-hoc uputama. Na isti način na koji biste uveli novog člana tima u principe proizvoda, inženjerske norme i kulturu tima (uključujući preferencije za emoji), pružanje agentu ovih informacija dovodi do bolje usklađenog rezultata.

Ovakvo uokviravanje razjasnilo je mnoge kompromise. Dali smo prednost zavisnostima i apstrakcijama koje su se mogle u potpunosti internalizirati i razumjeti unutar repozitorija. Tehnologije koje se često opisuju kao „dosadne“ obično su agentima lakše za model zbog kompozabilnosti, stabilnosti API-ja i zastupljenosti u skupu za obuku. U nekim slučajevima, bilo je jeftinije da agent ponovo implementira podskupove funkcionalnosti nego da se zaobilazi nejasno ponašanje iz javnih biblioteka. Na primjer, umjesto da koristimo generički paket u stilu p-limit, implementirali smo vlastiti pomoćni alat za mapiranje s konkurentnošću: on je tijesno integrisan s našom OpenTelemetry instrumentacijom, ima 100% pokrivenost testovima i ponaša se tačno onako kako naš runtime očekuje.

Uvođenje većeg dijela sistema u oblik koji agent može pregledati, validirati i direktno mijenjati povećava uticaj—ne samo za Codex, već i za druge agente (npr. Aardvark) koji također rade na kodnoj bazi.

Sama dokumentacija ne može sama po sebi održati koherentnost baze koda koju je generisao agent. Primjenjujući invarijante, a ne mikroupravljajući implementacijama, omogućavamo agentima da brzo isporučuju bez narušavanja temelja. Na primjer, zahtijevamo da Codex analizira oblike podataka na granici⁠(otvara se u novom prozoru), ali ne propisujemo kako se to treba desiti (čini se da model preferira Zod, ali nismo specificirali tu biblioteku).

Agenti su najefikasniji u okruženjima sa strogim granicama i predvidljivom strukturom⁠(otvara se u novom prozoru), pa smo aplikaciju izgradili oko krutog arhitektonskog modela. Svaka poslovna domena podijeljena je na fiksni skup slojeva, sa strogo provjerenim smjerovima zavisnosti i ograničenim skupom dozvoljenih veza. Ova ograničenja se mehanički provode putem prilagođenih lintera (naravno, generisanih od Codexa!) i strukturnih testova.

Dijagram ispod prikazuje pravilo: unutar svake poslovne domene (npr. Postavke aplikacije), kod može zavisiti samo “naprijed” kroz fiksni skup slojeva (Types → Config → Repo → Service → Runtime → UI). Poprečne brige (autentifikacija, konektori, telemetrija, zastavice funkcija) ulaze kroz jedan eksplicitan interfejs: Provajderi. Sve ostalo nije dozvoljeno i provodi se mehanički.

Ovo je vrsta arhitekture koju obično odgađaš dok nemaš stotine inženjera. Kod agenata za kodiranje, to je rani preduvjet: ograničenja su ono što omogućava brzinu bez degradacije ili arhitektonskog odstupanja.

U praksi, provodimo ova pravila pomoću prilagođenih lintera i strukturnih testova, plus malog skupa „invarijanti ukusa“. Na primjer, statički provodimo strukturirano logiranje, konvencije imenovanja za šeme i tipove, ograničenja veličine datoteka i zahtjeve pouzdanosti specifične za platformu pomoću prilagođenih lintova. Budući da su lintovi prilagođeni, pišemo poruke o greškama kako bismo ubacili upute za otklanjanje problema u kontekst agenta.

U radnom toku koji stavlja ljude na prvo mjesto, ova pravila mogu izgledati sitničavo ili ograničavajuće. S agentima, oni postaju množiteli: jednom kada se kodiraju, primjenjuju se svugdje odjednom.

Istovremeno, jasno ističemo gdje su ograničenja važna, a gdje nisu. Ovo je slično vođenju velike organizacije inženjerske platforme: centralno postavite granice, lokalno omogućite autonomiju. Duboko ti je stalo do granica, ispravnosti i ponovljivosti. Unutar tih granica, timovima—ili agentima—dopuštate značajnu slobodu u izražavanju rješenja.

Rezultirajući kod ne mora uvijek odgovarati ljudskim stilističkim preferencijama, i to je u redu. Sve dok je izlaz ispravan, održiv i čitljiv za buduća pokretanja agenta, ispunjava standard.

Ljudski ukus se kontinuirano unosi natrag u sistem. Komentari pregleda, refaktorisanje pull requesta i greške vidljive korisnicima bilježe se kao ažuriranja dokumentacije ili se kodiraju direktno u alate. Kada dokumentacija nije dovoljna, pravilo pretvaramo u kod.

Kako se Codexov protok povećavao, mnoge konvencionalne inženjerske norme postale su kontraproduktivne.

Repozitorij radi sa minimalnim blokirajućim merge vratima. Pull requesti su kratkotrajni. Testne nestabilnosti se često rješavaju ponovnim pokretanjem umjesto da se napredak blokira na neodređeno. U sistemu u kojem je protok agenta daleko veći od ljudske pažnje, ispravke su jeftine, a čekanje je skupo.

Ovo bi bilo neodgovorno u okruženju sa niskim protokom. Ovdje je često pravi kompromis.

Kada kažemo da je baza koda generisana od strane Codex agenata, mislimo na sve što se nalazi u toj bazi.

Agenti proizvode:

• Kod proizvoda i testiranja
• CI konfiguracija i alati za izdavanje
• Interni alati za razvojne programere
• Historija dokumentacije i dizajna
• Evaluacijski pojasevi
• Pregledajte komentare i odgovore
• Skripti koji upravljaju samim repozitorijem
• Datoteke definicija kontrolne table za proizvodnju

Ljudi uvijek ostaju uključeni, ali rade na drugačijem nivou apstrakcije nego što smo ranije radili. Dajemo prednost radu, prevodimo povratne informacije korisnika u kriterije prihvatanja i provjeravamo rezultate. Kada se agent muči, tretiramo to kao signal: identificiramo šta nedostaje—alati, zaštitne ograde, dokumentacija—i vraćamo to u repozitorij, uvijek tako da Codex sam napiše ispravku.

Agenti koriste naše standardne alate za razvoj direktno. Oni povlače povratne informacije iz pregleda, odgovaraju inline, guraju ažuriranja i često squashaju i spajaju svoje vlastite pull requeste.

Kako je sve veći dio razvojnog ciklusa bio kodiran direktno u sistem—testiranje, validacija, pregled, obrada povratnih informacija i oporavak—repozitorij je nedavno prešao značajan prag na kojem Codex može od početka do kraja pokretati novu funkcionalnost.

Na osnovu jednog upita, agent sada može:

• Provjerite trenutno stanje koda
• Reproducirajte prijavljenu grešku
• Snimite video koji prikazuje neuspjeh.
• Ispravi grešku
• Potvrdi ispravku vozeći aplikaciju
• Snimite drugi video koji prikazuje rješenje
• Otvori pull request
• Odgovorite na povratne informacije agenta i ljudi.
• Otkrivanje i saniranje grešaka u izgradnji
• Prebacite na čovjeka samo kada je potrebna procjena.
• Spojite promjenu.

Ovo ponašanje uveliko zavisi od specifične strukture i alata ovog repozitorija i ne bi trebalo pretpostaviti da se može generalizirati bez sličnog ulaganja—barem, ne još.

Puna autonomija agenta takođe donosi nove probleme. Codex replicira obrasce koji već postoje u repozitoriju—čak i neujednačene ili suboptimalne. Tokom vremena, ovo neizbježno dovodi do odstupanja.

U početku su ljudi ovo rješavali ručno. Naš tim je ranije provodio svaki petak (20% sedmice) čisteći 'AI nered'. Nije iznenađujuće, to se nije proširilo.

Umjesto toga, počeli smo kodirati ono što nazivamo „zlatnim principima“ direktno u repozitorij i uspostavili smo ponavljajući proces čišćenja. Ovi principi su subjektivna, mehanička pravila koja održavaju kodnu bazu čitljivom i dosljednom za buduće pokretanje agenta. Na primjer: (1) preferiramo dijeljene pakete uslužnih programa umjesto ručno pisanih pomoćnih funkcija kako bismo invarijante držali centraliziranim, i (2) ne ispitujemo podatke “YOLO-stilom”—provjeravamo granice ili se oslanjamo na tipizirane SDK-ove kako agent ne bi mogao slučajno graditi na pretpostavljenim oblicima. U redovnim intervalima imamo skup pozadinskih zadataka Codex koji pretražuju odstupanja, ažuriraju ocjene kvaliteta i otvaraju ciljane pull requestove za refaktorisanje. Većinu ovih možete pregledati za manje od minute i automatski spojiti.

Ovo funkcioniše kao sakupljanje smeća. Tehnički dug je poput kredita s visokom kamatnom stopom: gotovo je uvijek bolje otplaćivati ga kontinuirano u malim obrocima nego dopustiti da se akumulira i rješavati ga u bolnim naletima. Ljudski ukus se jednom zabilježi, a zatim se neprekidno primjenjuje na svaku liniju koda. Ovo nam također omogućava da svakodnevno uočavamo i rješavamo loše obrasce, umjesto da im dopustimo da se šire u bazi koda danima ili sedmicama.

Ova strategija je do sada dobro funkcionisala do internog lansiranja i usvajanja u OpenAI. Izgradnja stvarnog proizvoda za stvarne korisnike pomogla je da naša ulaganja usidrimo u stvarnost i usmjerimo ka dugoročnoj održivosti.

Ono što još ne znamo je kako se arhitektonska koherentnost razvija tokom godina u potpuno agent-generisanom sistemu. Još uvijek učimo gdje ljudska prosudba donosi najveću prednost i kako tu prosudbu kodirati da se ona umnožava. Također ne znamo kako će se ovaj sistem razvijati dok modeli s vremenom postaju sve sposobniji.

Ono što je postalo jasno: izgradnja softvera i dalje zahtijeva disciplinu, ali se disciplina više očituje u pomoćnoj strukturi nego u samom kodu. Alati, apstrakcije i povratne petlje koje održavaju koherentnost baze koda postaju sve važniji.

Naši najteži izazovi sada se usmjeravaju na dizajniranje okruženja, povratnih petlji i kontrolnih sistema koji pomažu agentima da postignu naš cilj: izgraditi i održavati složen i pouzdan softver u velikom obimu.

Kako agenti poput Codexa preuzimaju veće dijelove životnog ciklusa softvera, ova pitanja će postati još važnija. Nadamo se da će dijeljenje nekih ranih lekcija pomoći da razmislite o tome gdje uložiti svoj trud kako biste mogli jednostavno graditi stvari.