Uzun Süren Codex Hedefim: Dört Gün Geçti ve Hâlâ Çalışıyor

Uzun Süren Codex Hedefim: Dört Gün Geçti ve Hâlâ Çalışıyor

9 Ekim 2026'da uzun süredir devam eden Codex hedefim 4 gün, 14 saat, 8 dakika ve 22 saniye gösteriyordu. Codex henüz yayımlamadığım bir SEO ürünü üzerinde çalışmaya devam ederken ekran görüntüsü aldım. Hedef hâlâ açıktı ve tamamlanması gereken daha fazla görev vardı.

Ondan, geliştirmekte olduğum ve henüz yayımlanmamış SEO ürünü için planın tamamını tamamlamasını istemiştim. O zamana kadar ayrıca daha fazla agent kullanmasını, reasoning effort seviyesini düşürmesini, güncellemeler için duraklamasını, yeniden başlatmanın ardından devam etmesini ve testleri tekrarlamaya daha az zaman ayırmasını istemiştim.

Bu, uzun süren bir Codex hedefiyle ilgili deneyimim: ürettiği işler, onu yavaşlatan işler ve hâlâ vermem gereken kararlar. Bu, tamamlanmamış bir geliştirme sürecidir; bir benchmark veya lansman duyurusu değildir.

Yukarıdaki sayaç hedefe aittir. Dört günlük kesintisiz model hesaplamasını kanıtlamaz. Oturumumda açıkça belirtilen duraklamalar ve devam etmeler, bir uygulama güncellemesi, bilgisayarın yeniden başlatılması, tool çalıştırma ve bekleme bulunuyor.

Codex'ten ne geliştirmesini istedim

Konuşma 3 Ekim'de daha küçük bir soruyla başladı: kullanıcıların kendi giriş bilgileri olacak mı, Google ile giriş yapabilecekler mi ve kişisel MCP anahtarları oluşturabilecekler mi?

Daha sonra gereksinimleri genişlettim. Her kullanıcı kendi projelerini görmeliydi. Kullanıcılar bir workspace'e kişi davet edebilmeliydi. Kişisel tercihler ve crawler concurrency için ayarlar istedim. Platform sonunda ticari olacaktı ve başlangıçta ücretsiz bir lansman yapılacaktı.

Geliştirmeye yön vermesi için çok daha büyük bir SEO ürün kataloğu sağladım. Ortaya çıkan plan 15 ürün alanını, 42 uygulama referansını ve 19 herkese açık ücretsiz aracı, ayrıca bir website traffic ranking özelliğini kapsıyordu. Teknik SEO, keyword research, rankings, backlinks, AI visibility, content, analytics, local SEO ve daha sonraki enterprise özelliklerini içeriyordu.

Ayrıca ürünün, kendi web sitemin arkasındaki content engine üzerinden makaleler sipariş etmesini istedim.

Bu nedenle planın tamamlanması talimatı, kapsamlı bir ürün yol haritasına atıfta bulunuyordu. Bu kapsamın oluşturulmasına ben de yardımcı oldum. Küçük bir bug fix üzerindeki dört günlük sayaç farklı bir hikâye anlatırdı.

Hangi model ve ayarları kullandım

Ana oturum günlüğü, modelin GPT-6.1 Sol olduğunu ve tanımlayıcısının gpt-6.1-sol olduğunu gösteriyor. Kaydedilen turlarda ultra, medium ve az sayıda high reasoning ayarı kullanılmış. Bu, ana oturumu tanımlar; her reviewer veya external tool'un arkasındaki modeli göstermez.

5 Ekim'de token tasarrufu yapmak için effort seviyesini açıkça medium olarak değiştirdim. Aynı nedenle turbo'yu da kapattım. Bunlar benim niyetlerimdi, ölçülmüş tasarruflar değil: iki yapılandırma için denetlenmiş bir maliyet karşılaştırmam yok.

Ayrıca daha fazla paralel agent istedim. Oturum, uygulamanın bazı bölümleri için devredilmiş işler ve Claude peer review'ları kullandı. Bu, ayrı görevlerin ilerlemesini sağladı; ancak çıktılarını birleştirmek ve ortaya çıkan sonucu doğrulamak için ek iş de oluşturdu.

Bir Codex hedefi ne kadar süre çalışmaya devam edebilir?

Bu durumda arayüz, aynı devam eden hedef için dört günden fazlasını gösterdi. Destekleyebildiğim gözlem bu. Bu, maksimum çalışma süresi garantisi değildir ve ekran görüntüsünden aktif inference süresini hesaplayamam.

OpenAI, Codex'te Goals özelliğini turlar boyunca devam eden hedefler olarak açıklıyor. Codex bir sonuca doğru ilerlemeye devam edebilir; kullanıcı da onu duraklatabilir veya sürdürebilir. Tamamlanma, kesintiler, bütçeler ve engeller işin devam edip etmeyeceğini etkiler.

Deneyimim bu kalıcı workflow ile örtüşüyor. Duraklamalardan sonra aynı hedefe dönebildim ve sonraki çalışmayı yönlendirebildim. Hedefi erişilebilir tutmak faydalıydı. Ancak bu, hedefi küçültmedi veya her yeni turun ürünü lansmana yaklaştıracağını garanti etmedi.

9 Ekim'e kadar ne teslim etmişti?

9 Ekim'deki teslim günlüğünde, 69 maddelik takip listesinden 30 kısmen tamamlanmış gereksinim, 39 değerlendirilmemiş gereksinim ve tamamen kabul edilmiş sıfır gereksinim kaydedilmişti.

Bu sayının bağlama ihtiyacı var. Liste, geniş ürün kabulünü ölçüyor. Tamamen kabul edilmiş gereksinim sayısının sıfır olması, çalışan hiçbir kod olmadığı anlamına gelmez. 30 kısmi gereksinim de ürünün yüzde 43 oranında tamamlandığı anlamına gelmez.

Günlük, desteklenen bir account baseline için tek kullanımlık bir local smoke test kaydediyor: ilk hesabı oluşturmak, password ile giriş yapmak, session'ı ve özel owner workspace'ini okumak, ardından çıkış yapmak ve eski session'ı reddetmek. Bu, sınırları belirlenmiş bir test sonucuna sahip somut bir kullanıcı akışıdır. En güncel eksiksiz uygulamanın müşterilere hazır olduğunun kanıtı değildir.

Diğer ilerlemeler arasında local password-reset source integration, backlink review taslakları, kaydedilmiş Search Console report çalışması, customer-token GA4 report transport ve article-to-LinkedIn taslak çalışması vardı. Bu parçaların birçoğunda hâlâ devre dışı activation, tamamlanmamış integration veya ertelenmiş verification bulunuyordu.

Tarihli checkpoint'ler açıkça commit, push veya deployment yapılmadığını bildiriyordu. Google login ve müşterilerin tam olarak kullanıma hazır olması doğrulanmamıştı. Kullanışlı kanıtlarla birlikte büyüyen bir local implementation vardı; yayımlanmış bir platform değil.

Uzun süren Codex hedefimi ne yavaşlattı?

Hedefi bir ürün yol haritasına dönüştürdüm

Google login eklemek tek bir özellik gibi görünüyor. Özel müşteriler eklemek ise projelere, raporlara, background job'lara ve integration'lara kimlerin erişebileceğini değiştiriyor. Bu sınırın uygulamanın tamamında korunmasını istedim.

Ardından keyword research, backlinks, content generation ve çok daha büyük bir katalog ekledim. Geçen sürenin bir bölümü geniş bir hedef üzerinde gerekli çalışmaları yansıtıyor. İlk hedefim, bir sonraki tamamlanmamış alanı açmaya devam etmeyi kolaylaştırdı.

Verification süreci fazla tekrarlı hâle geldi

Source-backed kararlar, dar kapsamlı değişiklikler, review'lar ve açık kanıtlar istedim. Bu talimatlar, bir şeyin tamamlandığına dair belirsiz iddiaların önlenmesine yardımcı oldu.

Ancak oturumda tekrarlanan source kontrolleri, review hazırlıkları ve test fixture çalışmaları birikti. Benim değerlendirmeme göre denge, bir sonraki kullanılabilir akışı tamamlamadan önce tek tek parçaları kanıtlamaya fazla kaydı.

9 Ekim'de, testlere bu kadar fazla zaman ayırmayı bırakmasını, tamamlanmaya doğru çalışmasını ve daha büyük bir testi sonraya bırakmasını söyledim. Bu, account isolation'ı doğrulama ihtiyacını ortadan kaldırmadı. Sıralamayı değiştirdi: implementation sırasında odaklanmış kontroller, ardından birleştirilmiş akışın daha geniş doğrulaması.

Bazı hatalar test kurulumuna aitti

Bir password-reset database denemesi, synthetic account kaydında gerekli bir display-name alanı bulunmadığı için başarısız oldu. Bu fixture'ı düzeltmek testi çalıştırmak için gerekliydi, ancak yeni bir ürün özelliği değildi.

Daha sonraki uzun süren bir database denemesi, workstation yeniden başlatıldığında sona erdi. Teslim günlüğü bu denemenin başarılı olduğunu iddia etmedi. Sonraki teşhis, önceki verification contract'larının tekrar tekrar hesaplandığını ve ilerleme çıktısının buffer'landığını ortaya çıkardı; bu da çalışan sürecin değerlendirilmesini zorlaştırdı.

Bu ayrıntılar önemli, çünkü beklemek belirsizdir. Canlı bir süreç çalışıyor, aynı ön koşulu yeniden hesaplıyor veya henüz göremediğim bir çıktı üretiyor olabilir. Sayaç tek başına hangisinin gerçekleştiğini söyleyemez.

Daha fazla agent koordinasyon ekledi

Paralel çalışma, birbirinden ayrılabilen görevlerde yardımcı oldu. Ana oturumun yine de sonuçları incelemesi, bağımlılıkları çözmesi ve değişiklikleri tek bir uygulamaya dahil etmesi gerekiyordu. Aynı projeyi agent'larla ve agentsız çalıştırmadığım için hız artışını agent eklemeye bağlayamam.

Pratik soru, başka bir agent'ın bağımsız bir parçayı tamamlayıp tamamlayamayacağı veya ana oturum için yeni bir handoff oluşturup oluşturmayacağı hâline geldi.

İnsan olarak hâlâ yaptığım şeyler

Ürün yönünü seçiyor ve sırada hangi özelliklerin önemli olduğuna karar veriyorum. Bildirilen ilerlemenin çalışan davranışı mı, local source code mu yoksa doğrulanmamış bir öneri mi olduğunu kontrol ediyorum. Codex'i güncellemem veya bilgisayarı yeniden başlatmam gerektiğinde çalışmayı duraklatıyor, ardından kaydedilmiş durumundan devam etmesini istiyorum.

Ayrıca hızı sorguluyorum. Bu geliştirme sırasında:

Plan ve teslim günlüğü, chat mesajlarının ötesinde inceleyebileceğim bir şey sağlıyor. Ancak bunlar da disiplin gerektiriyor: tarihli bir checkpoint, yalnızca neyin değiştiğini ve neyin kanıtlanmamış kaldığını söylüyorsa faydalıdır.

Şimdiye kadarki avantajlar ve dezavantajlar

Bu geliştirmeyle ilgili deneyimimde en büyük avantaj continuity. Kapsamlı bir hedefi açık tutabiliyor ve kesintilerden sonra sürdürebiliyorum. Codex local implementation'lar üretti, hataları araştırdı ve çalışmayı incelememe yardımcı olan ayrıntılı kayıtlar tuttu.

Aynı proje içinde çeşitli iş türlerini de ele alabiliyor: database değişiklikleri, API davranışı, frontend akışları, integration transport'ları ve documentation. Bu, yönlendirebileceğim geniş bir geliştirmeyi mümkün kılıyor.

Dezavantaj ise activity'nin progress gibi görünebilmesi. Tamamlanmış birçok kontrol, tamamlanmamış bir ürünle aynı anda var olabilir. Yüksek reasoning effort ve daha fazla agent, daha hızlı teslimatı garanti etmeden bütçe ve koordinasyon tercihleri doğuruyor.

Uzun çalışmalar scope discipline'ı da zorlaştırıyor. Kısmen tamamlanmış bir yol haritası, agent'a savunulabilir birçok sonraki adım sunuyor. Bir sonraki faydalı sonucu hangisinin sağlayacağına benim karar vermem gerekiyor.

Kalıcı bir hedefi yeniden kullanırdım, ancak her implementation aşamasına daha küçük bir acceptance target verirdim. Örneğin: bir account oluştur, giriş yap, özel workspace'ini gör ve ikinci bir account'tan gelen erişimi reddet. Daha büyük yol haritasını context olarak koru, bu akışı tamamla ve ardından devam et.

Sırada neyi ölçeceğim

SEO ürünü hâlâ geliştirme aşamasında ve 9 Ekim itibarıyla yayımlanmış değil. Sıradaki faydalı ölçüm, mevcut birleştirilmiş uygulamaya karşı tamamlanmış bir kullanıcı akışı ve kalan blocker'ların açıkça listelenmesi.

Bundan sonra Google login, customer-bound integration'lar, kişisel MCP anahtarları ve güvenli bir release için kanıt istiyorum. Codex görevler üzerinde çalışmaya devam ediyor; bu makale 9 Ekim'deki durumu kaydediyor. Geliştirmeyi, hedefin ne kadar süre açık kaldığına göre değil, bu sonuçlara göre değerlendireceğim.

Kaynaklar ve bu anlatımın sınırları

Sayaç yukarıdaki ekran görüntümden geliyor. Model identifier'ı, ayarlardaki değişiklikler ve müdahalelerim ana oturum geçmişinden geliyor. Kapsam ve ilerleme sayıları proje planı ile tarihli teslim günlüğünden geliyor. Bu proje kayıtları özel çalışma belgeleridir; günlükleri veya müşteri verilerini yayımlamadım.

OpenAI'ın Using Goals in Codex sayfası, kalıcı hedef workflow'unu açıklıyor. Bu kaynak, Goals açıklamasını destekliyor; projemle ilgili teslim iddialarını değil.

69 maddelik sayı, geniş kapsamlı bir acceptance snapshot'ıdır; geriye kaç saat kaldığının ölçümü değildir. Ekran görüntüsü kesintisiz inference'ı kanıtlamaz, ayar değişiklikleri maliyet tasarrufunu kanıtlamaz ve local kontroller production readiness oluşturmaz. Bu geliştirme hâlâ devam ediyor.

*Bu makale, ekran görüntüm, oturum geçmişim ve proje teslim kayıtlarımdan AI yardımıyla taslak hâline getirildi. Devam eden tek bir geliştirmeyi anlatıyor. Genel bir Codex runtime sınırı, model sıralaması, denetlenmiş bir maliyet veya production readiness ortaya koymuyor.*