Kuinka käytimme Codexia rakentaaksemme Sora-sovelluksen Androidille 28 päivässä

26.4.2026 alkaen Sora-tuote ei ole enää saatavilla.

Marraskuussa julkaisimme Sora-Android-sovelluksen, jonka avulla kuka tahansa Android-laitteen omistaja voi muuttaa lyhyen kehotuksen eläväksi videoksi. Julkaisupäivänä sovellus nousi Play Storen ykköseksi. Android-käyttäjät loivat yli miljoona videota ensimmäisen 24 tunnin aikana.

Julkaisun taustalla on tarina: Sora-tuotannon Android-sovelluksen alkuperäinen versio luotiin 28 päivässä saman agentin ansiosta, joka on kaikkien tiimien ja kehittäjien käytettävissä: Codex.

8. lokakuuta – 5. marraskuuta 2025 pieni suunnittelutiimi, joka työskenteli yhdessä Codexin kanssa ja käytti noin 5 miljardia tunnistetta, julkaisi Soran Androidille prototyypistä maailmanlaajuiseen lanseeraukseen. Laajuudestaan huolimatta sovelluksen kaatumisvapauden aste on 99,9 prosenttia, ja olemme ylpeitä sen arkkitehtuurista. Jos mietit, käytimmekö salaista mallia, käytimme GPT‑5.1‑Codexin varhaista mallia – samaa versiota, jota mikä tahansa kehittäjä tai yritys voi käyttää tänään CLI:n, IDE-laajennuksen tai verkkosovelluksen kautta.

Kun Sora julkaistiin iOS:lle, käyttö kasvoi räjähdysmäisesti. Ihmiset alkoivat heti luoda videoita jatkuvasti. Androidilla meillä oli vain pieni sisäinen prototyyppi ja kasvava määrä ennakkorekisteröityjä käyttäjiä Google Playssa.

Yleinen reaktio kiireelliseen ja tärkeään julkaisuun on lisätä resursseja ja prosesseja. Tämän laajuinen ja laadukas tuotantosovellus vaatisi yleensä monien insinöörien kuukausien työn, jota koordinointi hidastaisi. 

Amerikkalainen tietokonearkkitehti Fred Brooks varoitti kuuluisasti, että ”myöhässä oleva ohjelmistoprojekti viivästyy entisestään, jos siihen lisätään ihmisiä”. Toisin sanoen, kun yritetään toteuttaa monimutkainen projekti nopeasti, insinöörien määrän lisääminen voi usein hidastaa tehokkuutta lisäämällä viestinnän ylikuormitusta, tehtävien pirstoutumista ja integraatiokustannuksia. Emme jättäneet tätä oivallusta huomiotta, vaan kokosimme vahvan nelihenkisen insinööritiimin, jonka jokainen jäsen oli varustettu Codexilla, mikä lisäsi merkittävästi jokaisen insinöörin vaikutusta. 

Tällä tavalla toimimalla toimitimme Sora for Androidin sisäisen version työntekijöille 18 päivässä ja julkaisimme sen 10 päivää myöhemmin. Pidimme Android-kehityskäytännöt korkealla tasolla, panostimme ylläpidettävyyteen ja vaadimme sovellukselta samaa luotettavuutta kuin perinteisemmiltä projekteilta. (Käytämme Codexia edelleen laajasti sovelluksen kehittämiseen ja uusien ominaisuuksien lisäämiseen).

Jotta voimme ymmärtää, miten työskentelimme Codexin kanssa, on hyödyllistä tietää, missä se loistaa ja missä se tarvitsee ohjausta. Sen kohteleminen juuri palkatun vanhemman insinöörin tavoin oli hyvä lähestymistapa. Codexin ansiosta voimme käyttää enemmän aikaa koodin ohjaamiseen ja tarkistamiseen kuin sen kirjoittamiseen itse.

Missä Codex tarvitsee opastusta

1. Codex ei vielä osaa hyvin päätellä asioita, joita sille ei ole kerrottu (esim. suosimasi arkkitehtuurimallit, tuotestrategia, todellinen käyttäytymisesi ja sisäiset normit tai oikotiet).
2. Samoin Codex ei voinut nähdä sovelluksen todellista toimintaa: se ei voinut avata Soraa laitteella, huomata, että vieritys tuntui oudolta, tai aistia, että kulku oli hämmentävä. Vain tiimimme pystyi hoitamaan nämä kokemukselliset tehtävät.
3. Jokainen tapaus vaatii perehdyttämistä. Selkeiden tavoitteiden, rajoitusten ja ohjeiden jakaminen siitä, ”miten teemme asioita”, oli olennaisen tärkeää Codexin hyvän toiminnan kannalta.
4. Samaan tapaan Codex kamppaili syvällisten arkkitehtonisten ratkaisujen kanssa: Jos se jätettäisiin oman onnensa nojaan, se saattaisi tuoda mukanaan ylimääräisen näkymämallin, kun me halusimme oikeasti laajentaa olemassa olevaa mallia tai siirtää logiikkaa käyttöliittymäkerrokseen, joka selvästi kuului tietovarastoon. Sen vaisto on saada jotain toimimaan, ei asettaa etusijalle pitkäaikaista siisteyttä.

Huomasimme, että on hyödyllistä, kun Codex luo ja ylläpitää runsaasti agentti.md-tiedostoja koko koodikannassa. Tämä helpotti samojen ohjeiden ja parhaiden käytäntöjen soveltamista kaikissa istunnoissa. Esimerkiksi varmistaaksemme, että Codex kirjoitti koodin tyyliohjeidemme mukaisesti, lisäsimme seuraavan tekstin ylätason AGENTS.md-tiedostoon:

Missä Codex loistaa

1. Suurten koodikantojen nopea lukeminen ja ymmärtäminen: Codex tuntee käytännössä kaikki tärkeimmät ohjelmointikielet, mikä helpottaa samojen käsitteiden hyödyntämistä useilla alustoilla ilman monimutkaisia abstraktioita.
2. Testauskattavuus: Codex on (ainutlaatuisen) innokas kirjoittamaan yksikkötestejä, jotka kattavat laajan valikoiman tapauksia. Kaikki testit eivät olleet syvällisiä, mutta kattava testaus auttoi estämään regressioita. 
3. Palautteen hyödyntäminen: Samalla tavalla Codex reagoi hyvin palautteeseen. Kun CI epäonnistui, voimme liittää lokitiedot komentokehotteeseen ja pyytää Codexia ehdottamaan korjauksia.
4. Massiivisesti rinnakkainen, kertakäyttöinen suoritus: Useimmat eivät yritä venyttää rajoja sille, kuinka monta istuntoa he voivat kerralla suorittaa. On täysin mahdollista testata useita ideoita rinnakkain ja pitää koodia kertakäyttöisenä.
5. Tarjoamme uuden näkökulman: Suunnittelukeskusteluissa käytimme Codexia generatiivisena työkaluna potentiaalisten ongelmakohtien tutkimiseen ja uusien ongelmanratkaisutapojen löytämiseen. Esimerkiksi kun suunnittelimme videotoistimen muistin optimointeja, Codex kävi läpi useita SDK:ita ja ehdotti lähestymistapoja, joita meillä ei olisi ollut aikaa analysoida. Codexin tutkimuksen oivallukset osoittautuivat korvaamattomiksi sovelluksen lopullisen muistin käytön minimoimisessa.
6. Tehokkaamman työn mahdollistaminen: Käytännössä käytimme enemmän aikaa koodin tarkistamiseen ja ohjaamiseen kuin sen kirjoittamiseen itse. Codex on kuitenkin myös erittäin hyvä koodin tarkistuksessa, ja se havaitsee usein virheet ennen niiden yhdistämistä, mikä parantaa luotettavuutta.

Kun tunnistimme nämä ominaisuudet, työmallimme tuli yksinkertaisemmaksi. Luotimme Codexiin, joka hoiti suuren osan raskaasta työstä hyvin ymmärrettävien mallien ja selkeästi rajattujen alueiden sisällä, kun taas tiimimme keskittyi arkkitehtuuriin, käyttökokemukseen, järjestelmällisiin muutoksiin ja lopulliseen laatuun.

Jopa parhaalla uudella, kokeneella työntekijällä ei välttämättä ole heti oikeaa näkökulmaa pitkäaikaisten kompromissien tekemiseen. Codexin hyödyntämiseksi ja sen toiminnan varmistamiseksi oli tärkeää, että valvoimme itse sovelluksen järjestelmäsuunnittelua ja keskeisiä kompromisseja. Näihin kuuluivat sovelluksen arkkitehtuurin muotoilu, modulointi, riippuvuuksien injektointi ja navigointi. Toteutimme myös todennuksen ja perusverkkovirrat. 

Tämän perustan pohjalta kirjoitimme muutamia edustavia ominaisuuksia alusta loppuun. Käytimme sääntöjä, joita halusimme koko koodipohjan noudattavan, ja dokumentoimme projektin laajuiset mallit sitä mukaa kuin etenimme. By pointing Codex to representative features, it was able to work more independently within our standards. Arviomme mukaan Codex kirjoitti 85 % projektista, ja huolellisesti suunniteltu perusta esti kalliita takaiskuja ja uudelleenkoodaamista. Se oli yksi tärkeimmistä tekemistämme päätöksistä. 

Ajatuksena ei ollut tehdä mahdollisimman nopeasti ”jotain, joka toimii”, vaan pikemminkin ”jotain, joka toimii niin kuin haluamme”. On monia "oikeita" tapoja kirjoittaa koodia. Meidän ei tarvinnut kertoa Codexille tarkalleen, mitä sen piti tehdä, vaan meidän piti näyttää Codexille, mikä on ”oikeaa” tiimissämme. Kun olimme määrittäneet lähtökohdan ja rakentamistavan, Codex oli valmis aloittamaan.

Kokeilimme, mitä tapahtuisi, kehottamalla: ”Rakenna Sora Android -sovellus iOS-koodin pohjalta. ”, mutta hylkäsimme tämän vaihtoehdon nopeasti. Vaikka Codexin luoma ratkaisu toimi teknisesti, tuotekokemus oli keskinkertaista. Ilman selkeää ymmärrystä päätepisteistä, tiedoista ja käyttäjävirroista Codexin yksittäinen koodi oli epäluotettava (jopa ilman agenttia on riskialtista yhdistää tuhansia rivejä koodia.) 

Oletimme Codexin menestyvän hyvin kirjoitettujen esimerkkien hiekkalaatikossa, ja olimme oikeassa. Codexin pyytäminen "rakentaa tämä asetus-näyttö" lähes ilman kontekstia oli epäluotettavaa. Codexille annettu pyyntö ”rakenna tämä asetusnäyttö käyttäen samaa arkkitehtuuria ja malleja kuin juuri näkemäsi toinen näyttö” toimi paljon paremmin. Ihmiset tekivät rakenteelliset päätökset ja asettivat muuttumattomat tekijät; Codex täytti sitten suuren määrän koodia kyseisen rakenteen sisälle.

Seuraava askeleemme Codexin potentiaalin maksimoimiseksi oli selvittää, miten Codex saataisiin toimimaan pitkään (viime aikoina yli 24 tuntia⁠) ilman valvontaa.

Codexin käytön alkuvaiheessa siirryimme suoraan kehotteisiin, kuten ”Tässä on ominaisuus”. Tässä on joitakin tiedostoja. Rakenna se." Se toimi joskus, mutta enimmäkseen tuotti koodia, joka teknisesti kääntyi, mutta poikkesi arkkitehtuuristamme ja tavoitteistamme.

Siksi muutimme työnkulun. Merkittävien muutosten yhteydessä pyysimme ensin Codexia auttamaan meitä ymmärtämään järjestelmän ja koodin toimintaa. Esimerkiksi pyytäisimme sitä lukemaan joukon siihen liittyviä tiedostoja ja tiivistämään, miten kyseinen ominaisuus toimii; esimerkiksi, miten data kulkee API:sta tietovarastokerroksen, näkymämallin ja käyttöliittymän läpi. Sitten korjaisimme tai tarkentaisimme sen ymmärrystä. Esimerkiksi voisimme huomauttaa, että tietty abstraktio kuuluu oikeastaan eri tasolle tai että tietty luokka on olemassa vain offline-tilassa eikä sitä pitäisi laajentaa.

Samoin kuin sitoutuisit uuteen, erittäin kyvykkääseen tiimikaveriin, me teimme yhteistyötä Codexin kanssa luodaksemme vankan toteutussuunnitelman. Tuo sopimus näytti usein pieneltä suunnitteludokumentilta, jossa määriteltiin, mitä tiedostoja tulisi muuttaa, mitä uusia tiloja tulisi ottaa käyttöön ja miten logiikan tulisi toimia. Vasta sitten pyysimme Codexia aloittamaan sopimuksen toteuttamisen, yksi askel kerrallaan. Hyödyllinen vinkki: erittäin pitkien tehtävien kohdalla, joissa kontekstin ikkunan raja saavutetaan, pyydämme Codexia tallentamaan suunnitelmansa tiedostoon, jotta voimme soveltaa samaa ohjeistusta kaikissa tapauksissa.

Tämä ylimääräinen suunnittelukierros osoittautui ajan arvoiseksi. Se antoi meille mahdollisuuden antaa Codexin toimia "valvomattomana" pitkiä aikoja, koska tiesimme sen suunnitelmat. Se helpotti koodin tarkistamista, koska saatoimme tarkistaa toteutuksen suunnitelmamme perusteella sen sijaan, että olisimme lukeneet kontekstittoman eron. Ja kun jokin meni pieleen, ensin korjata suunnitelman virheen ja vasta sitten koodin. 

Dynaaminen vaikutelma oli samanlainen kuin hyvä suunnitteludokumentti, joka antaa tekniselle johtajalle luottamusta projektiin. Emme vain luoneet koodia: tuotimme koodia, joka tuki yhteistä etenemissuunnitelmaa.

Suoritimme projektin huipulla usein useita Codex-istuntoja rinnakkain. Yksi työskenteli toiston parissa, toinen haun, kolmas virheiden käsittelyn ja joskus neljäs testien tai refaktoroinnin parissa. Se tuntui enemmän tiimin johtamiselta kuin työkalun käytöltä.

Jokainen istunto raportoi meille säännöllisesti edistymisestä. Joku saattaa sanoa: ”Olen saanut tämän moduulin suunnittelun valmiiksi; tässä on ehdotukseni”, kun taas toinen saattaa ehdottaa suurta muutosta uuteen ominaisuuteen. Jokainen edellytti huomiota, palautetta ja tarkastelua. Se oli hämmästyttävän samanlaista kuin työskennellä teknisenä johtajana useiden uusien insinöörien kanssa, jotka edistyvät ja tarvitsevat ohjausta.

Tuloksena oli yhteistyövirta. Codexin raaka koodauskyky vapautti meidät paljosta manuaalisesta kirjoittamisesta. Meillä oli enemmän aikaa miettiä arkkitehtuuria, lukea pull-pyyntöjä huolellisesti ja testata sovellusta. 

Samalla tuo lisänopeus tarkoitti, että tarkastusjonossamme oli aina jotain odottamassa. Kontekstin vaihtaminen ei estänyt Codexia, mutta me jäimme jumiin. Kehityksemme pullonkaula siirtyi koodin kirjoittamisesta päätöksentekoon, palautteen antamiseen ja muutosten integroimiseen.

Tässä Brooksin näkemykset saavat uuden merkityksen. Et voi yksinkertaisesti lisätä Codex-istuntoja ja odottaa lineaarista nopeutumista, aivan kuten et voi lisätä insinöörejä projektiin ja odottaa aikataulun lyhenevän lineaarisesti. Jokainen lisätty "käsipari", jopa virtuaalinen, lisää koordinointityötä. Meistä oli tullut orkesterin kapellimestari sen sijaan, että olisimme vain nopeampia soittajia.

Aloitimme projektimme merkittävällä askeleella: Sora oli jo julkaistu iOS:lle. Ohjasimme usein Codexin iOS- ja backend-koodikantoihin auttaaksemme sitä ymmärtämään keskeisiä vaatimuksia ja rajoituksia. Koko projektin ajan vitsailimme, että olimme keksineet uudelleen ajatuksen alustojen välisestä viitekehyksestä. Unohda React Native tai Flutter; monialustaisuuden tulevaisuus on Codex.

Vitsailun taustalla on kaksi periaatetta:

1. Logiikka on siirrettävissä. Olipa koodi kirjoitettu Swiftillä tai Kotlinilla, sovelluksen peruslogiikka – datamallit, verkkokutsut, validointisäännöt, liiketoimintalogiikka – on sama. Codex on erittäin hyvä lukemaan Swift-toteutuksen ja tuottamaan vastaavan Kotlin-koodin, joka säilyttää semantiikan.
2. Konkreettiset esimerkit tarjoavat vaikuttavan kontekstin. Uusi Codex-istunto, joka voi nähdä ”juuri näin tämä toimii iOS:ssä” ja ”tässä on Android-arkkitehtuuri”, on paljon tehokkaampi kuin sellainen, joka toimii vain luonnollisen kielen kuvauksista.

Näitä periaatteita soveltaen teimme iOS-, backend- ja Android-repositorit saataville samassa ympäristössä. Annoimme Codexille kehotteita, kuten:

Lue nämä mallit ja päätepisteet iOS-koodista ja ehdota sitten sopimuksen vastaavan toiminnan toteuttamiseksi Androidilla käyttämällä olemassa olevaa API-asiakasta ja malliluokkia.

Yksi pieni mutta hyödyllinen temppu oli merkitä ~/.codex/AGENTIT.md-tiedostoon, missä paikalliset repositorit sijaitsivat ja mitä ne sisälsivät. Se helpotti Codexia löytämään ja navigoimaan olennaista koodia.

Teimme tehokkaasti monialustakehitystä käännöksen avulla sen sijaan, että olisimme käyttäneet jaettua abstraktiota. Koska Codex hoiti suurimman osan käännöksestä, vältimme toteutuskustannusten kaksinkertaistamisen.

Laajempi opetus on, että Codexille konteksti on kaikki kaikessa. Codex teki parhaansa, kun se ymmärsi, miten ominaisuus jo toimi iOS:ssa, ja ymmärsi samalla Android-sovelluksemme rakenteen. Kun Codexilta puuttui tämä konteksti, se ei ”kieltäytynyt yhteistyöstä”, vaan arvaili. Mitä enemmän kohtelimme sitä kuin uutta tiimikaveria ja panostimme antamaan sille oikeat syötteet, sitä paremmin se suoriutui.

Neljän viikon sprintin lopussa Codexin käyttö ei enää tuntunut kokeilulta, vaan siitä oli tullut oletuskehityssilmukkamme. Käytimme sitä olemassa olevan koodin ymmärtämiseen, muutosten suunnitteluun ja ominaisuuksien toteuttamiseen. Arvioimme sen tuloksia samalla tavalla kuin arvioisimme tiimikaverin tuloksia. Se oli meidän tapamme toimittaa ohjelmistoja.

Kävi selväksi, että tekoälyavusteinen kehitys ei vähennä perusteellisuuden tarvetta, vaan lisää sitä. Niin kykenevä kuin Codex onkin, sen tavoitteena on päästä pisteestä A pisteeseen B nyt. Siksi tekoälyavusteinen koodaus ei toimi ilman ihmisiä. Ohjelmistosuunnittelijat ymmärtävät ja osaavat soveltaa järjestelmien todellisia rajoituksia, parhaita tapoja suunnitella ohjelmistoja tulevaisuuden kehityssuunnitelmat ja tuotantosuunnitelmat huomioon ottaen. Tulevaisuuden ohjelmistosuunnittelijan supervoimat ovat syvällinen järjestelmien ymmärtäminen ja kyky tehdä pitkäaikaista yhteistyötä tekoälyn kanssa. 

Ohjelmistosuunnittelun mielenkiintoisimpia osia ovat kiinnostavien tuotteiden kehittäminen, skaalautuvien järjestelmien suunnittelu, monimutkaisten algoritmien kirjoittaminen sekä datan, mallien ja koodin kokeileminen. Ohjelmistotekniikan menneisyyden ja nykyisyyden todellisuudet ovat kuitenkin usein arkisempia: painikkeiden keskittäminen, päätepisteiden yhdistäminen ja rutiinikoodin kirjoittaminen. Nyt Codex mahdollistaa keskittymisen ohjelmistokehityksen merkityksellisimpiin osiin ja syihin, joiden vuoksi rakastamme ammattiaamme.

Kun Codex on asennettu kontekstirikkaaseen ympäristöön, jossa se ymmärtää tavoitteesi ja rakentamistapasi, mikä tahansa tiimi voi moninkertaistaa kykynsä. Lanseerauksemme ei ole kaikille sopiva ratkaisu, emmekä väitä ratkaisseemme tekoälyavusteista kehitystä. Toivomme kuitenkin, että kokemuksemme helpottaa parhaiden keinojen löytämistä, joilla Codex voi voimaannuttaa sinua.  

Kun Codex lanseerattiin tutkimusversiona seitsemän kuukautta sitten, ohjelmistokehitys näytti hyvin erilaiselta. Soran kautta pääsimme tutustumaan suunnittelutyön seuraavaan lukuun. Malliemme ja valikoimamme kehittyessä tekoälystä tulee yhä tärkeämpi osa rakentamista. 

Mitä aiot tehdä omalla Codex-tiimilläsi?