Cum am folosit Codex pentru a lansa Sora pentru Android în 28 de zile

Din 26 aprilie 2026, produsul Sora nu mai este disponibil.

În noiembrie, am lansat aplicația Sora pentru Android, oferind oricui are un dispozitiv Android posibilitatea de a transforma o scurtă solicitare într-un videoclip plin de viață. În ziua lansării, aplicația a ajuns pe locul 1 în Magazin Play. Utilizatorii Android au generat peste un milion de videoclipuri în primele 24 de ore.

În spatele lansării se află o poveste: versiunea inițială a aplicației Android de producție a Sora a fost construită în 28 de zile, datorită aceluiași agent disponibil oricărei echipe sau dezvoltator: Codex.

Între 8 octombrie și 5 noiembrie 2025, o echipă eficientă de ingineri, care a lucrat alături de Codex și a utilizat aproximativ 5 miliarde de tokenuri, a gestionat Sora pentru Android de la prototip până la lansarea globală. În ciuda dimensiunii sale, aplicația are o rată fără erori de 99,9% și o arhitectură de care suntem mândri. Dacă te întrebi dacă am folosit un model secret, am folosit o versiune timpurie a modelului GPT‑5.1‑Codex – aceeași versiune pe care orice dezvoltator sau business o poate folosi astăzi prin CLI, extensia IDE sau aplicația web.

Când Sora a fost lansat pe iOS, utilizarea a explodat. Oamenii au început imediat să genereze un flux de videoclipuri. Pe Android, în schimb, aveam doar un mic prototip intern și un număr tot mai mare de utilizatori preînregistrați pe Google Play.

O reacție obișnuită la o lansare cu miză mare și la presiunea timpului este să se adune resurse și să se adauge procese. O aplicație de producție de această amploare și calitate ar implica de obicei mulți ingineri care lucrează luni întregi, încetiniți de coordonare. 

Arhitectul american de calculatoare Fred Brooks a avertizat că „adăugarea mai multor persoane la un proiect software întârziat îl face să fie întârziat”. Cu alte cuvinte, atunci când se încearcă livrarea rapidă a unui proiect complex, adăugarea mai multor ingineri poate adesea încetini eficiența prin creșterea nevoii de comunicare, fragmentarea sarcinilor și costurile de integrare. Ne-am bazat pe această perspectivă în loc să o ignorăm; am format o echipă puternică de patru ingineri – toți echipați cu Codex pentru a crește drastic impactul fiecărui inginer. 

Lucrând în acest mod, am livrat o versiune internă a Sora pentru Android angajaților în 18 zile și am lansat-o public 10 zile mai târziu. Am menținut un standard ridicat în practicile de inginerie Android, am investit în mentenabilitate și am menținut aplicația la același standard de fiabilitate pe care l-am aștepta de la un proiect mai tradițional. (De asemenea, continuăm să folosim Codex pe scară largă astăzi pentru a evolua și a aduce noi funcții aplicației).

Pentru a înțelege cum am lucrat cu Codex, e util să știi unde excelează și unde are nevoie de îndrumare. A-l trata ca pe un inginer senior proaspăt angajat a fost o abordare bună. Capacitatea Codex a însemnat că am putut petrece mai mult timp direcționând și revizuind codul decât scriindu-l singuri.

Unde are Codex nevoie de îndrumare

1. Codex nu este încă foarte priceput la a deduce ceea ce nu i s-a spus (de exemplu, modelele arhitecturale preferate, strategia de produs, comportamentul real al utilizatorului și normele sau scurtăturile interne).
2. În mod similar, Codex nu putea vedea cum rula aplicația: nu putea deschide Sora pe un dispozitiv, nu putea observa că o derulare părea ciudată sau nu putea sesiza că un flux era confuz. Doar echipa noastră putea acoperi aceste sarcini experiențiale.
3. Fiecare instanță necesită integrare. Partajarea contextului cu obiective clare, constrângeri și îndrumări despre „cum facem lucrurile” a fost esențială pentru ca Codex să funcționeze bine.
4. În același sens, Codex s-a confruntat cu dificultăți în ceea ce privește judecata arhitecturală profundă: lăsat de sine stătător, ar putea introduce un model de vizualizare suplimentar acolo unde am dori cu adevărat să extindem unul existent sau să împingem logica în stratul UI care aparținea în mod clar unui depozit. Instinctul său este să pună ceva în mișcare, nu să acorde prioritate curățeniei pe termen lung.

Am considerat util ca Codex să creeze și să întrețină o cantitate generoasă de fișiere AGENT.md în întreaga bază de cod. Acest lucru a facilitat aplicarea acelorași îndrumări și bune practici în cadrul sesiunilor. De exemplu, pentru a ne asigura că Codex a scris codul conform ghidurilor noastre de stil, am adăugat următoarele la fișierul nostru principal AGENTS.md:

Unde Codex excelează

1. Citirea și înțelegerea rapidă a bazelor de cod mari: Codex cunoaște practic toate limbajele de programare majore, ceea ce facilitează utilizarea acelorași concepte pe mai multe platforme, fără abstracții complexe.
2. Acoperire de testare: Codex este (extrem de) entuziast în scrierea de teste unitare pentru a acoperi o gamă largă de cazuri. Nu toate testele au fost aprofundate, dar amploarea acoperirii a fost utilă în prevenirea regresiilor. 
3. Aplicarea feedbackului: în mod similar, Codex este bun la reacționarea la feedback. Când CI eșua, puteam lipi rezultatul jurnalului într-o solicitare și să cerem Codex-ului să propună soluții.
4. Execuție masiv paralelă, de unică folosință: majoritatea nu vor depăși limitele numărului de sesiuni pe care le-ar putea rula simultan. Este foarte fezabil să testezi mai multe idei în paralel și să consideri codul ca fiind de unică folosință.
5. Oferirea unei noi perspective: în discuțiile despre design, am folosit Codex ca instrument generativ pentru a explora potențialele puncte de defecțiune și a descoperi noi modalități de a rezolva o problemă. De exemplu, în timp ce noi proiectam optimizări pentru memoria playerelor video, Codex a analizat mai multe SDK-uri pentru a propune abordări pe care nu am fi avut timp să le analizăm. Informațiile obținute în urma cercetării Codex s-au dovedit neprețuite în minimizarea amprentei de memorie în aplicația finală.
6. Permiterea unei munci cu impact mai mare: în practică, am ajuns să petrecem mai mult timp revizuind și coordonând codul decât scriindu-l singuri. Acestea fiind spuse, Codex se descurcă foarte bine și la revizuirea codului, identificând adesea erorile înainte de a fi îmbinate, îmbunătățind fiabilitatea.

Odată ce am recunoscut aceste caracteristici, modelul nostru de lucru a devenit mai simplu. Ne-am bazat pe Codex pentru a realiza o mare parte din munca grea în cadrul unor modele bine înțelese și a unor domenii de aplicare bine delimitate, în timp ce echipa noastră s-a concentrat pe arhitectură, experiența utilizatorului, schimbările sistemice și calitatea finală.

Chiar și cel mai bun angajat nou, senior, nu are punctul de vedere potrivit pentru a face imediat compromisuri pe termen lung. Pentru a valorifica Codex și a ne asigura că funcționarea sa este robustă și ușor de întreținut, a fost esențial să supraveghem noi înșine designul sistemelor aplicației și compromisurile cheie. Acestea au inclus conturarea arhitecturii aplicației, modularizarea, injectarea de dependențe și navigarea; de asemenea, am implementat autentificarea și fluxurile de rețea de bază. 

Pornind de la această bază, am scris câteva funcții reprezentative de la început până la sfârșit. Am folosit regulile pe care doream să le urmeze întreaga bază de cod și am documentat modelele la nivelul întregului proiect pe parcurs. Prin direcționarea Codex către funcții reprezentative, acesta a putut funcționa mai independent în cadrul standardelor noastre. Pentru un proiect despre care estimăm că a fost scris în proporție de 85% de Codex, o fundație atent planificată a evitat reveniri și refactorizări costisitoare. A fost una dintre cele mai importante decizii pe care le-am luat. 

Ideea nu era să facem „ceva care să funcționeze” cât mai repede posibil, ci mai degrabă să facem „ceva care să facă lucrurile să funcționeze așa cum vrem noi”. Există multe moduri „corecte” de a scrie cod. Nu trebuia să-i spunem lui Codex exact ce să facă; trebuia să-i arătăm lui Codex ce este „corect” în echipa noastră. Odată ce am stabilit punctul de plecare și modul în care ne plăcea să construim, Codex era gata de start.

Pentru a vedea ce s-ar întâmpla, am încercat să cerem: „Construiește aplicația Sora pentru Android pe baza codului iOS. Hai”, dar a renunțat rapid la acea cale. Deși ceea ce a creat Codex a funcționat din punct de vedere tehnic, experiența cu produsul a fost sub așteptări. Și fără o înțelegere clară a endpointurilor, datelor și fluxurilor de utilizatori, codul single-shot al Codex era nesigur (chiar și fără a utiliza un agent, este riscant să îmbini mii de linii de cod.) 

Am emis ipoteza că Codex ar prospera într-o cutie plină de exemple bine scrise și am avut dreptate. A cere lui Codex să „construiască acest ecran de setări” cu aproape niciun context a fost nesigur. A funcționat mult mai bine dacă i-am cerut lui Codex să „construiască acest ecran de setări folosind aceeași arhitectură și modele ca și celălalt ecran pe care tocmai l-ai văzut”. Oamenii au luat deciziile structurale și au stabilit invarianții; Codex a completat apoi cantități mari de cod în interiorul acelei structuri.

Următorul nostru pas în maximizarea potențialului Codex a fost să descoperim o modalitate de a permite Codex să funcționeze perioade lungi (recent, mai mult de 24 de ore⁠), nesupravegheat.

La începutul utilizării Codex, am sărit la solicitări precum „Iată caracteristica. Iată câteva fișiere. Te rog să construiești-l.” Aceasta uneori funcționa, dar în mare parte producea cod care se compila tehnic, în timp ce se abătea de la arhitectura și obiectivele noastre.

Așadar, am schimbat fluxul de lucru. Pentru orice modificare semnificativă, am cerut mai întâi ajutorul Codex pentru a înțelege cum funcționează sistemul și codul. De exemplu, i-am cere să citească un set de fișiere corelate și să rezume cum funcționează acea funcție; de exemplu, cum circulă datele de la API prin stratul depozitului, modelul de vizualizare și în interfața cu utilizatorul. Apoi am corecta sau rafina înțelegerea lui. (De exemplu, am sublinia că o anumită abstracție aparține de fapt unui alt strat sau că o anumită clasă există doar pentru modul offline și nu ar trebui extinsă.)

Similar cu modul în care ai putea să te implici cu un nou coleg de echipă foarte capabil, am colaborat cu Codex pentru a crea un plan de implementare solid. Acel plan arăta adesea ca un document de proiectare în miniatură care indica ce fișiere ar trebui modificate, ce stări noi ar trebui introduse și cum ar trebui să curgă logica. Abia atunci am cerut lui Codex să înceapă aplicarea planului, pas cu pas. Un sfat util: pentru sarcini foarte lungi, unde atingem limita ferestrei noastre de context, i-am cere lui Codex să salveze planul într-un fișier, permițându-ne să aplicăm aceeași direcție în toate instanțele.

Această buclă suplimentară de planificare s-a dovedit a merita timpul investit. Ne-a permis să lăsăm Codex să ruleze „nesupravegheat” pentru perioade lungi, deoarece îi cunoșteam planurile. A ușurat revizuirea codului, deoarece am putut verifica implementarea în raport cu planul nostru, în loc să citim o diferență fără context. Și când ceva nu mergea bine, puteam depana mai întâi planul și apoi codul. 

Dinamica s-a simțit similară cu modul în care un document de design bun îi oferă unui tech lead încredere într-un proiect. Nu generam doar cod: produceam cod care susținea o foaie de parcurs comună.

La apogeul proiectului, rulam frecvent mai multe sesiuni Codex în paralel. Unul lucra la redare, altul la căutare, altul la tratarea erorilor și uneori altul la teste sau refactorizări. Se simțea mai puțin ca o folosire a unui instrument și mai mult ca o gestionare a unei echipe.

Fiecare sesiune ne-ar raporta periodic progresul. Cineva ar putea spune: „Am terminat de planificat acest modul; iată ce propun”, în timp ce altul ar oferi o diferență mare pentru o nouă funcționalitate. Fiecare a necesitat atenție, feedback și analiză. Era ciudat de similar cu a fi tech lead alături de mai mulți ingineri noi, toți făcând progrese, toți având nevoie de îndrumare.

Rezultatul a fost un flux colaborativ. Capacitatea de codare brută a Codex ne-a eliberat de o mare parte din tastarea manuală. Am avut mai mult timp să ne gândim la arhitectură, să citim cu atenție cererile de extragere a datelor și să testăm aplicația. 

În același timp, acea viteză suplimentară însemna că aveam mereu ceva care ne aștepta în coada de revizuire. Codex nu a fost blocat de schimbarea contextului, dar noi am fost. Blocajul nostru în dezvoltare s-a mutat de la scrierea codului la luarea deciziilor, oferirea de feedback și integrarea modificărilor.

Aici intervin perspectivele lui Brooks într-un mod nou. Nu poți pur și simplu să adaugi sesiuni Codex și să te aștepți la creșteri liniare ale vitezei, la fel cum nu poți continua să adaugi ingineri la un proiect și să te aștepți ca programul să se reducă liniar. Fiecare „pereche de mâini” suplimentară, chiar și virtuală, adaugă un plus de coordonare. Devenisem dirijorii unei orchestre, în loc de niște soliști mai rapizi.

Am început proiectul nostru cu un pas important: Sora fusese deja lansat pe iOS. Am îndrumat frecvent Codex către bazele de cod iOS și de backend pentru a-l ajuta să înțeleagă cerințele și constrângerile cheie. Pe parcursul proiectului, am glumit că am reinventat ideea unui framework multiplatformă. Uită de React Native sau Flutter; viitorul cross-platform este pur și simplu Codex.

Dincolo de glumă se află două principii:.

1. Logica este portabilă. Indiferent dacă codul este scris în Swift sau Kotlin, logica aplicației subiacente – modele de date, apeluri la rețea, reguli de validare, logică de business – rămân aceleași. Codex este foarte bun la citirea unei implementări Swift și la crearea unui echivalent în Kotlin care păstrează semantica.
2. Exemplele concrete oferă un context puternic. O sesiune Codex nouă, care poate vedea „iată exact cum funcționează asta pe iOS” și „iată arhitectura Android”, este mult mai eficientă decât una care funcționează doar pe baza descrierilor în limbaj natural.

Punând în aplicare aceste principii, am făcut ca depozitele iOS, backend și Android să fie disponibile în același mediu. Am dat solicitări Codex, cum ar fi:

„Citește aceste modele și puncte finale în codul iOS și apoi propune un plan pentru a implementa comportamentul echivalent pe Android folosind clientul nostru API existent și clasele de model.”

Un truc mic, dar util, a fost detalierea în ~/.codex/AGENTS.md a locurilor în care se aflau depozitele locale și a conținutului acestora. Asta a făcut mai ușor pentru Codex să descopere și să navigheze prin codul relevant.

Practic, făceam dezvoltare multi-platformă prin traducere, în loc de abstractizare partajată. Deoarece Codex s-a ocupat de cea mai mare parte a traducerii, am evitat dublarea costurilor de implementare.

Lecția mai amplă este că, pentru Codex, contextul este esențial. Codex a făcut cea mai bună treabă atunci când a înțeles cum funcționa deja funcția în iOS, împreună cu o înțelegere a modului în care era structurată aplicația noastră Android. Când Codex nu avea acel context, nu „refuza să coopereze”; ci ghicea. Cu cât l-am tratat mai mult ca pe un nou coleg de echipă și am investit în a-i oferi datele de intrare corecte, cu atât a avut performanțe mai bune.

Până la sfârșitul sprintului nostru de patru săptămâni, utilizarea Codex a încetat să mai pară un experiment și a devenit ciclul nostru implicit de dezvoltare. L-am folosit pentru a înțelege codul existent, a planifica modificări și a implementa funcții. Am analizat rezultatele sale în același mod în care am analiza rezultatele unui coechipier. Era pur și simplu felul în care livram software.

A devenit clar că dezvoltarea asistată de AI nu reduce nevoia de rigoare, ci o sporește. Oricât de capabil ar fi Codex, obiectivul său este să ajungă de la A la B, acum. Acesta este motivul pentru care programarea asistată de AI nu funcționează fără oameni. Inginerii software pot înțelege și aplica constrângerile reale ale sistemelor, cele mai bune modalități de a proiecta software-ul și cum să construiască având în vedere planurile viitoare de dezvoltare și de produs. Superputerile inginerului software de mâine vor fi înțelegerea profundă a sistemelor și capacitatea de a colabora cu AI pe perioade lungi de timp. 

Cele mai interesante părți ale ingineriei software sunt construirea de produse captivante, proiectarea de sisteme scalabile, scrierea de algoritmi complecși și experimentarea cu date, modele și cod. Cu toate acestea, realitățile ingineriei software din trecut și prezent sunt adesea mai banale: centrarea butoanelor, conectarea punctelor finale și scrierea de cod șablon. Acum, Codex face posibilă concentrarea asupra celor mai importante părți ale ingineriei software și a motivelor pentru care ne iubim meseria.

Odată ce Codex este configurat într-un mediu bogat în context, unde înțelege obiectivele tale și modul în care îți place să construiești, orice echipă își poate multiplica capacitățile. Retrospectiva noastră de lansare nu este o rețetă universală și nu pretindem că am rezolvat problema dezvoltării asistate de AI. Dar sperăm că experiența noastră va ajuta la găsirea celor mai bune modalități de a-i oferi lui Codex putere și de a-ți oferi putere. 

Când Codex a fost lansat într-o previzualizare a cercetării acum șapte luni, ingineria software arăta foarte diferit. Prin intermediul Sora, am putut explora următorul capitol al ingineriei. Pe măsură ce modelele și sistemele noastre continuă să se îmbunătățească, AI va deveni o parte din ce în ce mai indispensabilă a construcției. 

Ce vei realiza cu propria ta echipă de Codex?