Codex’te Model Yönlendirme: Sol, Terra, Luna ve Spark

Bir düğmenin rengini değiştirmek için en derin modelin uzun uzun düşünmesini beklerken, kimlik doğrulama akışındaki kritik bir hatayı hızlı modele bırakabilirsiniz. İki görev de ekranda “kod yazma” olarak görünür; fakat aynı düşünme bütçesini, aynı denetim seviyesini ve aynı geri bildirim döngüsünü istemez.

Codex Pro gibi yüksek kullanım kapasitesi sunan bir çalışma ortamında asıl soru “En güçlü model hangisi?” değildir. Daha yararlı soru şudur: Bu görev için yeterli olan en düşük güç nedir ve hangi bulgu ortaya çıkarsa bir üst seviyeye geçmeliyim?

Bu yazıda benchmark sıralamalarına yaslanmadan uygulanabilecek bir model yönlendirme sistemi kuracağız. Görevleri belirsizlik, etki alanı ve geri bildirim maliyeti üzerinden sınıflandıracak; Spark, Luna, Terra ve Sol arasında başlangıç seçimi yapacak; test başarısızlığı, tutarsız değişiklik veya yeni bir bilinmeyen ortaya çıktığında yükseltme kuralı uygulayacağız. Sonunda amacımız daha fazla kod üretmek değil, daha çok doğrulanmış ve yayımlanabilir iş bitirmek olacak.

Model seçimi neden yalnızca hız ve zekâ meselesi değildir?

Daha derin çalışan bir model, belirsiz bir mimari problemi araştırırken değerli olabilir. Ancak her görevde onu kullanmak üç görünmez maliyet doğurur.

Bekleme maliyeti: Sonucu birkaç saniyede doğrulanabilecek küçük işler gereksiz yere yavaşlar.
İnceleme maliyeti: Basit bir değişiklik için geniş kapsamlı çözüm üretildiğinde okunacak ve elenecek kod miktarı artar.
Kapasite maliyeti: Sınırlı kullanım bütçesi, gerçekten derin araştırma isteyen sorunlar yerine rutin işlerde tüketilir.

Tersi de tehlikelidir. Hızlı bir model yerel ve açık bir düzenlemede başarılı olabilirken ödeme, yetkilendirme veya veri geçişi gibi görevlerde yüzeyde çalışan ama sınır durumlarını kaçıran bir çözüm üretebilir. İlk bakışta kazanılan süre; hata ayıklama, geri alma ve insan incelemesi sırasında fazlasıyla geri ödenir.

Doğru yönlendirme, “ucuz modeli mümkün olduğunca çok kullanmak” değildir. Görev riskine uygun başlangıç seviyesini seçmek ve kanıt yetersiz kaldığında zamanında yükseltmektir.

Bu nedenle model tercihini model isimlerinden önce işin yapısına bağlamak gerekir.

Görevi üç eksende okuyun

Her göreve üç ayrı puan vereceğiz. Puanlar bilimsel kesinlik iddiası taşımaz; ekip içinde tutarlı karar verebilmek için kullanılan pratik bir dil oluşturur.

1. Belirsizlik: Ne yapılacağı ve neden bozulduğu ne kadar açık?

1 — Düşük: İstenen değişiklik açık, ilgili dosya biliniyor ve doğru sonuç kolayca tarif edilebiliyor.
2 — Orta: Birkaç olası neden veya çözüm var; kod tabanında kısa bir araştırma gerekiyor.
3 — Yüksek: Problem tanımı eksik, birden fazla sistem etkileniyor veya mimari bir tercih yapılması gerekiyor.

“Buton metnini ‘Devam et’ olarak değiştir” düşük belirsizliklidir. “Form bazen gönderilmiyor” orta belirsizliklidir; tarayıcı doğrulaması, ağ isteği veya sunucu cevabı sorumlu olabilir. “Tekrarlanan ödemeleri nasıl önlemeliyiz?” ise yüksek belirsizliklidir; hata tekrar denemelerinden idempotency tasarımına kadar geniş bir alan açar.

Uygulama kuralı: Görevi tek cümlede yazdıktan sonra “Doğru çözümün hangi dosyada olduğunu biliyor muyum?” ve “İki makul çözüm çelişebilir mi?” diye sorun. İkinci soruya evet diyorsanız belirsizliği en az 2 kabul edin.

2. Etki alanı: Yanlış değişiklik ne kadar uzağa yayılır?

1 — Yerel: Tek bileşen, metin, stil veya kolayca geri alınabilen küçük davranış.
2 — Sınırlı sistemik: Birden fazla modül, ortak form bileşeni, API sözleşmesi ya da kalıcı olmayan kullanıcı durumu.
3 — Kritik: Kimlik doğrulama, yetkilendirme, ödeme, veri kaybı, gizlilik, güvenlik veya geri dönüşü zor veri geçişi.

Burada değişen satır sayısına aldanmamak gerekir. Bir yetki kontrolündeki tek satır, yüz satırlık sunum bileşeninden daha yüksek etkiye sahip olabilir. Etkiyi diff büyüklüğüyle değil, yanlış sonucun ulaşabileceği alanla ölçeriz.

Kırmızı çizgi: Para, erişim yetkisi, hassas veri veya geri dönüşü zor kalıcı veri değişiyorsa toplam puanı beklemeden görevi kritik kabul edin. Güçlü başlangıç, bağımsız inceleme ve kontrollü yayımlama gerekir.

3. Geri bildirim maliyeti: Yanlış yaptığımızı ne kadar çabuk anlarız?

1 — Ucuz: Linter, birim testi, derleme veya hızlı görsel karşılaştırma sonucu hemen gösterir.
2 — Orta: Entegrasyon testi, birkaç kullanıcı akışı veya farklı ekran ölçüleri kontrol edilmelidir.
3 — Pahalı: Gerçek servislerle uçtan uca deneme, manuel güvenlik incelemesi, veri geri yükleme provası veya üretim benzeri ortam gerekir.

Hatanın kolay bulunması, hızlı başlangıcı güvenli kılabilir. Aynı model yanlış karar verse bile test birkaç dakika içinde bunu gösterebilir. Fakat hata ancak gerçek ödeme sağlayıcısının dönüşünde veya günler sonra oluşan bir yarış durumunda görülebiliyorsa ilk çözümün gerekçesi daha derin incelenmelidir.

Uygulama kuralı: “Bu çözüm yanlışsa bunu hangi somut kanıt gösterecek?” sorusuna tek cümleyle cevap veremiyorsanız geri bildirim maliyetini 3 sayın. Önce doğrulama yöntemini tasarlayın.

Puanı modele çevirmek

Üç puanı toplayarak başlangıç için basit bir yönlendirme tablosu elde ederiz. Bu bir otomatik pilot değil, varsayılan seçimdir.

Toplam	Başlangıç profili	Uygun iş biçimi	Beklenen doğrulama
3–4	Spark veya Luna	Dar, açık, kolay geri alınabilir değişiklik	Hızlı test, derleme ya da görsel kontrol
5–6	Terra	Gündelik geliştirme, birkaç dosyalı hata veya özellik	Birim ve entegrasyon testleri, diff incelemesi
7–9	Sol	Belirsiz, mimari veya hata etkisi yüksek problem	Geniş test, gerekçe incelemesi ve bağımsız kod değerlendirmesi

10 Ağustos 2026 tarihli Codex model belgelerinde Sol, Terra ve Luna farklı hız–derinlik profilleriyle konumlandırılıyor; Pro’ya özel Spark ise hızlı, gerçek zamanlı iterasyon için sunuluyor. Pratik ayrım şöyle kurulabilir:

Spark: Kapsamın çok dar tutulduğu, hızlı karşılıklı iterasyonun değerli olduğu işler.
Luna: Açıkça tanımlanmış küçük uygulama ve düzeltmeler.
Terra: Kod tabanını bir miktar araştıran, birkaç parçayı birleştiren gündelik geliştirme.
Sol: Problem tanımını açmayı, seçenekleri karşılaştırmayı veya yüksek etkili bir kararı gerekçelendirmeyi gerektiren işler.

Model seçimiyle düşünme seviyesi aynı karar değildir. Terra ile başlanabilecek bir görev, orta düzey araştırma gerektirebilir; Sol seçilen kritik bir işte ise önce yalnızca plan ve risk analizi istenebilir. “Güçlü model” demek “hemen büyük bir değişiklik yap” demek değildir.

Üç doldurulmuş örnek

Örnek 1: Açılış sayfasındaki metin düzeltmesi

Görev: Fiyatlandırma kartındaki “14 gün ücretsiz deneyin” metnini, kampanyayla uyumlu biçimde “7 gün ücretsiz deneyin” olarak değiştirmek.

Eksen	Puan	Gerekçe
Belirsizlik	1	Hedef metin ve doğru yeni değer açık.
Etki alanı	1	Yerel içerik değişikliği; ancak aynı vaadin başka yerde tekrarlanması kontrol edilmeli.
Geri bildirim	1	Arama, derleme ve sayfa önizlemesiyle hemen doğrulanabilir.

Toplam: 3. Spark veya Luna ile başlanabilir. Fakat kabul testi yalnızca “sayfa açılıyor” değildir: Eski “14 gün” ifadesi ilgili ürün yüzeylerinde kalmamalı, yeni metin kartta taşmamalı ve bağlantının hedefi değişmemelidir.

Bu küçük örnek önemli bir alışkanlık gösterir: Hızlı modele verilen iş de bir başarı sözleşmesi ister. Küçük görev, ölçütsüz görev değildir.

Örnek 2: Kayıt formunda doğrulama hatası

Görev: Kullanıcı, başında veya sonunda boşluk bulunan e-posta adresi yazdığında form geçerli adresi reddediyor.

Eksen	Puan	Gerekçe
Belirsizlik	2	Sorun istemci doğrulamasında, ortak şemada veya sunucu normalizasyonunda olabilir.
Etki alanı	2	Kayıt davranışı ve ortak e-posta bileşenleri etkilenebilir.
Geri bildirim	2	Birim testine ek olarak kayıt akışının uçtan uca denenmesi gerekir.

Toplam: 6. Terra uygun başlangıçtır. Görev talimatı “boşlukları kırp” kadar dar yazılmamalıdır. Önce normalizasyonun sistemde nerede yapılması gerektiği bulunmalı; istemci ile sunucunun farklı değerler işlemesi önlenmelidir.

Doldurulmuş kabul testi şöyledir:

" deniz@example.com " girdisi, sunucuya "deniz@example.com" olarak ulaşır ve kayıt başarılı olur.
"deniz @example.com" geçersiz kalır; iç boşluk sessizce düzeltilmez.
Aynı normalizasyon giriş, parola sıfırlama ve davet akışlarında çelişkili sonuç üretmez.
Değişiklik yalnızca gerekli dosyalara dokunur; ilgisiz form bileşenleri yeniden yazılmaz.

Terra ortak şemanın beklenmedik biçimde birçok servise yayıldığını bulursa artık başlangıç puanı geçerli değildir. Yeni bilgi, görevin etki alanını büyütür ve yükseltmeyi tetikleyebilir.

Örnek 3: Çift ödeme riskini önleme

Görev: Kullanıcı ödeme düğmesine iki kez bastığında veya ağ zaman aşımından sonra istek yeniden denendiğinde aynı sipariş için iki tahsilat oluşmasını engellemek.

Eksen	Puan	Gerekçe
Belirsizlik	3	İstemci kilidi, sunucu durumu, benzersiz anahtar ve sağlayıcı davranışı birlikte düşünülmeli.
Etki alanı	3	Para hareketi, sipariş durumu ve müşteri güveni etkileniyor.
Geri bildirim	3	Yeniden deneme, zaman aşımı ve eşzamanlı istek senaryoları üretim benzeri ortamda sınanmalı.

Toplam: 9. Sol ile başlanmalı; fakat ilk teslim kod değil, durum geçişlerini ve başarısızlık senaryolarını açıklayan bir plan olmalıdır. Örneğin aynı sipariş kimliğiyle gelen iki eşzamanlı isteğin tek bir idempotency anahtarını paylaşması, bir işlemin başarıyla sonuçlanması ve diğerinin aynı sonucu güvenle okuması beklenebilir. Gerçek uygulama, kullanılan ödeme sağlayıcısının doğrulanmış sözleşmesine göre yapılmalıdır.

Bu değişiklik için yalnızca ajanın kendi testine güvenilmez. Ayrı bir inceleme turu; yarış durumunu, anahtarın saklanma süresini, başarısız işlemden sonra yeniden denemeyi ve sipariş–ödeme durumu arasındaki tutarlılığı sorgulamalıdır. Modelin güçlü olması, bağımsız doğrulama ihtiyacını azaltmaz; incelenecek kararların kalitesini yükseltir.

En düşük yeterli güçle başlayın, körü körüne orada kalmayın

Yönlendirme sisteminin ekonomik değeri, düşük riskli işlerin hızlı hatta kalmasından gelir. Güvenlik değeri ise yükseltme kuralından gelir. Şu dört sinyalden biri görülürse görev yeniden puanlanmalıdır:

Kabul testi iki kez başarısız oluyor. Aynı yaklaşımı daha uzun promptlarla zorlamak yerine sorun sınıfının yanlış anlaşılmış olabileceğini kabul edin.
Diff beklenmedik biçimde genişliyor. Tek bileşenlik iş ortak altyapıya uzanıyorsa etki alanı puanı yükselmiştir.
Model birbiriyle çelişen gerekçeler sunuyor. Çalışan kod üretmesi, karar modelinin tutarlı olduğu anlamına gelmez.
Yeni bir dış bağımlılık veya geri dönüşü zor durum ortaya çıkıyor. Veri geçişi, yetki sınırı ya da üçüncü taraf sözleşmesi keşfedildiğinde kırmızı çizgi uygulanır.

Pratik yükseltme sırası şöyle olabilir: Spark veya Luna başarısızsa önce görev tanımını ve kabul testini düzeltin; problem hâlâ birkaç bileşene yayılıyorsa Terra’ya geçin. Terra yeni mimari belirsizlik ya da kritik etki keşfederse Sol’dan önce bir araştırma ve plan isteyin. Sol’un ürettiği çözümü ise bağımsız kod incelemesi ve somut testlerle doğrulayın.

Her başarısızlık daha güçlü model gerektirmez. Test yanlış beklenti taşıyor, geliştirme ortamı bozuk veya gereksinim kendi içinde çelişkili olabilir. Yükseltmenin amacı sorumluluğu modele devretmek değil, daha fazla araştırma kapasitesi açmaktır.

Yönlendirmeyi çalışma sistemine yerleştirin

Karar tablosu yalnızca zihinde kalırsa yoğun bir günde unutulur. Bunu görev kartına veya proje talimatlarına kısa bir sözleşme olarak ekleyin. Aşağıdaki doldurulmuş örnek, kayıt formu hatası için kullanılabilir:

Görev: E-posta alanının başındaki ve sonundaki boşlukları güvenle normalleştir.
Belirsizlik: 2 — normalizasyonun ortak şemada mı sunucuda mı olduğu araştırılacak.
Etki: 2 — kayıt, giriş ve parola sıfırlama akışları kontrol edilecek.
Geri bildirim: 2 — birim testleri ve kayıt akışı testi çalıştırılacak.
Başlangıç: Terra.
Kapsam sınırı: E-posta dışındaki alanların doğrulamasını yeniden tasarlama.
Kabul: Dış boşluk kırpılır; iç boşluk geçersiz kalır; üç kimlik akışı tutarlı davranır.
Yükseltme: Ortak şema başka servisleri etkiliyorsa veya iki kabul denemesi başarısızsa Sol ile planı yeniden değerlendir.
Teslim kanıtı: Değişen dosyalar, geçen testler ve kalan riskler kısa biçimde raporlanır.

Codex’in proje talimatları bu kuralları kalıcılaştırmak için kullanılabilir. Worktree yaklaşımı da farklı risk sınıflarındaki işleri birbirinden ayırmaya yardımcı olur: küçük görsel düzenleme ile ödeme deneyi aynı çalışma ağacında birbirine karışmaz. Görsel girdiler ve uygulama görüntüleri, arayüz görevlerinde “bana doğru göründü” yerine karşılaştırılabilir kabul kanıtı sağlar. Bağımsız kod incelemesi ise özellikle yüksek etkili değişikliklerde uygulayan ajan ile sorgulayan rolü ayırır.

Yayımlama kapısı da modelden bağımsız olmalıdır. Bir değişiklik ancak şu dört koşul birlikte sağlandığında hazır sayılabilir:

İstenen davranış açık kabul testini geçiyor.
Diff, görev kapsamıyla orantılı ve açıklanabilir durumda.
Kritik etkiler için bağımsız inceleme tamamlanmış.
Geri alma veya güvenli durdurma yolu belli.

Sites gibi dağıtım akışları teslimi hızlandırabilir; fakat hızlı dağıtım, doğrulamanın yerine geçmez. Dağıtım düğmesi çalışma sisteminin son adımıdır, başarı ölçütü değil.

Kapasiteyi verime dönüştüren haftalık alıştırma

Bir hafta boyunca tamamlanan on görevi seçin. Her biri için başlangıç puanlarını, seçilen modeli, kaç yükseltme yapıldığını ve insanın incelemeye harcadığı süreyi kaydedin. Ardından üç soruya bakın:

Hangi işler gereksiz yere ağır modelle başladı?
Hangi işlerde risk geç fark edildi ve yükseltme gecikti?
Hangi kabul testleri hatayı model cevabından daha hızlı ortaya çıkardı?

Örneğin on işin altısı yerel ve kolay doğrulanabilir olduğu hâlde Sol ile başladıysa hız sorunu model kapasitesinden değil yönlendirme alışkanlığından kaynaklanıyor olabilir. Buna karşılık Terra ile başlayan iki görev sürekli ödeme veya yetki sınırına çarpıyorsa kırmızı çizgi tanımınız yeterince erken çalışmıyordur. Sayılar burada performans gösterisi için değil, bir sonraki seçimi değiştirmek için kullanılır.

Sonuç: En güçlü model değil, en güçlü geri bildirim döngüsü

Codex Pro’nun yüksek kapasitesi, ancak görevler doğru hatta yönlendirildiğinde üretkenliğe dönüşür. Dar ve kolay sınanabilen işler Spark veya Luna ile hız kazanabilir. Gündelik, birkaç parçalı geliştirme Terra’ya bırakılabilir. Belirsiz ya da etkisi yüksek kararlar Sol’un daha derin araştırmasından yararlanabilir. Fakat bu isimlerin hiçbiri kendi başına kalite güvencesi değildir.

Kalite; görevi sınıflandırma, kapsamı sınırlama, kabul testini önceden yazma, yeni belirsizlikte yükseltme ve bağımsız kanıtla bitirme zincirinden doğar. Bugün uygulanabilecek ilk adım basit: Sıradaki üç kodlama görevinize belirsizlik, etki ve geri bildirim puanı verin. Sonra en güçlü modeli değil, yeterli olan en düşük başlangıcı ve açık yükseltme koşulunu seçin. Ham kapasiteyi yayımlanabilir ürüne çeviren şey tam olarak bu disiplindir.

Her Vida İçin Balyoz Kullanmayın: Codex’te Model Yönlendirme