Si e përdorëm Codex për të ndërtuar Sora për Android në 28 ditë

Që nga 26.4.2026, produkti Sora nuk është më i disponueshëm.

Në nëntor, ne lançuam aplikacionin Sora për Android në mbarë botën, duke i dhënë kujtdo që ka një pajisje Android mundësinë për të shndërruar një kërkesë të shkurtër në një video të gjallë. Në ditën e lançimit, aplikacioni arriti vendin e parë në Play Store. Përdoruesit e Android përftuan më shumë se një milion video në 24 orët e para.

Pas lançimit fshihet një histori: versioni fillestar i aplikacionit të prodhimit Android të Sora u ndërtua në 28 ditë, falë të njëjtit agjent që është i disponueshëm për çdo ekip ose zhvillues: Codex.

Nga data 8 tetor deri më 5 nëntor 2025, një ekip i vogël inxhinierik që punonte së bashku me Codex dhe përdorte afërsisht 5 miliardë token, dërgoi Sora për Android nga prototipi deri në lançimin global. Pavarësisht madhësisë së tij, aplikacioni ka një normë pa ndërprerje prej 99.9 përqind dhe një arkitekturë për të cilën jemi krenarë. Nëse po pyesni nëse kemi përdorur një model sekret, kemi përdorur një version të hershëm të modelit GPT‑5.1‑Codex – i njëjti version që çdo zhvillues ose biznes mund ta përdorë sot përmes CLI, shtesës IDE ose aplikacionit në ueb.

Kur Sora u lançua në iOS, përdorimi u rrit ndjeshëm. Njerëzit menjëherë filluan të përftojnë një sërë videosh. Në Android, në të kundërt, kishim vetëm një prototip të vogël të brendshëm dhe një numër në rritje të përdoruesve të pararegjistruar në Google Play.

Një përgjigje e zakonshme ndaj një lançimi me rrezik të lartë dhe nën presionin e kohës është të shtosh burime dhe të shtosh proces. Një aplikacion prodhimi i kësaj shtrirjeje dhe cilësie zakonisht do të përfshinte shumë inxhinierë që punojnë për muaj të tërë, të ngadalësuar nga koordinimi. 

Arkitekti amerikan i kompjuterëve Fred Brooks paralajmëroi bindshëm se "shtimi i më shumë njerëzve në një projekt softuerik të vonuar e bën atë edhe më të vonuar." Me fjalë të tjera, kur përpiqesh të dërgosh një projekt kompleks shpejt, shtimi i më shumë inxhinierëve shpesh mund të ngadalësojë efikasitetin duke shtuar ngarkesën e komunikimit, fragmentimin e detyrave dhe kostot e integrimit. Ne u mbështetëm në këtë njohuri në vend që ta injoronim; ne formuam një Team të fortë prej katër inxhinierësh – të gjithë të pajisur me Codex për të rritur ndjeshëm ndikimin e secilit inxhinier. 

Duke punuar në këtë mënyrë, ne dërguam një version të brendshëm të Sora për Android te punonjësit brenda 18 ditësh dhe e lançuam publikisht 10 ditë më vonë. Ne mbajtëm një standard të lartë për praktikat inxhinierike në Android, investuam në mirëmbajtje dhe e mbajtëm aplikacionin në të njëjtin standard besueshmërie që do të prisnim nga një projekt më tradicional. (Ne gjithashtu vazhdojmë të përdorim Codex gjerësisht sot për të evoluar dhe sjellë veçori të reja në aplikacionin tonë).

Për të kuptuar se si kemi punuar me Codex, është e dobishme të dimë se ku shkëlqen dhe ku ka nevojë për udhëzim. Ta trajtosh atë si një inxhinier të ri të lartë ishte një qasje e mirë. Aftësia e Codex-it nënkuptonte që mund të kalonim më shumë kohë duke drejtuar dhe rishikuar kodin sesa duke e shkruar vetë.

Fushat ku Codex ka nevojë për udhëzime

1. Codex ende nuk është i shkëlqyer në nxjerrjen e përfundimeve për atë që nuk i është thënë (p.sh., modelet e tua të preferuara të arkitekturës, strategjia e produktit, sjellja reale e përdoruesve dhe normat ose shkurtoret e brendshme).
2. Në mënyrë të ngjashme, Codex nuk mund ta shihte aplikacionin të funksiononte në të vërtetë: Nuk mund ta hapte Sora në një pajisje, të vërente që një rrotullim nuk ishte i saktë, ose të ndjente që një rrjedhë ishte konfuze. Vetëm ekipi ynë mund të mbulonte këto detyra të bazuara në eksperiencë.
3. Çdo rast kërkon përgatitje fillestare. Ndarja e kontekstit me qëllime të qarta, kufizime dhe udhëzime mbi "si i bëjmë gjërat" ishte thelbësore për të bërë që Codex të ekzekutojë mirë.
4. Në të njëjtën mënyrë, Codex kishte vështirësi me gjykimin e thellë arkitekturor: I lënë vetëm, mund të prezantonte një model pamjeje shtesë aty ku ne vërtet donim të zgjeronim një ekzistues ose të shtynim logjikën në shtresën e UI që qartësisht i përkiste një depoje. Instinkti i tij është të bëjë diçka që të funksionojë, jo t'i japë përparësi pastërtisë në planin afatgjatë.

E pamë të dobishme që Codex të krijojë dhe të mirëmbajë një numër të madh skedarësh AGENT.md në të gjithë bazën e kodit. Kjo e bëri të lehtë zbatimin e të njëjtave udhëzime dhe praktikave më të mira nëpër sesione. Për shembull, për të siguruar që Codex të shkruante kodin sipas udhëzimeve tona të stilit, ne shtuam sa vijon në AGENTS.md në nivelin më të lartë:

Ku shkëlqen Codex

1. Leximi dhe kuptimi i bazave të mëdha të kodit me shpejtësi: Codex njeh në thelb të gjitha gjuhët kryesore të programimit, gjë që e bën më të lehtë përdorimin e të njëjtave koncepte në shumë platforma pa abstraksione komplekse.
2. Mbulimi i testimit: Codex është (në mënyrë unike) entuziast për të shkruar teste njësie për të mbuluar një gamë të gjerë rastesh. Jo çdo test ishte i thellë, por gjerësia e mbulimit ndihmoi në parandalimin e regresioneve. 
3. Zbatimi i përshtypjeve: Në të njëjtën mënyrë, Codex është i mirë në reagimin ndaj përshtypjeve. Kur CI dështoi, mund të ngjisnim daljen e regjistrit në një kërkesë dhe t'i kërkonim Codex-it të propozojë rregullime.
4. Ekzekutim masivisht paralel, i disponueshëm: Shumica nuk do të shtyjnë kufijtë e numrit të sesioneve që mund të ekzekutojnë në të njëjtën kohë. Është shumë e mundur të testosh disa ide paralelisht dhe të shohësh kodin si të zëvendësueshëm.
5. Ofrimi i një perspektive të re: Në diskutimet e dizajnit, përdorëm Codex si një mjet gjenerues për të eksploruar pikat e mundshme të dështimit dhe për të zbuluar mënyra të reja për të zgjidhur një problem. Për shembull, ndërsa ne dizenjuam optimizimet e memories së luajtësit të videove, Codex kaloi nëpër disa SDK për të propozuar qasje që nuk do të kishim pasur kohë t'i analizonim. Njohuritë nga kërkimet e Codex u treguan të paçmueshme në minimizimin e gjurmës së memories në aplikacionin përfundimtar.
6. Mundësimi i punës me ndikim më të madh: Në praktikë, përfunduam duke kaluar më shumë kohë duke rishikuar dhe drejtuar kodin sesa duke e shkruar vetë. Megjithatë, Codex është shumë i mirë edhe në rishikimin e kodit, shpesh duke kapur gabime para se të shkrijen, duke përmirësuar besueshmërinë.

Pasi i pranuam këto karakteristika, modeli ynë i punës u bë më i thjeshtë. Ne u mbështetëm te Codex për të kryer një sasi të madhe pune të rëndë brenda modeleve të mirëkuptuara dhe kufijve të mirëpërcaktuar, ndërsa ekipi ynë u përqendrua në arkitekturë, përvojën e përdoruesit, ndryshimet sistemike dhe cilësinë përfundimtare.

Edhe punonjësi më i mirë i ri, me përvojë të lartë, nuk ka këndvështrimin e duhur për të bërë kompromise afatgjata menjëherë. Për të shfrytëzuar Codex dhe për të siguruar që puna e tij të ishte e fortë dhe e mirëmbajtshme, ishte thelbësore që ne të mbikëqyrnim vetë dizajnin e sistemeve të aplikacionit dhe kompromiset kryesore. Këto përfshinin formësimin e arkitekturës së aplikacionit, modularizimin, injektimin e varësive dhe navigimin; gjithashtu implementuam autentifikimin dhe rrjedhat bazë të rrjetëzimit. 

Nga kjo bazë, ne shkruam disa veçori përfaqësuese të plota. Ne përdorëm rregullat që donim që i gjithë kodi të ndiqte dhe dokumentuam modelet e projektit ndërsa vazhdonim. Duke drejtuar Codex drejt veçorive përfaqësuese, ai arriti të punonte më në mënyrë të pavarur brenda standardeve tona. Për një projekt që vlerësojmë se ishte 85% i shkruar nga Codex, një bazë e planifikuar me kujdes shmangu kthimet e kushtueshme dhe rifaktorizimin. Ishte një nga vendimet më të rëndësishme që kemi marrë. 

Ideja nuk ishte të bënim “diçka që funksionon” sa më shpejt të jetë e mundur, por të bënim “diçka që kupton se si duam që gjërat të funksionojnë.” Ka shumë “mënyra të sakta” për të shkruar kod. Nuk kishim nevojë t'i tregonim Codex-it saktësisht çfarë të bënte; kishim nevojë t'i tregonim Codex-it çfarë është “e saktë” në ekipin tonë. Pasi kishim vendosur pikën tonë të fillimit dhe mënyrën se si na pëlqente të ndërtonim, Codex ishte gati të fillonte.

Për të parë se çfarë do të ndodhte, ne provuam të kërkonim: “Ndërto aplikacionin Sora për Android bazuar në kodin iOS. Shko,” por e ndërpreu shpejt atë rrugë. Ndërsa ajo që krijoi Codex teknikisht funksionoi, përvoja e produktit ishte nën standard. Dhe pa një kuptim të qartë të pajisjeve fundore, të dhënave dhe rrjedhave të përdoruesve, kodi me një goditje i Codex ishte i pasigurt (Edhe pa përdorur një agjent, është e rrezikshme të shkrihen mijëra rreshta kodi.) 

Ne hipotezuam se Codex do të lulëzonte në një sandbox me shembuj të shkruar mirë; dhe kishim të drejtë. T'i kërkosh Codex-it të "ndërtojë këtë ekran cilësimesh" me pothuajse asnjë kontekst ishte e pasigurt. T'i kërkosh Codex-it të “ndërtojë këtë ekran të cilësimeve duke përdorur të njëjtën arkitekturë dhe modele si ky ekran tjetër që sapo pe” funksionoi shumë më mirë. Njerëzit morën vendimet strukturore dhe vendosën invariantet; Codex më pas plotësoi sasi të mëdha kodi brenda asaj strukture.

Hapi ynë tjetër në maksimizimin e potencialit të Codex ishte të kuptonim se si ta bënim Codex-in të funksiononte për periudha të gjata kohore (kohët e fundit, më shumë se 24 orë⁠), pa mbikëqyrje.

Në fillim të përdorimit të Codex, ne kaluam te kërkesa të tilla si, "Këtu është veçoria." Këtu janë disa skedarë. Të lutem ndërtoje. Kjo ndonjëherë funksiononte, por kryesisht prodhonte kod që teknikisht përpilohej, ndërkohë që largohej nga arkitektura dhe qëllimet tona.

Kështu që ne ndryshuam rrjedhën e punës. Për çdo ndryshim jo të parëndësishëm, së pari i kërkuam Codex-it të na ndihmojë të kuptojmë se si funksionojnë sistemi dhe kodi. Për shembull, do t'i kërkonim të lexonte një grup skedarësh të lidhur dhe të përmbledhte se si funksionon ajo veçori; për shembull, si rrjedhin të dhënat nga API përmes shtresës së depozitës, modelit të pamjes dhe në UI. Pastaj do të korrigjonim ose rafinonim kuptimin e tij. (Për shembull, do të theksonim se një abstraksion i caktuar me të vërtetë i përket një shtrese tjetër ose se një klasë e caktuar ekziston vetëm për modalitetin offline dhe nuk duhet të zgjerohet.)

Në mënyrë të ngjashme me mënyrën se si mund të angazhosh një anëtar të ri, shumë të aftë të ekipit, ne punuam me Codex për të krijuar një plan të fortë zbatimi. Ky plan shpesh dukej si një dokument i vogël dizajni që tregonte se cilët skedarë duhej të ndryshonin, çfarë gjendjesh të reja duhej të prezantoheshin dhe si duhej të rridhte logjika. Vetëm atëherë i kërkuam Codex të fillonte të zbatonte planin, hap pas hapi. Një këshillë e dobishme: për detyra shumë të gjata, ku arrijmë kufirin e dritares së kontekstit tonë, do t'i kërkojmë Codex të ruajë planin e tij në një skedar, duke na lejuar të aplikojmë të njëjtin drejtim nëpër instanca.

Ky cikël shtesë i planifikimit doli të ishte i vlefshëm për kohën. Na lejoi të lëmë Codex të funksionojë "pa mbikëqyrje" për periudha të gjata, sepse i dinim planet e tij. E bëri rishikimin e kodit më të lehtë, sepse mund të kontrollonim zbatimin kundrejt planit tonë në vend që të lexonim një ndryshim pa kontekst. Dhe kur diçka shkonte keq, mund të spastronim planin së pari dhe kodin së dyti. 

Dinamika ndihej e ngjashme me mënyrën se si një dokument i mirë dizajni i jep një udhëheqës teknologjie besim për një projekt. Ne nuk po përftonim vetëm kod: ne po prodhonim kod që mbështeste një plan të përbashkët.

Në kulmin e projektit, shpesh po drejtonim disa sesione Codex njëkohësisht. Njëri po punonte në riprodhim, një tjetër në kërkim, një tjetër në trajtimin e gabimeve dhe ndonjëherë një tjetër në teste ose ristrukturime. Dukej më pak si përdorimi i një mjeti dhe më shumë si menaxhimi i një Team.

Çdo sesion do të raportonte prapa periodikisht përparimin tek ne. Dikush mund të thotë, "E kam mbaruar planifikimin e këtij moduli; ja çfarë propozoj," ndërsa një tjetër do të ofronte një ndryshim të madh për një veçori të re. Secila kërkonte vëmendje, përshtypje dhe shqyrtim. Ishte çuditërisht e ngjashme me të qenit një drejtues teknik me disa inxhinierë të rinj, të gjithë duke bërë përparim, të gjithë duke pasur nevojë për udhëzime.

Rezultati ishte një rrjedhë bashkëpunuese. Aftësia e papërpunuar e kodimit e Codex na çliroi nga shumë shtypje manuale. Kishim më shumë kohë për të menduar rreth arkitekturës, për të lexuar me kujdes kërkesat e tërheqjes dhe për të testuar aplikacionin. 

Në të njëjtën kohë, ajo shpejtësi shtesë nënkuptonte që gjithmonë kishim diçka në radhën tonë të rishikimit. Codex nuk u bllokua nga ndërrimi i kontekstit, por ne u bllokuam. Ngushtica jonë në zhvillim u zhvendos nga shkrimi i kodit te marrja e vendimeve, dhënia e përshtypjeve dhe integrimi i ndryshimeve.

Këtu është vendi ku njohuritë e Brooks shfaqen në një mënyrë të re. Nuk mund të shtosh thjesht sesione Codex dhe të presësh përshpejtim linear, ashtu siç nuk mund të vazhdosh të shtosh inxhinierë në një projekt dhe të presësh që orari të shkurtohet në mënyrë lineare. Çdo "palë duar" shtesë, madje edhe virtuale, shton ngarkesën e koordinimit. Ne ishim bërë dirigjentë të një orkestre në vend që të ishim thjesht muzikantë solo më të shpejtë.

Ne e nisëm projektin tonë me një hap të madh përpara: Sora tashmë ishte lançuar në iOS. Ne shpesh e drejtonim Codex drejt bazave të kodit të iOS dhe backend për ta ndihmuar të kuptonte kërkesat dhe kufizimet kryesore. Gjatë gjithë projektit, bënim shaka se kishim rishpikur idenë e një kuadri ndër-platformë. Harro React Native ose Flutter; e ardhmja e ndër-platformës është vetëm Codex.

Përtej shakasë, janë dy parime:.

1. Logjika është e lëvizshme. Pavarësisht nëse kodi është shkruar në Swift apo Kotlin, logjika themelore e aplikacionit – modelet e të dhënave, thirrjet e rrjetit, rregullat e vlefshmërisë, logjika e biznesit– janë të njëjta. Codex është shumë i mirë në leximin e një implementimi Swift dhe krijimin e një ekuivalenti në Kotlin që ruan kuptimin.
2. Shembuj konkretë ofrojnë një kontekst të fuqishëm. Një sesion i ri Codex që mund të shohë "ja saktësisht si funksionon kjo në iOS" dhe "ja arkitektura Android" është shumë më efektiv sesa një që punon vetëm nga përshkrimet në gjuhë natyrore.

Duke vënë në zbatim këto parime, ne bëmë që repos për iOS, backend dhe Android të jenë të disponueshme në të njëjtin mjedis. Ne i dhamë Codex-it kërkesa si:

“Lexo këto modele dhe pajisje fundore në kodin iOS dhe pastaj propozo një plan për të zbatuar sjelljen ekuivalente në Android duke përdorur klientin tonë ekzistues të API dhe klasat e modelit.”

Një truk i vogël por i dobishëm ishte të detajohej në ~/.codex/AGENTS.md se ku ndodheshin depot lokale dhe çfarë përmbanin ato. Kjo e bëri më të lehtë për Codex të zbulojë dhe të navigojë në kodin përkatës.

Ne po zhvillonim në mënyrë efektive ndër-platforma përmes përkthimit në vend të abstraksionit të përbashkët. Për shkak se Codex trajtoi shumicën e përkthimit, ne shmangëm dyfishimin e kostove të zbatimit.

Mësimi më i gjerë është se për Codex, konteksti është gjithçka. Codex bëri punën e vet më të mirë kur kuptoi se si funksiononte tashmë veçoria në iOS, e kombinuar me një kuptim të strukturës së aplikacionit tonë Android. Kur Codex-it i mungonte ai kontekst, nuk ishte se "refuzonte të bashkëpunonte"; ishte duke hamendësuar. Sa më shumë që e trajtuam si një anëtar të ri të ekipit dhe investuam në dhënien e hyrjeve të duhura, aq më mirë performoi.

Në fund të sprintit tonë katër-javor, përdorimi i Codex-it ndaloi së qeni një eksperiment dhe u bë rrjedha jonë e parazgjedhur e zhvillimit. E përdorëm për të kuptuar kodin ekzistues, për të planifikuar ndryshimet dhe për të zbatuar veçoritë. Ne e rishikuam prodhimin e tij në të njëjtën mënyrë siç do të rishikonim atë të një shoku skuadre. Ishte thjesht mënyra se si e dërgonim softuerin.

U kuptua qartë se zhvillimi i asistuar nga IA-ja nuk e zvogëlon nevojën për rigorozitet; përkundrazi, e rrit atë. Sado i aftë që është Codex, objektivi i tij është të shkojë nga A në B, tani. Kjo është arsyeja pse kodimi i asistuar nga IA-ja nuk funksionon pa njerëz. Inxhinierët e softuerit mund të kuptojnë dhe të zbatojnë kufizimet reale të sistemeve, mënyrat më të mira për të arkitektuar softuerin dhe si të ndërtojnë duke pasur parasysh zhvillimet e ardhshme dhe planet e produktit. Superfuqitë e inxhinierit të softuerit të së nesërmes do të jenë kuptimi i thellë i sistemeve dhe aftësia për të punuar në mënyrë bashkëpunuese me IA për periudha të gjata kohore. 

Pjesët më interesante të inxhinierisë softuerike janë ndërtimi i produkteve tërheqëse, projektimi i sistemeve të shkallëzueshme, shkrimi i algoritmeve komplekse dhe eksperimentimi me të dhëna, modele dhe kod. Megjithatë, realitetet e inxhinierisë softuerike të së kaluarës dhe të tashmes shpesh janë më të zakonshme: qendërzimi i butonave, lidhja e pajisjeve fundore dhe shkrimi i kodit të përsëritur. Tani, Codex e bën të mundur të përqendrohemi në pjesët më domethënëse të inxhinierisë softuerike dhe arsyet pse e duam zanatin tonë.

Pasi Codex është vendosur në një mjedis të pasur me kontekst ku kupton qëllimet tuaja dhe mënyrën se si ju pëlqen të ndërtoni, çdo ekip mund të shumëfishojë aftësitë e tij. Retroja jonë e lançimit nuk është një recetë që i përshtatet të gjithëve, dhe nuk po pretendojmë se kemi zgjidhur zhvillimin e asistuar nga IA-ja. Por shpresojmë që përvoja jonë e bën më të lehtë gjetjen e mënyrave më të mira për të fuqizuar Codex-in që të të fuqizojë ty. 

Kur Codex u lançua në një pamje paraprake kërkimore shtatë muaj më parë, inxhinieria softuerike dukej shumë ndryshe. Përmes Sora, ne patëm mundësinë të eksplorojmë kapitullin para të inxhinierisë. Ndërsa modelet dhe sistemet tona përmirësohen, IA-ja do të bëhet një pjesë gjithnjë e më e domosdoshme e ndërtimit. 

Çfarë do të krijosh me ekipin tënd të Codex?