Hvernig við notuðum Codex til að byggja Sora fyrir Android á 28 dögum

Frá og með 26. apríl 2026 verður Sora ekki lengur í boði.

Í nóvember kynntum við Sora Android-appið fyrir heiminum, sem gefur öllum með Android-tæki tækifæri til að breyta stuttri kvaðningu í líflegt myndband. Á útgáfudegi náði appið fyrsta sæti í Play Store. Android-notendur bjuggu til meira en milljón myndbönd á fyrstu 24 klukkustundunum.

Á bak við útgáfuna er saga: upphafsútgáfa af Android-appi Sora var byggð á 28 dögum, þökk sé sama fulltrúa sem er í boði fyrir hvaða teymi eða forritara sem er: Codex.

Frá 8. október til 5. nóvember 2025 vann lítið teymi ásamt Codex og notaði um það bil 5 milljarða tákna til að koma Sora fyrir Android frá frumgerð til alþjóðlegrar útgáfu. Þrátt fyrir umfang sitt hefur appið hrunlaust hlutfall upp á 99,9 prósent og högun sem við erum stolt af. Ef þú ert að velta fyrir þér hvort við notuðum leynilegt líkan, þá notuðum við snemmbúna útgáfu af GPT‑5.1‑Codex líkaninu – sama útgáfa sem hver forritari eða fyrirtæki getur notað í dag í gegnum CLI, IDE-viðbót eða vefapp.

Þegar Sora var sett á markað á iOS var notkunin gríðarmikil. Fólk hóf strax að búa til straum af myndböndum. Á Android, aftur á móti, höfðum við aðeins litla innri frumgerð og vaxandi fjölda fyrirfram skráðra notenda á Google Play.

Algeng viðbrögð við háspennu og tímaskorti við upphaf eru að bæta við auðlindum og auka ferli. Framleiðsluapp af þessari stærðargráðu og gæðum myndi venjulega krefjast margra verkfræðinga sem vinna í marga mánuði, en samhæfing hægir á þeim. 

Bandaríski tölvuarkitektinn Fred Brooks varaði, eins og frægt er orðið, við því að „með því að bæta fleiri við síðbúið hugbúnaðarverkefni gerir það verkefnið enn seinna.“ Með öðrum orðum, þegar reynt er að skila flóknu verkefni hratt, getur það að bæta við fleiri verkfræðingum oft dregið úr skilvirkni með því að auka samskiptaálag, verkefnaskiptingu og samþættingarkostnað. Við nýttum okkur þessa innsýn í stað þess að hunsa hana; við settum saman sterkt teymi fjögurra verkfræðinga – allir búnir Codex til að auka verulega áhrif hvers verkfræðings. 

Með því að vinna á þennan hátt sendum við innri smíð af Sora fyrir Android til starfsmanna á 18 dögum og hófum opinbera útgáfu 10 dögum síðar. Við héldum háum stöðlum fyrir verkfræðiaðferðir á Android, fjárfestum í viðhaldsgetu og héldum appinu við sömu áreiðanleikastaðla og við myndum búast við frá hefðbundnara verkefni. (Við notum Codex enn mikið í dag til að þróa og bæta nýjum eiginleikum við appið).

Til að átta sig á hvernig við unnum með Codex, er gagnlegt að vita hvar það skarar fram úr og hvar það þarf leiðsögn. Að meðhöndla það eins og nýráðinn háttsettan verkfræðing var góð nálgun. Hæfileiki Codex þýddi að við gátum varið meiri tíma í að stýra og yfirfara kóða en að skrifa hann sjálf.

Hvar Codex þarf leiðsögn

1. Codex er enn ekki frábær í að álykta það sem því hefur ekki verið sagt (t.d. þín uppáhalds högunarmynstur, vörustefna, raunveruleg hegðun notenda og innri venjur eða flýtileiðir).
2. Á sama hátt gat Codex ekki séð appið í raun keyra: Það gat ekki opnað Sora á tæki, tekið eftir að fletting virtist vera óeðlileg, eða skynjað að flæði væri ruglingslegt. Aðeins teymið okkar gat sinnt þessum reynsluverkefnum.
3. Hvert tilvik krefst kynningar. Að deila samhengi með skýrum markmiðum, takmörkunum og leiðbeiningum um „hvernig við gerum hlutina“ var nauðsynlegt til að Codex framkvæmdi hlutina vel.
4. Á sama hátt átti Codex í erfiðleikum með djúpa byggingarlega dómgreind: Ef það væri látið í friði gæti það kynnt nýtt líkan þar sem við vildum í raun framlengja núverandi eða ýta rökfræði inn í notendaviðmótslagið sem augljóslega átti heima í geymslu. Eðlishvöt þess er að fá eitthvað til að virka, ekki að forgangsraða langtíma hreinskilni.

Okkur fannst gagnlegt að láta Codex búa til og viðhalda ríkulegu magni af AGENT.md skrám um allan kóðagrunninn. Þetta gerði það auðvelt að beita sömu leiðbeiningum og bestu starfsvenjum yfir lotum. Til dæmis, til að tryggja að Codex skrifaði kóða í samræmi við stílleiðbeiningar okkar, bættum við eftirfarandi við AGENTS.md á efsta stigi:

Þar sem Codex skarar fram úr

1. Að lesa og skilja stór kóðasöfn hratt: Codex þekkir í raun öll helstu forritunarmál, sem auðveldar að nýta sömu hugtök á mörgum kerfum án flókinna óhlutstæðra hugtaka.
2. Prófunarumfang: Codex er (einstaklega) áhugasamt um að skrifa einingapróf til að ná yfir fjölbreytt úrval af tilfellum. Ekki voru öll próf djúp, en að hafa breitt umfang var gagnlegt til að koma í veg fyrir afturför. 
3. Að taka við ábendingu: Á svipaðan hátt er Codex gott í að bregðast við ábendingu. Þegar CI mistókst, gátum við límt skráningarfrálag inn í kvaðningu og beðið Codex um að leggja til lagfæringar.
4. Gríðarmikil samhliða, einnota keyrsla: Flestir munu ekki ýta á mörk fjölda lota sem þeir gætu raunverulega keyrt á hverjum tíma. Það er mjög raunhæft að prófa margar hugmyndir samtímis og líta á kóða sem einnota.
5. Að bjóða upp á nýja sýn: Í hönnunarumræðum notuðum við Codex sem skapandi verkfæri til að kanna mögulega veikleika og finna nýjar leiðir til að leysa vandamál. Til dæmis, á meðan við hönnuðum minnishagræðingu fyrir myndspilara, fór Codex í gegnum mörg SDK til að leggja til aðferðir sem við hefðum ekki haft tíma til að skoða. Innsýn úr rannsóknum Codex reyndist ómetanleg við að minnka minnisálag í lokaútgáfu appsins.
6. Að gera kleift að vinna að verkefnum með meiri áhrif: Í reynd eyddum við meiri tíma í að yfirfara og stýra kóða en að skrifa hann sjálf. Þar að auki er Codex mjög gott í kóðayfirferð, oft að finna villur áður en þær eru sameinaðar, sem eykur áreiðanleika.

Þegar við viðurkenndum þessa eiginleika varð vinnulíkanið okkar einfaldara. Við treystum á Codex til að sinna miklu magni af erfiðum verkefnum innan vel skilgreinds mynsturs og vel afmarkaðra sviða, á meðan teymið okkar einbeitti sér að högun, notendaupplifun, kerfisbreytingum og endanlegum gæðum.

Jafnvel besti nýi, háttsetti starfsmaðurinn hefur ekki rétta sjónarhornið til að gera langtíma málamiðlanir strax. Til að nýta Codex og tryggja að vinna þess væri traust og viðhaldanleg, var lykilatriði að við sjálf höfðum umsjón með hönnun kerfa appsins og helstu málamiðlunum. Þetta innihélt að móta högun appsins, mátun, ósjálfstæða eininga innspýtingu og leiðsögn; við útfærðum einnig auðkenningu og grunn netkerfisflæðis. 

Frá þessum grunni skrifuðum við nokkra fulltrúa eiginleika frá upphafi til enda. Við notuðum reglurnar sem við vildum að allt kóðasafnið fylgdi og skráðum mynstur fyrir allt verkefnið á meðan við unnum. Með því að benda Codex á dæmigerða eiginleika gat það unnið sjálfstæðara innan okkar viðmiða. Fyrir verkefni sem við áætlum að Codex hafi skrifað 85% af, kom vandlega skipulögð undirstaða í veg fyrir kostnaðarsama afturför og endurgerð. Þetta var ein af mikilvægustu ákvörðunum sem við tókum. 

Hugmyndin var ekki að búa til „eitthvað sem virkar“ eins fljótt og hægt er, heldur að búa til „eitthvað sem skilur hvernig við viljum að hlutirnir virki.“ Það eru margar „réttar“ leiðir til að skrifa kóða. Við þurftum ekki að segja Codex nákvæmlega hvað átti að gera; við þurftum að sýna Codex hvað er „rétt“ í okkar teymi. Þegar við höfðum komið á fót upphafsstað okkar og hvernig við vildum byggja, var Codex tilbúið að hefjast handa.

Til að sjá hvað myndi gerast, reyndum við að gefa fyrirmæli: „Byggðu Sora Android-appið út frá iOS-kóðanum.“ Go,“ en hættum fljótt við þá leið. Þó að það sem Codex bjó til tæknilega virkaði, var vöruupplifunin ekki upp á marga fiska. Og án skýrs skilnings á endapunktum, gögnum og notendaflæði var einnar skots kóði Codex óáreiðanlegur (Jafnvel án þess að nota fulltrúa er áhættusamt að sameina þúsundir lína af kóða.) 

Við gerðum ráð fyrir að Codex myndi blómstra í sandkassa með vel skrifuðum dæmum; og við höfðum rétt fyrir okkur. Að biðja Codex um að „búa til þennan stillingaskjá“ með næstum engu samhengi var óáreiðanlegt. Að biðja Codex um að „búa til þennan stillingaskjá með sömu uppbyggingu og mynstri og þessi annar skjár sem þú sást rétt áðan“ virkaði mun betur. Menn tóku ákvarðanir um uppbyggingu og settu óbreytur; Codex fyllti síðan inn mikið magn af kóða innan þessarar uppbyggingar.

Næsta skref okkar í að hámarka möguleika Codex var að finna út hvernig á að virkja Codex til að vinna í langan tíma (nýlega, meira en 24 klukkustundir⁠), án eftirlits.

Snemma í notkun Codex fórum við beint í kvaðningar eins og, „Hér er eiginleikinn.“ Hér eru nokkur skjöl. Vinsamlegast byggðu það. Það virkaði stundum, en oftast skilaði það kóða sem tæknilega séð var hægt að setja saman, en sem fór út fyrir okkar högun og markmið.

Því breyttum við vinnuflæðinu. Fyrir allar breytingar sem eru ekki smávægilegar, báðum við fyrst Codex um að hjálpa okkur að skilja hvernig kerfið og kóðinn virka. Til dæmis myndum við biðja það um að lesa safn tengdra skráa og draga saman hvernig þessi eiginleiki virkar; til dæmis hvernig gögn flæða frá API í gegnum geymslulagið, skoðunarlíkanið og inn í notendaviðmótið. Síðan myndum við leiðrétta eða fínpússa skilning þess. (Til dæmis myndum við benda á að ákveðin abstrakt hugmynd tilheyrir í raun öðru lagi eða að tiltekinn klasi er eingöngu til fyrir ótengda stillingu og ætti ekki að vera útvíkkaður.)

Á svipaðan hátt og þú gætir tekið á móti nýjum, mjög hæfum liðsfélaga, unnum við með Codex til að búa til trausta framkvæmdaráætlun. Sú áætlun leit oft út eins og smækkað hönnunarskjal sem gaf til kynna hvaða skrár ætti að breyta, hvaða nýtt ástand ætti að kynna og hvernig rökfræði ætti að flæða. Þá báðum við Codex um að byrja að framkvæma áætlunina, eitt skref í einu. Eitt gagnlegt ráð: fyrir mjög löng verkefni, þar sem við náum hámarki samhengisgluggans okkar, myndum við biðja Codex um að vista áætlun sína í skrá, sem gerir okkur kleift að beita sömu stefnu yfir mörg tilvik.

Þessi auka skipulagslykkja reyndist vera þess virði. Það gerði okkur kleift að láta Codex keyra „án eftirlits“ í langan tíma, því við þekktum áætlanir þess. Það gerði kóðayfirferð auðveldari, því við gátum borið útfærsluna saman við áætlun okkar frekar en að lesa diff án samhengis. Og þegar eitthvað fór úrskeiðis gátum við gert villuleit á áætluninni fyrst og kóðanum síðan. 

Dýnamíkin var svipuð og þegar gott hönnunarskjal veitir tæknileiðtoga sjálfstraust á verkefni. Við vorum ekki bara að búa til kóða: við vorum að framleiða kóða sem studdi sameiginlegan vegvísi.

Á hápunkti verkefnisins vorum við oft að keyra margar Codex-lotur samhliða. Ein var að vinna við spilun, önnur við leit, enn önnur við villumeðhöndlun, og stundum enn önnur við prófanir eða endurbætur. Þetta var minna eins og að nota verkfæri og meira eins og að stjórna teymi.

Hver lota myndi reglulega skila til baka framvinduskýrslu. Ein gæti sagt: „Ég er búin að skipuleggja þessa einingu; hér er það sem ég legg til,“ á meðan önnur myndi bjóða upp á stóran diff fyrir nýjan eiginleika. Hver krafðist athygli, ábendinga og endurskoðunar. Það var ótrúlega líkt því að vera tæknileiðtogi með nokkra nýja verkfræðinga, allir að ná árangri, allir þurfa á leiðsögn að halda.

Niðurstaðan var samstarfsflæði. Hrá kóðunargeta Codex losaði okkur við mikla handvirka innsláttarvinnu. Við höfðum meiri tíma til að hugsa um högun, lesa pull-beiðnir vandlega og prófa appið. 

Á sama tíma þýddi þessi aukni hraði að við höfðum alltaf eitthvað sem beið í yfirferðarröðinni okkar. Codex lenti ekki í vandræðum vegna samhengisskipta, en við gerðum það. Flöskuhálsinn í þróuninni okkar færðist frá því að skrifa kóða yfir í að taka ákvarðanir, veita ábendingu og samþætta breytingar.

Þetta er þar sem innsýn Brooks kemur fram á nýjan hátt. Þú getur ekki einfaldlega bætt við Codex-lotum og búist við línulegri hraðaaukningu frekar en þú getur haldið áfram að bæta við verkfræðingum í verkefni og búist við að áætlunin styttist línulega. Hvert viðbótar „par af höndum“, jafnvel sýndar, bætir við samhæfingarálagi. Við urðum stjórnandi hljómsveitar frekar en einfaldlega hraðari einleikarar.

Við hófum verkefnið okkar með stórum áfanga: Sora hafði þegar verið gefið út á iOS. Við beindum oft Codex að iOS og bakvinnslukóðagrunninum til að hjálpa því að skilja lykilkröfur og takmarkanir. Í gegnum allt verkefnið gerðum við grín að því að við hefðum enduruppgötvað hugmyndina um fjölverkvangsgrunn. Gleymdu React Native eða Flutter; framtíðin í fjölverkvangsforritun er bara Codex.

Að baki þessu liggja tvær meginreglur:.

1. Rökfræði er færanleg. Hvort sem kóðinn er skrifaður í Swift eða Kotlin, þá er undirliggjandi snjallforritsrökfræði – gagnalíkön, netköll, fullgildingarreglur, viðskiptarökfræði – sú sama. Codex er mjög gott í að lesa Swift-útfærslu og búa til jafngildi í Kotlin sem varðveitir merkingu.
2. Áþreifanleg dæmi veita sterkt samhengi. Ný Codex-lota sem getur séð „hér er nákvæmlega hvernig þetta virkar á iOS“ og „hér er Android-högunin“ er mun áhrifaríkari en sú sem vinnur eingöngu út frá náttúrulegum tungumálalýsingum.

Með því að beita þessum meginreglum gerðum við iOS, bakvinnslu og Android-geymslurnar aðgengilegar í sama umhverfi. Við gáfum Codex fyrirmæli eins og:

„Lestu þessi líkön og endapunkta í iOS-kóðanum og leggðu síðan fram áætlun til að innleiða samsvarandi hegðun á Android með því að nota núverandi API-biðlara okkar og líkanaklassa.“

Ein lítil en gagnleg brella var að útskýra í ~/.codex/AGENTS.md hvar staðbundnir fulltrúar voru og hvað þeir innihéldu. Það gerði Codex auðveldara að uppgötva og vafra um viðeigandi kóða.

Við vorum í raun að vinna að þróun á mörgum kerfum með þýðingu í stað sameiginlegs, óhlutstæðs hugtaks. Þar sem Codex sá um mest af þýðingunni, forðuðumst við að tvöfalda innleiðingarkostnaðinn.

Víðari lærdómurinn er að fyrir Codex skiptir samhengi öllu máli. Codex vann sitt besta verk þegar það skildi hvernig eiginleikinn virkaði nú þegar í iOS, ásamt því að skilja hvernig Android-appið okkar var uppbyggt. Þegar Codex skorti það samhengi, var það ekki að „neita að vinna með“; það var að giska. Því meira sem við komum fram við það sem nýjan liðsfélaga og lögðum áherslu á að veita því rétt inntök, því betur stóð það sig.

Í lok fjögurra vikna sprettsins okkar hætti notkun Codex að vera eins og tilraun og varð sjálfgefið þróunarferli okkar. Við notuðum það til að skilja núverandi kóða, gera áætlun um breytingar og innleiða eiginleika. Við fórum yfir niðurstöðurnar á sama hátt og við myndum fara yfir niðurstöður samstarfsmanns. Þannig afhentum við einfaldlega hugbúnað.

Það varð ljóst að þróun með aðstoð gervigreindar dregur ekki úr þörfinni fyrir nákvæmni; hún eykur hana. Þrátt fyrir hversu hæft Codex er, er markmið þess að komast frá A til B strax. Þetta er ástæðan fyrir því að kóðun með aðstoð gervigreindar virkar ekki án manna. Hugbúnaðarverkfræðingar geta skilið og beitt raunheims takmörkunum kerfa, bestu leiðunum til að hanna hugbúnað og hvernig á að byggja með framtíðarþróun og áætlunum í huga. Ofurkraftar hugbúnaðarverkfræðinga morgundagsins munu vera djúpur skilningur á kerfum og hæfileikinn til að vinna í samvinnu við gervigreind yfir langan tíma. 

Það áhugaverðasta við hugbúnaðarverkfræði er að þróa heillandi vörur, hanna stigstærðarkerfi, skrifa flókin reiknirit og gera tilraunir með gögn, mynstur og kóða. Hins vegar eru veruleikar hugbúnaðarverkfræði fortíðar og nútíðar oft frekar hversdagslegir: að miðja hnappa, tengja endapunkta og skrifa grunnkóða. Nú gerir Codex það mögulegt að einbeita sér að þeim mikilvægustu þáttum hugbúnaðarverkfræði og rökunum fyrir því að við elskum iðn okkar.

Þegar Codex er sett upp í samhengisríku umhverfi þar sem það skilur markmið þín og hvernig þú vilt byggja, getur hvaða teymi sem er margfaldað getu sína. Endurskoðun okkar eftir kynningu er ekki ein lausn sem hentar öllum, og við segjum ekki að við höfum leyst þróun með aðstoð gervigreindar. En við vonum að reynsla okkar geri það auðveldara að finna bestu leiðirnar til að gera Codex kleift að styrkja þig. 

Þegar Codex var kynnt í forskoðun fyrir sjö mánuðum síðan, leit hugbúnaðarverkfræði mjög öðruvísi út. Í gegnum Sora fengum við að kanna næsta kafla í verkfræði. Eftir því sem líkönin okkar og nýting þeirra halda áfram að batna, mun gervigreind verða sífellt ómissandi hluti af byggingunni. 

Hvað ætlarðu að búa til með þínu eigin teymi?