PLAYGRND ima javni web proizvod, backend, mobilne klijente, AI workflowe, podatke o natjecanjima, dizajn, operacije, sadržaj, komercijalna pitanja i sve veći broj odluka koje moraju ostati međusobno usklađene.

Staviti sve to u jedan dugi razgovor s AI-em zvuči učinkovito. U praksi nastaje novo usko grlo: svaki zadatak nosi povijest svih ostalih zadataka, vlasništvo postaje nejasno, a koristan odgovor se i dalje može sudariti s radom koji se odvija drugdje.

Projekt trenutačno organiziramo kroz 12 trajnih Codex threadova. Svaki čuva kontekst jedne uloge. Zaseban PM thread orkestrira njihov redoslijed i ovisnosti.

To nisu dvanaest zaposlenika ni dvanaest autonomnih sustava koji bez nadzora donose produktne odluke. To su radni prostori pod ljudskim nadzorom, s različitim odgovornostima, koji rade nad istim repozitorijem, produktnom dokumentacijom i acceptance procesom. HILLS Lab ostaje odgovoran za prioritete, review i odluke o releaseu.

Dvanaest uloga

Podjela prati trajno vlasništvo, a ne pojedinačne featuree.

  • PM održava aktualnu sliku proizvoda, određuje redoslijed rada, rješava ovisnosti i bira kojem specijalistu pripada sljedeći ograničeni zadatak.
  • Dev posjeduje glavnu implementaciju kroz backend, bazu i server-rendered web proizvod.
  • Design unapređuje javno i prijavljeno iskustvo na desktopu i mobitelu bez tihog mijenjanja produktnih pravila.
  • AI posjeduje ponašanje asistenta, determinističke akcije, evaluacije i granicu između generiranog prijedloga i prihvaćene promjene.
  • Mobile štiti iOS i Android ugovor, kompatibilnost releaseova i ponašanje specifično za uređaje.
  • Termini vodi rasporede i uključivanje natjecanja, gdje su kvaliteta izvora, datumi i kanonski zapisi posebno važni.
  • Social pretvara provjereni materijal o proizvodu u javni sadržaj bez izmišljanja featurea ili rezultata.
  • Sales radi na ponudi, kvalifikaciji i komercijalnom putu oko onoga što proizvod stvarno može isporučiti.
  • Audit neovisno provjerava rizične pretpostavke, failure modeove i acceptance dokaze prije nego što release proglasimo sigurnim.
  • Legal prepoznaje pitanja privatnosti, tvrdnji, dozvola i ugovora koja traže oprezan produktni tretman ili pregled kvalificiranog pravnika.
  • Competitors proučava javno dostupne proizvode i kretanje tržišta radi boljeg pozicioniranja, bez kopiranja vlasničkog koda, podataka ili dizajna.
  • Pitch održava koherentnu vanjsku priču temeljenu na isporučenim činjenicama i jasno označenom smjeru proizvoda.

Vrijednost ovakve podjele nije u tome da je svaka uloga stalno zauzeta. Većina treba mirovati dok njezin kontekst ne postane koristan. Trajna uloga je pripremljena traka za rad, a ne cilj maksimalne aktivnosti.

PM thread igra vezni red

PM thread je kontrolni toranj, ali nogomet daje bolju metaforu: igra vezni red.

Vidi dovoljno terena da odabere sljedeće dodavanje. Ne pokušava sam završiti svaki napad.

Uobičajen orkestracijski ciklus izgleda ovako:

  1. Pročitati aktualno stanje repozitorija, otvorene produktne odluke i handovere specijalista.
  2. Odvojiti ono što je live od onoga što je planirano i onoga što još čeka ljudski QA.
  3. Odabrati najmanji vrijedan rez i dodijeliti mu jednog jasnog vlasnika.
  4. Pauzirati drugi build rad ako bi se sudario s istim datotekama, istom schemom ili releaseom.
  5. Vratiti nalaze specijalista vlasniku. Audit nalaz, primjerice, postaje Dev acceptance uvjet, a ne druga paralelna implementacija.
  6. Tražiti testove, čisto stanje sourcea i produkcijski dokaz prije nego što se rez proglasi isporučenim.
  7. Završnu produktnu i QA odluku vratiti čovjeku.

Ta razlika je važna. Orkestrator koji implementira svaki zadatak s vremenom postaje samo još jedan prevelik thread. Naš PM thread koordinira vlasništvo; ne preuzima queueove specijalista.

Jedan repozitorij i dalje treba jednu istinu

Paralelan AI rad ne uklanja uobičajena ograničenja software inženjeringa. Dva sposobna threada i dalje mogu mijenjati istu datoteku, pretpostaviti različito stanje scheme ili nedovršeni feature opisati kao live.

Zato repozitorij tretiramo kao kanonsko tehničko stanje. Prije početka novog reza PM provjerava koji je rad aktivan, koje promjene pripadaju drugoj ulozi i koristi li se još zaseban worktree. Postojeće necommitane promjene čuvamo; ne čistimo ih radi praktičnosti.

Ista disciplina vrijedi nakon implementacije. Commit je dokaz da kod postoji. Nije dokaz da je deploy završio, da je migracija ispravno izvršena ili da se javna ruta ponaša kako očekujemo. Za takve tvrdnje trebaju zasebne provjere.

Sve ovo zvuči proceduralno dok se dva radna toka ne susretnu u istoj migraciji ili releaseu. Tada je to razlika između paralelizma i race conditiona.

Handover je dio arhitekture

Dugotrajni threadovi skupljaju odluke, neuspjele pokušaje, izlaze alata i stare pretpostavke. U jednom trenutku korisni kontekst postane teže pronaći nego što je ukupan kontekst lako spremiti.

To rješavamo epizodama. Kada thread jedne uloge postane pregust, piše sažeti handover koji sadrži:

  • aktualno provjereno stanje;
  • rad koji je još u tijeku;
  • odluke koje ne treba ponovno otvarati bez novih dokaza;
  • datoteke ili produktne granice koje posjeduje drugi tok;
  • najmanji siguran sljedeći korak.

Nova epizoda počinje iz tog handovera i živog repozitorija. Potpuna povijest ostaje dostupna, ali više ne mora biti dio aktivnog radnog seta.

To je context engineering u praktičnom obliku. Cilj nije sačuvati svaku rečenicu prompta. Cilj je sačuvati odluke i dokaze potrebne za sljedeću ispravnu akciju.

Snapshot bez izmišljene token matematike

U jednom egzaktnom health snapshotu svih 12 aktualnih threadova po ulogama izbrojali smo 45 API-level turnova, 1.141 zapisanu stavku povijesti i 16 context compactiona. Sedam threadova bilo je u low-load rasponu, četiri u medium, jedan u high, a nijedan u extreme.

Te brojke opisuju oblik workflowa, ne produktivnost. Jedan kratak Audit turn može spriječiti dane popravaka. Dugi Design thread možda je samo spreman za čist handover.

Ne objavljujemo procijenjeni broj tokena jer sažeta i skraćena povijest ne omogućuje pouzdanu rekonstrukciju billing tokena. Precizno formulirana pretpostavka bila bi manje korisna od brojeva koje možemo provjeriti.

Za ovaj rad koristimo 20x Codex pretplatnički paket. Dodatni kapacitet je koristan jer specijalizirani konteksti mogu ostati dostupni dok se često izvode ograničeni zadaci. Paket ne daje orkestraciju. Više kapaciteta bez vlasništva, redoslijeda i release gateova samo bi brže proizvelo konflikte.

Gdje ostaje ljudska prosudba

Sustav namjerno ostavlja nekoliko odluka izvan automatskog izvršavanja:

  • koji problem sada vrijedi rješavati;
  • je li produktni trade-off prihvatljiv;
  • traže li pravna pitanja ili privatnost pregled kvalificiranog stručnjaka;
  • jesu li dokazi dovoljno jaki da feature opišemo kao isporučen;
  • je li rezultat dovoljno dobar za korisnike.

Legal i Competitors threadovi su funkcije podrške, a ne prečac oko stručnog savjeta, licenci ili granica izvora. Audit može izložiti rizik; ne može umjesto tvrtke definirati toleranciju rizika. PM može predložiti sljedeći rez; nema završnu produktnu odluku.

Ta granica čini workflow korisnijim, a ne manje automatiziranim. Codex preuzima veći dio čitanja, usporedbe, draftanja, implementacije i provjere. Ljudi više vremena troše na prioritete, prosudbu i acceptance.

Što ovo pokazuje o radu HILLS Laba

Zanimljiva jedinica nije prompt ni pojedinačni thread. Zanimljiv je operativni sustav oko njih:

  • trajno vlasništvo umjesto jednog univerzalnog chata;
  • kratki handoveri temeljeni na dokazima;
  • kanonski repozitorij i jasno održavanje worktreeova;
  • neovisan pregled rizika;
  • jasna razlika između isporučenih činjenica i roadmap namjere;
  • ljudski gateovi tamo gdje su posljedice veće od sigurnosti automatizacije.

PLAYGRND nam daje zahtjevno mjesto za testiranje tog modela jer se kod, podaci, product, dizajn i operacije redovito susreću u istom releaseu.

Za software timove pouka je jednostavna: dodati više AI kapaciteta je lako. Dizajnirati workflow u kojem nekoliko AI konteksta može pridonositi bez gubitka odgovornosti pravi je inženjerski posao.

Ako vaš tim dolazi do granica jednog dugog AI razgovora, možemo pomoći postaviti granice uloga, handovere i verifikacijski loop oko proizvoda koji već imate. Javite se HILLS Labu.