Hogyan készítettük el a Sora Android-verzióját 28 nap alatt a Codex segítségével

2026. április 26-tól a Sora termék már nem érhető el.

Novemberben világszerte elindítottuk a Sora Android appot, amivel bárki, akinek Androidos készüléke van, egy rövid utasításból látványos videót készíthet. A megjelenés napján az app az 1. helyre került a Play Áruházban. Az Android-felhasználók az első 24 órában több mint egymillió videót generáltak.

A bevezetés mögött meghúzódó történeti szál: a Sora éles Android-appjának első verziója 28 nap alatt készült el, ugyanannak az ügynöknek köszönhetően, amely bármely csapat vagy fejlesztő számára elérhető: a Codexnek.

2025. október 8. és november 5. között egy kis létszámú mérnökcsapat a Codexszel együtt dolgozva, nagyjából 5 milliárd token felhasználásával jutott el a Sora Android-verziójával a prototípustól a globális megjelenésig A mérete ellenére az app 99,9%-os összeomlásmentes arányt hoz, és olyan architektúrája van, amire büszkék vagyunk. Ha azon tűnődsz, hogy valamilyen titkos modellt használtunk-e: a GPT‑5.1‑Codex modell egy korai verzióját vettük igénybe – ugyanazt a verziót, amit ma bármely fejlesztő vagy cég használhat CLI-n, IDE-bővítményen vagy webes appon keresztül.

Amikor a Sora elindult iOS-en, a használat robbanásszerűen megugrott. Az emberek azonnal elkezdtek folyamatosan videókat generálni. Androidon ezzel szemben csak egy kis belső prototípusunk volt, miközben a Google Playen egyre nőtt az előregisztrált felhasználók száma.

A nagy tétekkel járó, időhiányos bevezetésekre adott gyakori reakció az erőforrások és a folyamatok növelése. Egy ekkora léptékű és minőségű éles appon általában sok mérnök dolgozik hónapokig, akiket a koordináció lelassít. 

Fred Brooks amerikai számítógép-architektus híresen figyelmeztetett arra, hogy „ha több embert adunk hozzá egy késésben lévő szoftverprojekthez, az csak még később készül el”. Másképp fogalmazva: amikor egy összetett projektet próbálunk gyorsan elkészíteni, a több mérnök gyakran inkább lassítja a munkát a megnövekedett kommunikációs terhek, a feladatok feldarabolása és az integrációs költségek miatt. Mi nem figyelmen kívül hagytuk ezt a felismerést, hanem tudatosan építettünk rá: összeállítottunk egy erős, négyfős mérnökcsapatot, ahol mindenki Codexszel dolgozott, hogy drasztikusan növeljük az egyes mérnökök által a projektre kifejtett hatást. 

Így dolgozva 18 nap alatt eljuttattuk a Sora Android-verziójának belső buildjét az alkalmazottakhoz, majd tíz nappal később nyilvánosan is elindítottuk. Magas színvonalú Android fejlesztési gyakorlatokat tartottunk fenn, sokat fektettünk a karbantarthatóságba, és az appot ugyanarra a megbízhatósági szintre emeltük, amit egy hagyományosabb projekttől is elvárnánk. (A Codexet azóta is intenzíven használjuk, hogy továbbfejlesszük az appot és új funkciókat adjunk hozzá.)

Ahhoz, hogy érthető legyen, miként dolgoztunk együtt a Codexszel, érdemes megismerni, miben erős, és hol van szüksége iránymutatásra. Jó megközelítés volt úgy kezelni, mintha egy frissen felvett vezető mérnök lenne. A Codex képességeinek köszönhetően több időt tudtunk irányítással és kódellenőrzéssel tölteni, mint magával a kód megírásával.

Ahol a Codexnek iránymutatásra van szüksége

1. A Codex még nem igazán jó abban, hogy olyan dolgokat kikövetkeztessen ki, amiket nem mondtunk el neki (például az általunk preferált architektúramintákat, a termékstratégiát, a valós felhasználói viselkedést, illetve a belső szokásokat vagy gyorsparancsokat).
2. Hasonlóképpen a Codex nem volt képes átlátni az app valódi működését sem: nem tudta megnyitni a Sorát egy eszközön, észlelni, hogy egy görgetés furcsának tűnik, vagy érzékelni, ha egy folyamat zavaros. Ezeket az élményalapú feladatokat csak a csapatunk volt képes feldolgozni.
3. Minden példány bevezetést igényel. Az volt a kulcs a jó működéshez, hogy világos célokat, korlátokat és iránymutatást adtunk arról, „hogyan miként végezzük a munkát”, és így osztottuk meg a kontextust a Codexszel.
4. Hasonló módon a Codex a mélyebb architekturális döntésekkel is megküzdött: ha magára hagytuk, előfordult, hogy egy plusz nézetmodellt vezetett be ott, ahol inkább egy meglévőt kellett volna bővíteni, vagy olyan logikát tolt a UI-rétegbe, amely egyértelműen az adattárba tartozott volna. Ösztönösen arra törekszik, hogy valami működjön, nem pedig arra, hogy a hosszú távú tisztaságot helyezze előtérbe.

Hasznosnak találtuk, hogy a Codex rengeteg AGENT.md fájlt hozzon létre és tartson karban a teljes kódbázisban. Így könnyű volt ugyanazokat az iránymutatásokat és bevált gyakorlatokat alkalmazni az egyes munkamenetek között. Például annak érdekében, hogy a Codex a mi stílusirányelveink szerint írjon kódot, a legfelső szintű AGENTS.md fájlba a következőt tettük bele:

Amiben a Codex igazán erős

1. Nagy kódbázisok gyors olvasása és megértése: A Codex gyakorlatilag minden jelentős programozási nyelvet ismer, ami megkönnyíti ugyanazon fogalmak alkalmazását sok platformon, bonyolult absztrakciók nélkül.
2. Tesztlefedettség: a Codex (meglepően) kifejezetten lelkes az egységtesztek írásában, és sokféle esetet lefed. Nem minden teszt volt igazán mély, de a széles lefedettség sokat segített a regressziók megelőzésében. 
3. Visszajelzések alkalmazása: hasonlóan ehhez, a Codex jól reagál a visszajelzésekre. Amikor a CI sikertelen volt, be tudtuk másolni a naplókimenetet egy utasításba, és megkértük a Codexet, hogy ajánljon javításokat.
4. Tömegesen párhuzamos, eldobható végrehajtás: a legtöbben nem feszegetik annak a határát, hány munkamenetet lehet egyszerre futtatni. Teljesen reális több ötletet párhuzamosan kipróbálni, és a kódra eldobható elemként tekinteni.
5. Új nézőpontok felkínálása: tervezési megbeszéléseken a Codexet generatív eszközként használtuk, hogy feltérképezzük a lehetséges meghibásodási pontokat, és új megoldásokat találjunk egy problémára. A videólejátszó memóriára vonatkozó optimalizálásainak tervezésekor például a Codex több SDK-t is átnézett, és olyan megközelítéseket javasolt, amelyek részletes átvizsgálására nekünk nem lett volna időnk. A Codex kutatásából származó felismerések felbecsülhetetlennek bizonyultak a végső app memóriaigényének minimalizálásában.
6. Nagyobb hatású munka lehetővé tétele: a gyakorlatban végül több időt töltöttünk a kód átnézésével és irányításával, mint annak saját kezű megírásával. Ettől függetlenül a Codex a kódellenőrzésben is nagyon jó, gyakran még az egyesítés előtt kiszúrja a hibákat, javítva ezzel a megbízhatóságot.

Miután felismertük ezeket a jellemzőket, a munkamodellünk egyszerűbbé vált. A Codexre bíztuk a munka nagy részét jól ismert mintákon és jól körülhatárolt területeken belül, miközben a csapatunk az architektúrára, a felhasználói élményre, a rendszerszintű változtatásokra és a végső minőségre összpontosított.

Még a legjobb, újonnan felvett senior mérnöknek sincs azonnal meg a megfelelő rálátása ahhoz, hogy hosszú távú kompromisszumokról döntsön. Ahhoz, hogy jól ki tudjuk használni a Codexet, és a munkája tartós és karbantartható legyen, kulcsfontosságú volt, hogy mi magunk felügyeljük az app rendszertervét és a fontosabb kompromisszumokat. Ezek közé tartozott az alkalmazás architektúrájának kialakítása, a modularizáció, a függőségi injektálás és a navigáció; továbbá megvalósítottuk a hitelesítést és az alapvető hálózati folyamatokat. 

Erre az alapra építve néhány reprezentatív funkciót teljes egészében, elejétől a végéig mi írtunk meg. Azokat a szabályokat alkalmaztuk, amelyeket az egész kódbázisra érvényesnek szerettünk volna, és menet közben dokumentáltuk a projekt-szintű mintákat. Azáltal, hogy a Codexet ezekre a reprezentatív funkciókra irányítottuk, sokkal önállóbban tudott dolgozni a mi elvárásaink szerint. Egy olyan projektben, amelynek becslésünk szerint 85%-át a Codex írta, a gondosan megtervezett alap elkerülte a költséges visszalépéseket és refaktorálásokat. Ez volt az egyik legfontosabb döntésünk. 

Az elképzelés nem az volt, hogy a lehető leggyorsabban összedobjunk „valamit, ami működik”, hanem az, hogy valami olyat készítsünk, „ami érti, hogyan szeretnénk, hogy a dolgok működjenek”. Számos „helyes” módja van a kódírásnak. Nem kellett pontosan megmondanunk a Codexnek, mit csináljon; azt kellett megmutatnunk neki, mi számít „helyesnek” a csapatunknál. Miután lefektettük a kiindulópontot és azt, ahogyan építkezni szeretnénk, a Codex készen állt a munkára.

Kíváncsiságból azért kipróbáltuk azt az utasítást, hogy: „Építsd meg a Sora Android appot az iOS kód alapján. Gyerünk.”, de gyorsan megszakítottuk ezt az irányt. Bár amit a Codex létrehozott, technikailag működött, a termékkel kapcsolatos felhasználói élmény nem volt megfelelő. Ráadásul az végpontok, az adatok és a felhasználói folyamatok világos megértése nélkül a Codex egyszeri kódkimenete megbízhatatlannak bizonyult (ügynök használata nélkül is kockázatos több ezer sornyi kódot összevonni). 

Azt feltételeztük, hogy a Codex egy jól megírt példákból álló „homokozóban” érzi majd igazán jól magát – és igazunk lett. Ha szinte bármilyen kontextus nélkül azt kértük, hogy „építsd meg ezt a beállítási képernyőt”, az eredmény megbízhatatlan volt. Ha viszont arra kértük a Codexet, hogy „építsd meg ezt a beállítási képernyőt ugyanazzal az architektúrával és mintákkal, mint ez a másik képernyő, amit az imént láttál”, az sokkal jobban működött. A strukturális döntéseket és az invariánsokat mi, emberek határoztuk meg, a Codex pedig ezen a struktúrán belül töltötte be a kód nagy részét.

A következő lépés a Codexben rejlő lehetőségek maximalizálásában az volt, hogy kitaláljuk, hogyan tudjuk elérni, hogy a Codex hosszú ideig (a közelmúltban 24 óránál tovább⁠), felügyelet nélkül dolgozzon.

A Codex használatának elején rögtön olyan utasításokkal próbálkoztunk, mint az „Itt a funkció. Itt van néhány fájl. Építsd meg.” Ez néha működött, többnyire azonban olyan kódot kaptunk, ami technikailag ugyan lefordult, viszont eltért az architektúránktól és a céljainktól.

Ezért megváltoztattuk a munkafolyamatot. Minden nem triviális változtatásnál először a Codexet kértük meg, hogy segítsen megérteni, hogyan működik a rendszer és a kód. Megkérnénk például, hogy olvasson el egy sor kapcsolódó fájlt, és foglalja össze, hogyan működik ez a funkció; például, hogyan áramlik az adat az API-ból a tárolórétegen, a nézetmodellen keresztül, majd onnan az UI-ba. Ezután kijavítanánk vagy finomítanánk a megértését. (Például rámutatnánk arra, hogy egy adott absztrakció valójában egy másik rétegbe tartozik, vagy hogy egy adott osztály csak offline módban létezik, és nem terjeszthető ki.)

Hasonlóan ahhoz, ahogyan egy új, rendkívül tehetséges csapattárssal dolgoznál együtt, a Codexszel együttműködve egy szilárd megvalósítási terv létrehozásán dolgoztunk. Ez a terv gyakran úgy nézett ki, mint egy mini tervezési dokumentum, ami megmondta, mely fájlok módosuljanak, milyen új állapotokat kell bevezetni, és hogyan működjön a logika. Csak ezután kértük meg a Codexet, hogy kezdje el megvalósítani a tervet, lépésről lépésre. Egy hasznos tipp: nagyon hosszú feladatoknál, amikor elértük a kontextusablak korlátját, megkértük a Codexet, hogy mentse el a tervet egy fájlba, így ugyanazt az irányt több példányon keresztül is tudtuk alkalmazni.

Ez az extra tervezési kör végül megérte a ráfordított időt. Lehetővé tette, hogy a Codex hosszabb ideig „felügyelet nélkül” fusson, mert ismertük a terveit. Könnyebbé tette a kódellenőrzést is, mert a megvalósítást a tervhez tudtuk viszonyítani, nem pedig kontextus nélküli különbségeket kellett átnézni. És ha valami rosszul sikerült, el tudtuk végezni először a terv, majd a kód hibakeresését. 

A dinamika hasonló volt ahhoz, ahogyan egy jó tervdokumentum bizalommal tölti el a műszaki vezetőt egy projektben. Nem csak kód generálásával foglalkoztunk: közös ütemtervet támogató kódot hoztunk létre.

A projekt csúcspontján gyakran több Codex munkamenet futott párhuzamosan. Az egyik a lejátszáson, a másik a keresésen, a harmadik a hibakezelésen, és néha egy másik a teszteken vagy a refaktorálásokon dolgozott. Inkább olyan érzés volt, mintha egy csapatot irányítanánk, nem pedig egy eszközt használnánk.

Minden munkamenet időről időre visszajelzett az előrehaladásról. Az egyik azt mondta: „Végeztem ennek a modulnak a megtervezésével, ezt javaslom”, egy másik pedig egy nagy eltérést (diffet) hozott egy új funkcióhoz. Mindegyik figyelmet, visszajelzést és átnézést igényelt. Mindez kísértetiesen hasonlított arra, mintha műszaki vezetőként több új mérnököt irányítanánk: mind haladtak, mindenkinek útmutatásra volt szüksége.

Az eredmény egy együttműködésen alapuló munkafolyamat lett. A Codex nyers kódolási képessége megszabadított minket rengeteg kézi gépeléstől. Több időnk maradt az architektúrán gondolkodni, alaposan átnézni a pull kéréseket, és kipróbálni az alkalmazást. 

Ez a plusz sebesség ugyanakkor azt is jelentette, hogy mindig volt valami, ami várt ránk az felülvizsgálati sorban. A Codexet nem akadályozta a kontextusváltás, minket viszont igen. A fejlesztés szűk keresztmetszete a kódírásról áttevődött a döntéshozatalra, a visszajelzésre és a változtatások integrálására.

Itt nyernek új értelmet Brooks meglátásai. Nem lehet egyszerűen csak újabb Codex-munkameneteket hozzáadni, és lineáris gyorsulást várni, ugyanúgy, ahogy nem lehet folyamatosan új mérnököket felvenni egy projektre, és azt hinni, hogy az ütemterv arányosan rövidebb lesz. Minden egyes további „kézpár”, még a virtuálisak is, koordinációs többletterhelést eredményeznek. Egy zenekar karmesterévé váltunk, nem pedig egyszerűen gyorsabb szólózenészekké.

A projektünket hatalmas előnnyel indítottuk: a Sora már elérhető volt iOS-en. Gyakran ráirányítottuk a Codexet az iOS és a backend kódbázisaira, hogy megértse a kulcsfontosságú követelményeket és korlátokat. A projekt során végig azzal viccelődtünk, hogy újra feltaláltuk a platformfüggetlen keretrendszer ötletét. Felejtsd el a React Native-ot vagy a Fluttert; a platformfüggetlenség jövője egyszerűen a Codex.

A poén mögött két alapelv áll:

1. A logika hordozható. Függetlenül attól, hogy a kód Swiftben vagy Kotlinban íródik, az alapvető alkalmazáslogika – adatmodellek, hálózati hívások, validációs szabályok, üzleti logika – ugyanaz. A Codex nagyon jó abban, hogy elolvasson egy Swift implementációt, és készítsen belőle egy szemantikailag azonos Kotlin-verziót.
2. A konkrét példák nagyon erős kontextust adnak. Egy friss Codex-munkamenet, amely látja, hogy „pontosan így működik iOS-en” és „ilyen az Android-architektúra”, sokkal hatékonyabb, mint egy olyan, ami csak természetes nyelvű leírásokból dolgozik.

Ezeket az elveket alkalmazva elérhetővé tettük az iOS, a backend és az Android repókat ugyanabban a környezetben. A Codex-nek olyan utasításokat adtunk, mint például a következők:

„Olvasd át az iOS-kódban ezeket a modelleket és végpontokat, majd javasolj egy tervet arra, hogyan valósítsuk meg az Androidon az ezzel egyenértékű viselkedést a meglévő API-kliensünkkel és modellosztályainkkal.”

Apró, de hasznos trükknek bizonyult, hogy a ~/.codex/AGENTS.md fájlban részletesen leírtuk, hol vannak a helyi repók, és mi található bennük Így a Codex könnyebben megtalálta a releváns kódot és odanavigálhatott.

Gyakorlatilag a közös absztrakció helyett fordítással végeztük a platformokon átívelő fejlesztést. Mivel a fordítás nagy részét a Codex végezte, sikerült elkerülni a végrehajtási költségek megduplázódását.

A tágabb értelemben vett tanulság az, hogy a Codex esetében a kontextus a legfontosabb. A Codex akkor végezte a legjobb munkát, amikor megértette, hogyan működik már a funkció az iOS-ben, valamint azt is, hogyan épül fel az Android-alkalmazásunk. Amikor a Codexnek hiányzott a kontextus, nem „megtagadta az együttműködést” – hanem találgatott. Minél inkább úgy kezeltük, mint egy új csapattagot, és a megfelelő bevitelek biztosítottuk, annál jobban teljesített.

A négyhetes sprint végére a Codex használata már nem tűnt kísérletezésnek, hanem az alapértelmezett fejlesztési ciklusunkká vált. A meglévő kód megértésére, a változtatások megtervezésére és a funkciók megvalósítására használtuk. Ugyanúgy átnéztük a kimenetét, mint ahogy egy csapattársunk munkáját átnéznénk. Egyszerűen így készítettük el a szoftvert.

Világossá vált, hogy az AI által támogatott fejlesztés nem csökkenti a szigorúság szükségességét; inkább növeli azt. Bármennyire is képes jelenleg a Codex, célja most az, hogy eljusson A-ból B-be. Ezért nem működik az AI által támogatott kódolás emberek nélkül. A szoftvermérnökök képesek megérteni és alkalmazni a rendszerek valós korlátozásait, a szoftverek architektúrájának legjobb módjait, valamint azt, hogyan lehet a jövőbeli fejlesztési és terméktervek figyelembevételével építeni. A holnap szoftvermérnökeinek szuperképessége a rendszerek mély megértése és a mesterséges intelligenciával való hosszú távú együttműködés képessége lesz. 

A szoftverfejlesztés legérdekesebb részeit a meggyőző termékek létrehozása, a skálázható rendszerek tervezése, az összetett algoritmusok írása, valamint az adatokkal, mintákkal és kódokkal való kísérletezés jelenti. A múlt és a jelen szoftverfejlesztésének valósága azonban gyakran sokkal hétköznapibb: gombok középre igazítása, a végpontok bekötése és a boilerplate kód megírása. A Codex most lehetővé teszi, hogy a szoftverfejlesztés igazán lényeges részeire koncentráljunk, és arra, amiért szeretjük ezt a szakmát.

Ha a Codexet egy gazdag kontextusú környezetben állítod be, ahol érti a céljaidat és azt, hogyan szeretsz dolgozni, bármely csapat megsokszorozhatja a képességeit. A mi bevezetésünk nem egy általános recept, és nem állítjuk, hogy megoldottuk a mesterséges intelligencia által támogatott fejlesztést. Reméljük azonban, hogy tapasztalataink segítségével könnyebben megtaláljuk a legjobb módját annak, hogy a Codexet a számodra is használhatóvá tegyük. 

Amikor a Codex hét hónappal ezelőtt egy kutatási előnézetben elindult, a szoftverfejlesztés egészen másképp nézett ki. A Sora révén felfedezhettük a mérnöki munka következő fejezetét. Ahogy a modelljeink és a hámunk folyamatosan fejlődik, a mesterséges intelligencia egyre inkább nélkülözhetetlen része lesz az építkezésnek. 

Mit fogsz alkotni a saját Codex-csapatoddal?