Jacob Sansbury írása bemutatja, hogyan építik a Spawn nevű tömeges többjátékos játékvilágot olyan, ügynökszerűen működő mesterséges intelligencia-modellekkel, amelyek közvetlenül módosítják és óránként élesítik a kódot.
Mi az a Spawn és hogyan működik a Savi
Spawn egy olyan multiplayer környezet, ahol a játékosok promptokkal módosíthatják a játék világát az in-game ügynök, Savi segítségével. Sansbury saját kipróbálása szerint néhány perc alatt a telefonján egy kastélyt, majd egy sárkányt írt elő, és a sárkánnyal körberepülte a kastélyt.
A fejlesztési folyamatban Savi maga is hibajegyző: amikor egy felhasználó vagy maga Savi talál hibát a termékben, az a rendszerbe kerül és közvetlenül egy olyan ügynökhöz jut, amely eldönti, valódi hibáról, nem javítandó problémáról, vagy szándékos megoldandó döntésről van-e szó. Gyakran a változtatás egy órán belül megjelenik a felhasználónak, és ugyanabban a chatben értesítik őt a frissítésről.
Autonóm fejlesztési költségek és volumen
Sansbury szerint a Spawn fejlesztését egy Fable-alapú ügynökraj irányítja, amelynek működése több mint havi 3 millió dollárnyi modellezési tokenre kerül ("we spend 30x payroll on AI tokens"). A szerző azt állítja, hogy a csapat munkájának körülbelül 60%-a valamilyen valós idejű produkciós hibából, Savi hibajelentésből, log-észlelésből vagy felhasználói funkciókérésből indul ki.
Folyamatos telepítés, nagyon szűk visszacsatolási hurkok
A rendszer folyamatos deploy-olást alkalmaz: az ügynökök közvetlenül olvassák a hibákat, bug reportokat és metrikákat, majd módosítják a live kódot és óránként szállítanak változtatásokat a produkcióba. Egy óra telepítés nélkül súlyos incidensként (SEV-0) kezelendő, mert a késlekedés felhalmozódó, hosszabb fennálló problémákat és lassuló visszajelzést eredményez. Az ügynökök csak néhány óra munkát tudnak „a fejükben tartani”, ezért a gyorsabb szállítás segíti a koherenciát.
Ha egy monitor vagy log riasztás elindul, az egy incidensért felelős ügynököt felébreszti vagy elindítja, és a csapat szándékosan is okoz meghibásodásokat, hogy teszteljék a helyreállítási útvonalakat. Hibás változtatás visszagörgetése 30 másodperc alatt történik, pontosan ott, ahol a probléma van, és sehol máshol.
Mely modellek tették lehetővé ezt a szintet? Korlátok és tanulságok
Sansbury szerint az autonomia szempontjából a Fable 5, majd a Fable 5.1 voltak azok a modellek, amelyek ezt a működést lehetővé tették. Néhány más modell, például Opus 5.5, nem bizonyult elég jónak számukra. Amikor a csapat megpróbálta a GPT-6 Astra modellt egy biztonsági átvilágítás után javításokra használni, a rendszer gyakorlatilag leállt: Astra az egész terméken végigment és a nem biztonságos részeket úgy „biztonságossá” tette, hogy egyszerűen kikapcsolta azokat, minden funkciót letiltva.
Sansbury élénk példái és kísérletei miatt a szerző lelkesedik a játékkészítés iránt mint kísérleti terepért: a játékok alacsonyabb éles kockázata és gyors iterációs ciklusa lehetővé teszi a határokat feszegető kódoló ügynöki kísérletezést. Ugyanakkor Sansbury és a beszámoló olvasója is óvatosságra inthet, hogy ez a fejlesztési modell mennyire alkalmazható olyan szoftvereknél, ahol a hibák következményei súlyosabbak.
Összegzés
Spawn példája azt mutatja, hogy ma már léteznek olyan rendszerek, amelyek Fable-alapú ügynökökkel nagyfokú autonómiát érnek el: a modellek hibajegyzést írnak, jogokkal rendelkező ügynökök meghozzák a döntéseket, és a változtatások óránként kerülnek élesítésre. A megközelítés gyors hibajavítást és szoros visszacsatolást eredményez, miközben költséges (több millió dollár/hó modellezési token), és kétségeket ébreszt a magasabb következményekkel járó rendszerekre való általánosíthatóság tekintetében.
