Codex'i kullanarak Android için Sora'yı 28 günde nasıl geliştirdik?

26 Nisan 2026 itibarıyla Sora artık kullanımdan kaldırılmıştır.

Kasım ayında Sora Android uygulamasını dünyaya sunarak Android cihazı olan herkese kısa bir komutu canlı bir videoya dönüştürme olanağı sağladık. Yayınlandığı gün, uygulama Play Store'da 1 numaraya ulaştı. Android kullanıcıları, ilk 24 saat içinde bir milyondan fazla video üretti.

Lansmanın arkasında bir hikaye var: Sora'nın Android uygulamasının ilk versiyonu, her ekip veya geliştirici için mevcut olan aynı otonom ajan Codex sayesinde 28 günde yapıldı.

8 Ekim - 5 Kasım 2025 tarihleri arasında Codex ile birlikte çalışan ve yaklaşık 5 milyar token tüketen küçük bir mühendislik ekibi, Sora'yı Android için prototipten küresel lansmana taşıdı. Ölçeğine rağmen uygulama %99,9 çökme olmadan çalışıyor ve gurur duyduğumuz bir mimariye sahip. Eğer gizli bir model kullanıp kullanmadığımızı merak ediyorsanız GPT‑5.1‑Codex'in erken bir sürümünü kullandık. Bugün her geliştirici veya işletme tarafından CLI, IDE uzantısı veya web uygulaması yoluyla kullanılabilen sürümün aynısı.

Sora, iOS'ta piyasaya sürüldüğünde kullanım sayısında adeta patlama yaşandı. İnsanlar hemen video akışları üretmeye başladı. Android'de ise yalnızca küçük bir dahili prototipimiz ve Google Play'de artan sayıda ön kayıtlı kullanıcımız vardı.

Yüksek riskli ve zaman baskısı altındaki lansmanlara genellikle verilen yanıt, kaynaklara yüklenmek ve süreç eklemektir. Bu kapsamda ve kalitede bir uygulama, genellikle birçok mühendisin aylarca çalışmasını gerektirir ve koordinasyon süreci nedeniyle yavaşlar. 

Amerikalı bilgisayar mimarı Fred Brooks, "gecikmiş bir yazılım projesine daha fazla insan eklemek onu daha da geciktirir" şeklinde meşhur bir uyarıda bulunmuştur. Başka bir deyişle karmaşık bir projeyi hızla teslim etmeye çalışırken daha fazla mühendis eklemek, iletişim yükünü artırarak ve görevlerin parçalanmasına ve entegrasyon maliyetlerinin yükselmesine neden olarak verimliliği düşürebilir. Bu öngörüyü görmezden gelmek yerine ona yöneldik. Her mühendisin etkisini önemli ölçüde artırmak için Codex ile donatılmış dört mühendisten oluşan güçlü bir ekip kurduk. 

Bu şekilde çalışarak Sora'nın Android için dahili sürümünü 18 gün içinde çalışanlara ulaştırdık ve 10 gün sonra da genel kullanıma sunduk. Android mühendislik uygulamalarında yüksek bir standardı koruduk, sürdürülebilirliğe yatırım yaptık ve uygulamayı daha geleneksel bir projeden bekleyeceğimiz güvenilirlik seviyesinde tuttuk. (Bugün de Codex'i kapsamlı bir şekilde kullanarak uygulamaya yeni özellikler eklemeye ve geliştirmeye devam ediyoruz).

Codex ile nasıl çalıştığımızı anlamak için nerede başarılı olduğunu ve nerede yönlendirmeye ihtiyaç duyduğunu bilmek faydalı olacaktır. Onu yeni işe alınmış bir kıdemli mühendis gibi değerlendirmek iyi bir yaklaşımdı. Codex'in yeteneği, kodu kendimiz yazmak yerine yönlendirmeye ve incelemeye daha fazla zaman ayırmamıza olanak tanıdı.

Codex'in rehberliğe ihtiyaç duyduğu alanlar

1. Codex, henüz kendisine açıklanmamış olan şeyleri (örneğin, tercih ettiğiniz mimari kalıpları, ürün stratejisi, gerçek kullanıcı davranışları ve iç normlar veya kısayollar) çıkarma konusunda iyi değil.
2. Benzer şekilde Codex, uygulamanın gerçekten çalıştığını göremiyordu: Sora'yı bir cihazda açamıyor, bir kaydırmanın yanlış olduğunu fark edemiyor veya bir akışın kafa karıştırıcı olduğunu hissedemiyordu. Bu deneyimsel görevleri sadece ekibimiz üstlenebilirdi.
3. Her birim oryantasyon gerektirir. Net hedeflerle, kısıtlamalarla bağlamı ve "işleri nasıl yaptığımız" konusundaki rehberliği paylaşmak, Codex'in iyi çalışmasını sağlamak için çok önemliydi.
4. Aynı şekilde Codex de derin mimari yargılarla mücadele etti: Kendi başına bırakıldığında gerçekten mevcut bir modeli genişletmek istediğimiz yerde fazladan bir görünüm modeli sunabiliyor veya açıkça bir depoya ait olan mantığı kullanıcı arayüzü katmanına itebiliyor. İçgüdüsü uzun vadeli temizliğe öncelik vermekten ziyade bir şeyi çalışır hale getirmek oldu.

Kod tabanı genelinde AGENT.md dosyalarını oluşturmak ve sürdürmek için Codex'in kullanılmasının faydalı olduğunu gördük. Bu, aynı rehberliği ve en iyi uygulamaları oturumlar genelinde uygulamayı kolaylaştırdı. Örneğin, Codex'in kodu stil yönergelerimize uygun yazmasını sağlamak için en üst düzey AGENTS.md dosyamıza aşağıdakileri ekledik:

Codex'in üstün olduğu alanlar

1. Büyük kod tabanlarını hızla okumak ve anlamak: Codex, neredeyse tüm büyük programlama dillerini bildiğinden karmaşık soyutlamalara gerek kalmadan birçok platformda aynı kavramları kullanmayı kolaylaştırır.
2. Test kapsamı: Codex geniş bir yelpazede durumu kapsayan birim testleri yazma konusunda (özgün bir şekilde) heveslidir. Her test derinlemesine değildi, ancak kapsam genişliğine sahip olmak, gerilemeleri önlemede faydalı oldu. 
3. Geri bildirimi uygulamak: Benzer şekilde Codex, geri bildirimlere iyi yanıt veriyor. CI başarısız olduğunda günlük çıktısını bir komuta yapıştırabiliyor ve Codex'ten düzeltmeler önermesini talep edebiliyoruz.
4. Kitlesel paralel, tek kullanımlık yürütme: Çoğu kişi aynı anda çalıştırabileceği oturum sayısının sınırlarını zorlamayacak. Birden fazla fikri aynı anda test etmek ve kodu geçici olarak görmek oldukça mümkündür.
5. Yeni bir bakış açısı sunmak: Tasarım tartışmalarında olası hata noktalarını keşfetmek ve sorunları çözmenin yeni yollarını bulmak için Codex'i üretken bir araç olarak kullandık. Örneğin, biz video oynatıcı bellek optimizasyonları tasarlarken Codex birden fazla SDK'yı inceleyerek bizim zaman ayıramayacağımız yaklaşımlar önerdi. Codex'in araştırmasından elde edilen bilgiler, son uygulamanın bellek ayak izini en aza indirmede paha biçilmez olduğunu kanıtladı.
6. Daha yüksek etkili çalışmayı sağlama: Pratikte, kodu kendimiz yazmaktan çok incelemeye ve yönlendirmeye daha fazla zaman harcadık. Bununla birlikte Codex, kod incelemede de çok iyiydi ve genellikle hataları birleştirmeden önce yakalıyor ve bu sayede güvenilirliği artırıyor.

Bu özellikleri kabul ettikten sonra çalışma modelimiz daha sade hale geldi. Mimariye, kullanıcı deneyimine, sistemik değişikliklere ve nihai kaliteye odaklanan ekibimiz, iyi anlaşılan kalıplar ve iyi tanımlanmış kapsamlar içinde büyük miktarda ağır işi yapmak için Codex'i kullandı.

En iyi yeni, kıdemli çalışan bile uzun vadeli kararlar almak için hemen doğru bakış açısına sahip değildir. Codex'ten yararlanmak ve çalışmalarının sağlam ve sürdürülebilir olmasını sağlamak için uygulamanın sistem tasarımını ve önemli denge analizlerini kendimiz denetlememiz kritik öneme sahipti. Bunlar arasında uygulamanın mimarisinin şekillendirilmesi, modülerleştirme, bağımlılık enjeksiyonu ve navigasyon yer alıyordu. Ayrıca kimlik doğrulama ve temel ağ akışlarını da hayata geçirdik. 

Bu temelden birkaç örnek özelliği baştan sona yazdık. Tüm kod tabanının uymasını istediğimiz kuralları uyguladık ve proje genelindeki kalıpları ilerledikçe kayıt altına aldık. Codex'i bu özelliklere yönlendirdiğimizde standartlarımız dahilinde daha bağımsız çalışabildi. Codex tarafından %85 oranında yazıldığını tahmin ettiğimiz bir projede dikkatlice planlanmış bir temel, maliyetli geri dönüşleri ve yeniden düzenlemeleri önledi. Verdiğimiz en önemli kararlardan biri bu oldu. 

Amaç, mümkün olan en kısa sürede "çalışan bir şey" yapmak değil, "nasıl çalışmasını istediğimizi anlayan bir şey" yapmaktı. Kod yazmanın birçok "doğru" yolu vardır. Codex'e tam olarak ne yapması gerektiğini söylememize gerek yoktu. Ekibimizde neyin "doğru" olduğunu Codex'e göstermemiz gerekiyordu. Başlangıç noktamızı ve nasıl inşa etmeyi sevdiğimizi belirledikten sonra Codex başlamaya hazırdı.

Ne olacağını görmek için "iOS koduna dayanarak Sora Android uygulamasını oluştur. Başla." şeklinde bir komut verdik ama hızla bu yoldan vazgeçtik. Codex'in oluşturduğu her ne kadar teknik olarak çalışsa da ürün deneyimi yetersizdi. Uç noktalar, veri ve kullanıcı akışları hakkında net bir anlayış olmadan Codex'in tek seferlik kodu güvenilir değildi (Bir otonom ajan kullanmadan bile binlerce satır kodu birleştirmek risklidir.) 

Codex'in iyi yazılmış örneklerle dolu bir sanal ortamda başarılı olacağını öngördük ve haklı çıktık. Codex'e neredeyse hiç bağlam olmadan "bu ayarlar ekranını oluştur" demek, güvenilir bir yöntem değildi. Codex'e, "az önce gördüğün diğer ekranla aynı mimariyi ve kalıpları kullanarak bu ayarlar ekranını oluştur" demek çok daha iyi sonuç verdi. Yapısal kararları veren ve sabit değerleri belirleyen insanlar oldu. Ardından Codex, bu yapının içine büyük miktarda kod ekledi.

Codex'in potansiyelini en üst düzeye çıkarmak için bir sonraki adımımız, Codex'i uzun süreler boyunca (son zamanlarda 24 saatten fazla⁠) gözetimsiz çalışacak şekilde etkinleştirmeyi öğrenmekti.

Codex'i kullanmaya başladığımızda "İşte özellik. İşte bazı dosyalar. Lütfen bunu geliştir." gibi komutlar kullandık. Bu bazen işe yaradı, ancak çoğunlukla teknik olarak derlenmiş, fakat mimarimizden ve hedeflerimizden uzaklaşmış kodlar üretti.

Bu nedenle iş akışını değiştirdik. Önemli bir değişiklik yapmadan önce sistemin ve kodun nasıl çalıştığını anlamamıza yardımcı olması için ilk olarak Codex'e başvurduk. Mesela ilgili dosyaları okumasını ve bu özelliğin nasıl çalıştığını özetlemesini istedik (örneğin verilerin API'den depo katmanına, görünüm modeline ve kullanıcı arayüzüne nasıl aktığı gibi). Sonra anlayışını düzelttik ya da geliştirirdik. (Örneğin, belirli bir soyutlamanın aslında farklı bir katmanda yer alması gerektiğini veya belirli bir sınıfın yalnızca offline mod için var olduğunu ve genişletilmemesi gerektiğini belirttik.)

Yeni ve son derece yetenekli bir ekip arkadaşıyla kuracağınız etkileşim gibi Codex ile sağlam bir plan oluşturduk. Bu plan, hangi dosyaların değişmesi gerektiğini, hangi yeni durumların tanıtılması gerektiğini ve mantığın nasıl akması gerektiğini belirten minyatür bir tasarım belgesi gibi görünüyordu. Ancak bunu yaptıktan sonra Codex'ten planı adım adım uygulamaya başlamasını istedik. Faydalı bir ipucu: Çok uzun görevlerde, bağlam penceremizin sınırına ulaştığımızda aynı yönlendirmeyi farklı durumlarda uygulayabilmek için Codex'ten planını bir dosyaya kaydetmesini istedik.

Bu ekstra planlama döngüsü için ayırdığımız zamana değdi. Planlarını bildiğimiz için Codex'in uzun süre "denetimsiz" çalışmasına izin verebildik. Bu, kod incelemesini kolaylaştırdı, çünkü bağlamdan yoksun bir farkı okumak yerine uygulamayı planımıza karşı kontrol edebildik. Bir şeyler ters gittiğinde önce plan, sonra kod üzerinde hata ayıklaması yapabildik. 

Bu dinamik, iyi bir tasarım belgesinin bir projede teknoloji liderine güven vermesine benziyordu. Sıradan bir kod değil, ortak yol haritasını destekleyen bir kod üretiyorduk.

Projenin en yoğun döneminde genellikle paralel olarak birden fazla Codex oturumu yürütüyorduk. Biri oynatma üzerinde çalışıyordu, diğeri arama, bir başkası hata yönetimi ve bazen bir diğeri testler veya yeniden düzenlemeler üzerinde çalışıyordu. Bir araç kullanmaktan çok ekip yönetmek gibiydi.

Her oturum, ilerleme hakkında bize periyodik olarak rapor veriyordu. Biri, "Bu modülü planlamayı bitirdim. İşte önerim" diyebilirken bir diğeri, yeni bir özellik için büyük bir değişiklik sunabiliyordu. Her biri dikkat, geri bildirim ve inceleme gerektiriyordu. Bu durum, hepsi ilerleme kaydeden ve yönlendirmeye ihtiyaç duyan birkaç yeni mühendisi işe almış bir teknoloji lideri olmaya tuhaf bir şekilde benziyordu.

Sonuç, iş birlikçi bir akış oldu. Codex'in ham kodlama yeteneği, bizi birçok manuel yazma işleminden kurtardı. Mimari üzerine düşünmek, pull request'leri dikkatlice incelemek ve uygulamayı test etmek için daha fazla zamanımız oldu. 

Aynı zamanda bu ekstra hız, inceleme kuyruğumuzda her zaman bir şeylerin beklemesine neden oluyordu. Codex, bağlam değişikliği nedeniyle tıkanıklık yaşamadı ama biz yaşadık. Geliştirme sürecindeki darboğazımız, kod yazmaktan karar vermeye, geri bildirim sağlamaya ve değişiklikleri entegre etmeye kaydı.

Brooks'un öngörülerinin yeni bir şekilde anlam kazandığı yer burasıdır. Codex oturumları ekleyerek doğrusal hız artışları beklemek, bir projeye mühendis ekleyerek takvimin doğrusal olarak kısalmasını beklemek kadar gerçek dışıdır. Sanal bile olsa eklenen her "yardım eli" koordinasyon yükünü artırır. Enstrümanı daha hızlı çalabilen solo müzisyenler yerine bir orkestranın şefi haline gelmiştik.

Projemize büyük bir adımla başladık: Sora, iOS'ta zaten kullanıma sunulmuştu. Temel gereksinimleri ve kısıtlamaları anlamasına yardımcı olmak amacıyla Codex'i sık sık iOS ve arka uç kod tabanlarına yönlendirdik. Proje boyunca çapraz platform çerçevesi fikrini baştan icat ettiğimizle ilgili şakalar yaptık. React Native veya Flutter'ı unutun: Çapraz platformun geleceği yalnızca Codex'tir.

Esprinin altında iki ilke yatmaktadır:

1. Mantık taşınabilirdir. Kod ister Swift ister Kotlin ile yazılmış olsun temel uygulama mantığı (veri modelleri, ağ çağrıları, doğrulama kuralları, iş mantığı) aynıdır. Codex, bir Swift uygulamasını okuyarak anlamını koruyan eş değer bir Kotlin kodu üretmekte çok iyidir.
2. Somut örnekler güçlü bir bağlam sunar. iOS'ta "işte tam olarak böyle çalışıyor" ve "işte Android mimarisi" ifadelerini görebilen yeni bir Codex oturumu, yalnızca doğal dil açıklamalarından çalışan bir oturumdan çok daha etkilidir.

Bu ilkeleri uygulayarak iOS, arka uç ve Android depolarını aynı ortamda erişilebilir hale getirdik. Codex'e şu tür komutlar verdik:

"iOS kodundaki bu modelleri ve uç noktaları oku ve ardından mevcut API istemcimizi ve model sınıflarımızı kullanarak Android'de eş değer davranışı uygulamak için bir plan öner."

Küçük ama kullanışlı bir numara, ~/.codex/AGENTS.md dosyasında yerel depoların nerede olduğunu ve ne içerdiklerini detaylandırmaktı. Bu, Codex'in ilgili kodu keşfetmesini ve içinde gezinmesini kolaylaştırdı.

Paylaşılan soyutlama yerine çeviri yoluyla etkili bir şekilde çapraz platform geliştirmesi yapıyorduk. Çoğu çeviriyi Codex gerçekleştirdiği için uygulama maliyetlerini iki katına çıkarmaktan kaçınmış olduk.

Çıkarılacak büyük ders şudur ki Codex için bağlam her şeydir. Codex, iOS'taki özelliğin nasıl çalıştığını ve Android uygulamamızın yapısını anladığında en iyi işi çıkardı. Codex bağlamdan yoksun olduğunda "iş birliğini reddetmiyordu" ancak sadece tahmin yürütüyordu. Ona yeni bir ekip arkadaşı gibi davrandıkça ve doğru girdiler sağladıkça performansı daha da iyileşti.

Dört haftalık çalışmamızın sonunda Codex kullanımı bir deney olmaktan çıkıp varsayılan geliştirme döngümüz haline geldi. Mevcut kodu anlamak, değişiklikler için plan yapmak ve özellikleri uygulamak için onu kullandık. Çıktılarını, bir takım arkadaşımızın çıktılarını gözden geçiriyormuş gibi inceledik. Yazılımı bu şekilde hazırladık.

Yapay zeka destekli geliştirmenin, titizlik gereksinimini azaltmak yerine artırdığı net bir şekilde ortaya çıktı. Codex ne kadar yetenekli olursa olsun amacı şu anda A'dan B'ye ulaşmak. İşte bu nedenle yapay zeka destekli kodlama, insan olmadan çalışmaz. Yazılım mühendisleri, sistemlerin gerçek dünya kısıtlamalarını anlayıp uygulayabilir, yazılımı en iyi şekilde tasarlayıp gelecekteki geliştirme ve ürün planlarını göz önünde bulundurarak inşa edebilir. Yarının yazılım mühendisinin süper güçleri; derin sistem anlayışı ve yapay zeka ile uzun vadeli iş birliği yapabilme yeteneği olacaktır. 

Yazılım mühendisliğinin en ilginç kısımları, etkileyici ürünler geliştirmek, ölçeklenebilir sistemler tasarlamak, karmaşık algoritmalar yazmak ve veri, kalıplar ve kod ile deneyler yapmaktır. Ancak geçmişte ve günümüzde yazılım mühendisliğinin gerçekleri genellikle daha sıradan konulara odaklanır: Düğmeleri ortalamak, uç noktaları bağlamak ve şablon kod yazmak. Codex artık yazılım mühendisliğinin en anlamlı kısımlarına ve zanaatımızı sevme nedenlerimize odaklanmayı mümkün kılıyor.

Codex, hedeflerinizi ve nasıl inşa etmeyi sevdiğinizi anladığı, bağlam açısından zengin bir ortamda kurulduğunda her ekibin yeteneklerini artırabilir. Lansman retrospektifimiz her duruma uyan bir çözüm değil ve yapay zeka destekli geliştirmeyi çözdüğümüzü iddia etmiyoruz. Ancak deneyimimizin, Codex'in sizi güçlendirecek en iyi yolları bulmanızı kolaylaştırmasını umuyoruz. 

Codex yedi ay önce araştırma önizlemesi olarak piyasaya sürüldüğünde yazılım mühendisliği çok farklı görünüyordu. Sora aracılığıyla mühendisliğin bir sonraki aşamasını keşfetme fırsatını bulduk. Modellerimiz ve donanımlarımız geliştikçe yapay zeka, yazılım üretmenin vazgeçilmez bir parçası haline gelecek. 

Kendi Codex ekibinizle siz neler yapacaksınız?