Codex'te Goals Nasıl Kullanılır

• Goals, Codex thread'inin tanımlanmış bir sonuca doğru birden fazla tur boyunca çalışmayı sürdürmesini sağlayan kalıcı hedef (persistent objective) özelliğidir
• Tek bir prompt ile ele alınması zor olan profilleme, yama hazırlama, benchmark çalıştırma, flaky test yeniden üretimi, kanıta dayalı denetim gibi işler için uygundur
• Sonuç (outcome), doğrulama yüzeyi (verification surface) ve kısıtlar (constraints) tanımlandığında Codex, tamamlanıp tamamlanmadığını kanıta dayalı olarak kendi değerlendirir
• /goal, /goal pause, /goal resume, /goal clear komutlarıyla yaşam döngüsü kontrolü yapılabilir; Codex 0.128.0'dan itibaren desteklenir
• Thread kapsamıyla sınırlı bir tamamlanma sözleşmesi (completion contract) yapısıdır; sınırsız otonom çalıştırma değil, kullanıcı kontrolü altındaki süreklilik esastır

---

Goals'un tanımı ve neden eklendiği

• Goals, Codex'e bir tamamlanma koşulu (completion condition) veren özelliktir; neyin doğru olması gerektiğini, başarının nasıl kontrol edileceğini ve hangi kısıtların korunacağını tanımlar
• Codex zaten depo inceleme, hata düzeltme, test ekleme, hata nedenini açıklama, odaklı değişiklik uygulama gibi kapsamı net kodlama işlerinde iyi çalışır
• Goals, bir sonraki adımın Codex'in süreç içinde öğrendiklerine göre değiştiği işler için uygundur
  • Profilleme, yama hazırlama, benchmark, flaky test yeniden üretimi, araştırma sorularını kanıta dayalı denetime dönüştürme gibi işler
• Bu tür işler daha büyük bir prompt değil, kalıcı bir hedef gerektirir
• Bir Goal etkin olduğunda, her ara sonuçta hedefi yeniden ifade etmeye gerek kalmadan Codex hedefi korur, tamamlanma durumunu değerlendirir ve bir sonraki eylemi seçer
• Goal, sınırları olmayan bir arka plan otonomisi değil, kapsamı tanımlanmış ve kullanıcı kontrolündeki bir tamamlanma sözleşmesidir

Quickstart: Goals nasıl kullanılır

• Varış noktası net ama oraya giden yol belirsiz olan işlerde Goal kullanın
  • Uygun adaylar: performans optimizasyonu, flaky test incelemesi, bağımlılık migrasyonu, yeniden üretim gerektiren hata takibi, çok aşamalı refactor, benchmark tabanlı tuning, nihai çıktı gerektiren araştırma işleri
  • Tek seferlik düzenlemeler için normal prompt daha uygundur

• Kurulum ve sürüm kontrolü

  • Goals, Codex 0.128.0 ve sonrasında kullanılabilir
  • npm: npm install -g @openai/codex@latest ardından codex --version
  • Homebrew: brew update && brew upgrade --cask codex ardından codex --version

• Goal ayarlama ve yaşam döngüsü komutları

  • /goal <sonuç> biçiminde ayarlanır, örn: /goal Reduce p95 latency below 120 ms without regressing correctness tests
  • /goal: mevcut Goal'ü görüntüler
  • /goal pause: etkin Goal'ü duraklatır
  • /goal resume: duraklatılmış Goal'ü sürdürür
  • /goal clear: mevcut Goal'ü kaldırır

• Durma koşulu (stopping condition)

  • Başarı, duraklatma, kaldırma, iptal, bütçe sınırına ulaşma veya kullanıcı girdisi gerektiren bir engel ortaya çıkması durumunda durur
• "Devam et", "sonraki mümkün düzeltmeyi dene", "benchmark'ı tekrar çalıştır", "şimdi testleri kontrol et" gibi tekrar eden yönlendirmeleri her turda vermeniz gereken durumlarda Goal bu niyeti açıkça ifade eder

Goals ve prompt'lar arasındaki fark

• Normal prompt: "bir sonraki işi yap"
• Goal: "bu sonuç doğru olana kadar çalışmayı sürdür"

• Davranış farkı

  • Normal istekte Codex anlık talimatı yerine getirir, sonucu bildirir ve bekler
  • Goal'de thread'e kalıcı hedef (durable target) eklenir; tur sona erdikten sonra mevcut kanıtı inceler ve hedefin karşılanıp karşılanmadığına karar verir
  • Hedef karşılanmadıysa, Goal etkinse ve bütçe uygunsa en güncel durumdan çalışmayı sürdürebilir

• Örnek: /goal Reduce p95 checkout latency below 120 ms on the checkout benchmark while keeping the correctness suite green

  • Ölçülebilir sonuç, doğrulama yöntemi ve kısıtlar sağlar
  • Codex benchmark çalıştırma → hot path inceleme → hedefli değişiklik → benchmark'ı yeniden çalıştırma → doğruluk test paketini çalıştırma döngüsünü tekrarlar; sonuç yetersizse devam eder

• Zihinsel model

  • Prompt: ask → work → result → wait
  • Goal: work → check → continue or complete
• Goal bitiş çizgisini sağlar, ancak iş yine de kanıta karşı denetlenmiş (audited against evidence) olmalıdır

İyi bir Goal nasıl yazılır

• İyi bir Goal daha uzun bir prompt değil; Codex'in nasıl çalışacağını, neyin başarı sayılacağını ve başarıya ulaşılamazsa ne yapılacağını tanımlayan özlü bir sözleşmedir

• Güçlü bir Goal'ün tanımladığı 6 unsur

  • Outcome: İş tamamlandığında doğru olması gereken şey
  • Verification surface: Bunu kanıtlayan test, benchmark, rapor, çıktı, komut çıktısı veya kaynak materyal
  • Constraints: Codex çalışırken regresyona uğramaması gereken şeyler
  • Boundaries: Kullanılabilecek dosyalar, araçlar, veriler, depolar ve kaynaklar
  • Iteration policy: Her denemeden sonra sırada ne yapılacağına karar verme biçimi
  • Blocked stop condition: Mevcut sınırlar içinde savunulabilir bir yol kalmadığında raporlayıp duracağı an

• Yazım kalıbı

  • /goal <istenen bitiş durumu> verified by <somut kanıt> while preserving <kısıtlar>. Use <izin verilen girdiler/araçlar/sınırlar>. Between iterations, <bir sonraki en iyi eylemi seçme biçimi>. If blocked or no valid paths remain, <raporlanacak şey ve ilerlemek için gereken girdi>.

• Zayıf örnek ve güçlü örnek

  • Zayıf: /goal Reduce p95 checkout latency below 120 ms without regressing correctness tests
  • Güçlü: doğrulama yöntemi (checkout benchmark), kullanım kapsamı (checkout service, benchmark fixture'ları, ilgili testler), iterasyon politikası (değişiklikler, benchmark sonuçları, sonraki deneyin kaydı) ve engel raporlama koşulunu da açıkça belirtir

• Araştırma / inceleme odaklı Goal'ler

  • Kesin kanıtın mümkün olmayabileceği durumlarda, işe başlamadan önce kanıt standardını (evidence standard) tanımlayın
  • Örnek: /goal Produce the strongest evidence-backed reproduction of the paper using the available materials and local resources. Attempt the headline results where feasible, verify outputs where possible, and end with a report that separates confirmed findings, approximate reconstructions, blocked claims, and remaining uncertainty.

• Goal yazımını Codex'e devretme

  • İşi düz bir dille açıklama → Codex'ten taslak Goal yazmasını isteme → başarı koşulu, doğrulama yöntemi, kısıtlar ve engel durma koşulunu iyileştirip etkinleştirme şeklindeki iki aşamalı workflow önerilir

Goal etkin olduğunda değişenler

• Hedef görünür kalır

  • Test başarısız olsa bile thread ilk hedefi korur
  • Benchmark iyileşse ama eşik değere ulaşmasa Codex ilerlemeyi sürdürür
  • Araştırma yolu veri eksikliğine takılsa bile araştırma standardını kaybetmeden kanıt planını ayarlar

• Boşta olan thread'de sürdürme (continuation) mümkün olur

  • Başka bir tur etkinse, kullanıcı girdisi kuyruktaysa veya başka thread işleri bekliyorsa sürdürmez
  • Yalnızca thread boşta olduğunda, Goal etkin olduğunda ve bütçe uygunsa sürdürür

• Tamamlanma kanıta dayanmalıdır

  • Modelin "muhtemelen bitti" diye düşünmesi tamamlandı sayılması için yeterli değildir
  • Ancak ilgili dosyalar, testler, log'lar, benchmark çıktıları, üretilen artefaktlar ve diğer somut kanıtlar üzerinden hedefi kontrol ettikten sonra tamamlanmış sayılır
• Tasarımın özü şudur: Codex ilerlemeyi sürdürebilir, ancak tamamlanmayı kanıt belirler

Codex içinde Goals'un tasarım yapısı

• Goals, thread kapsamlı kalıcı durum (persisted thread state) olarak uygulanır; genel bellek ya da proje düzeyinde talimat değildir
  • Hedef, ilgili bağlamın bulunduğu thread'e aittir: incelenen dosyalar, çalıştırılan komutlar, üretilen diff'ler, görülen log'lar ve muhakeme kaydı

• Mimari katmanlar

  • Kalıcı ve thread kapsamlı durum olarak hedef, yaşam döngüsü, bütçe ve ilerleme muhasebesini kaydeder
  • Goal durumları: active, paused, complete, budget-limited
  • Duruma göre Codex'in devam edip etmeyeceği, kullanıcıyı bekleyip beklemeyeceği veya yeni iş yerine ilerleme özeti sunup sunmayacağı belirlenir

• Sürdürme (continuation) olay tabanlıdır

  • Basit bir döngü değildir; yalnızca güvenli sınırlarda kontrol edilir: turun bitimi, bekleyen iş olmaması, kullanıcı girdisi kuyruğu olmaması, thread'in boşta olması
  • Dispatcher davranışı temkinlidir: yalnızca planlama amaçlı işler sürdürmeyi tetiklemez, kesinti olduğunda hedef duraklatılır, thread yeniden başladığında uygunsa hedef geri yüklenir, sürdürme turu araç çağrısı yapmazsa bir sonraki otomatik sürdürme engellenir (spin önleme)

• Prompt katmanı

  • Sürdürme prompt'u Codex'i etkin hedef etrafında hizalar, ancak tamamlamadan önce denetim gerektirir
  • Hedefi somut kanıtla karşılaştırır: değiştirilen dosyalar, çalıştırılan komutlar, geçen testler, benchmark çıktıları, üretilen artefaktlar, araştırma kanıtları

• Bütçe yönetimi

  • Bütçeye ulaşıldığında esas çalışma durur, ilerleme ve engeller özetlenir, sonraki faydalı adım belirlenir
  • Bütçe sınırına ulaşmak Goal'ün tamamlandığı anlamına gelmez

• Araç sözleşmesi (tool contract)

  • Model Goal'ü başlatabilir; mevcut Goal'ü ancak kanıt tamamlandığını desteklediğinde tamamlandı olarak işaretleyebilir
  • Duraklatma, sürdürme, kaldırma ve bütçe sınırı geçişleri kullanıcı veya sistem kontrolü altında kalır

Zayıf Goal'ü güçlü Goal'e dönüştürme

• Performans tuning örneği

  • Zayıf: /goal Improve performance
  • Güçlü: /goal Reduce p95 latency below 120 ms on the checkout benchmark while keeping the correctness test suite green
  • Güçlü sürüm sonuç, doğrulama yöntemi ve kısıt sağlar; ne zaman durmaması gerektiğini anlamasını mümkün kılar
    • p95 180ms'den 135ms'ye inse bile Goal tamamlanmış sayılmaz
    • Gecikme 120ms'nin altına inse ama doğruluk testleri başarısız olsa yine tamamlanmış sayılmaz
    • Benchmark çalıştırılamıyorsa başarı ilan etmek yerine engeli görünür kılar

• Goal için uygun kapsam

  • Denetlenebilir olacak kadar dar, ama bir sonraki eylemi seçebilecek kadar geniş olmalıdır
  • "Fix the failing checkout test", gerçek sorun yukarı akış bağımlılığıysa fazla dardır
  • "Improve the whole system" ise denetim yüzeyi olmadığı için fazla geniştir
  • "Make the checkout test suite pass on the current branch without changing public API behavior" uygun bir örnektir

• Üretilen artefaktlar için de aynı ilke geçerlidir

  • Zayıf: /goal Write docs for this feature
  • Güçlü: /goal Produce a docs page for Goals that explains the lifecycle, command surface, and two examples. Verify that the page builds locally and that all referenced commands match the current CLI behavior.
  • Güçlü sürüm denetlenebilir sayfa, build komutu ve komut davranışı sağlar

• Araştırma Goal'lerinde kanıt standardı

  • İnceleme başlamadan önce şunları tanımlayın: tam yeniden üretim, kısmi yeniden yapılandırma, vekil destek ve engel olarak işaretlenecek unsurlar
  • Güçlü bir araştırma Goal'ü; iddia envanteri oluşturmayı, iddia-kanıt eşlemesini, uygulanabilir parçaları hayata geçirmeyi, engelleri etiketlemeyi ve doğrulanmış iddialar, yalnızca destekleyici kanıt, engellenmiş iddialar ve kalan belirsizlikleri ayıran bir denetim üretmeyi gerektirir

Bileşik araştırmalarda Goals kullanımı: kuant makale yeniden üretimi örneği

• Vaka özeti

  • Hedef: Buehler, Gonon, Teichmann ve Wood'un Deep Hedging makalesi
  • Makalenin konusu: sinir ağı tabanlı trading stratejilerinin, risk tercihi, işlem maliyetleri ve yüksek boyutlu piyasa ortamlarında model tabanlı hedge'i yeniden üretip üretemeyeceği
  • Doğru Goal, soyut bir "makaleyi yeniden üret" değil; manşet sayısal iddiaları denemeyi, tam mekanizmalar ile yaklaşık öğrenilmiş ikameleri ayırmayı ve mevcut materyallerle tam yeniden üretimin mümkün olmadığı kısımları açıkça belirtmeyi içermelidir

• Zayıf ve güçlü araştırma Goal'ü

  • Zayıf: /goal Reproduce Buehler et al., "Deep Hedging"
    • Hangi bölümlerin önemli olduğu, neyin yeniden üretim sayıldığı, eğitim durumunun yokluğunun nasıl ele alınacağı ve yaklaşık eşleşmeyle tam tekrar arasındaki ayrım tanımlı değildir
  • Güçlü: /goal Produce the strongest evidence-backed reproduction of Buehler et al., "Deep Hedging," using the available paper materials and local resources. Attempt every headline result, verify the outputs, and end with a report that separates reproduced mechanics, approximate trained results, blocked exact replay, and remaining uncertainty.

• Codex'in fiilen yaptığı işler

  • Manşet iddiaları ile destekleyici iddiaları ayırma
  • İddiaları mevcut kanıta eşleme
  • Yerelde test edilebilir parçaları yeniden kurma
  • Eldeki materyallerle tam olarak yeniden üretilemeyen iddiaları etiketleme

• Gerçekleştirilebilen kısımlar

  • Fiyatlama ve hedge mekanizmalarının yeniden kurulması
  • Heston referans fiyatının yeniden üretilmesi
  • CVaR hedge deneyleri için policy eğitimi
  • Ana histogram ve hedge surface artefaktlarının yeniden üretilmesi
  • Black-Scholes işlem maliyeti eğiminin yeniden üretilmesi
  • Heston işlem maliyeti ve yüksek boyutlu örnekler için eğitilmiş kontrollerin yürütülmesi

• Engel olarak kalan kısımlar

  • Makale tam random seed'leri, üretilmiş eğitim yollarını, TensorFlow graph'larını, optimizer durumunu, checkpoint'leri veya tam özgün simülasyon durumunu sunmuyor
  • En dürüst sonuç kısmi ve yaklaşık yeniden üretimdir; tam sinir ağı tekrar üretimi değildir

• Raporun epistemik destek düzeyini korumak

  • Eğitilmiş ikameler bir iddiayı destekleyebilir, sayısal olarak yakın eşleşme güveni artırabilir ve yeniden oluşturulmuş şekiller sonucun bir kısmını doğrulayabilir; ancak bunların hiçbiri özgün deneyin birebir geri kazanıldığı şeklinde ifade edilmemelidir
  • Örnek kayıt (ledger):
    • Claim: Deep hedging approximates complete-market Heston hedge without transaction costs
    • Route: model mekanizmasını yeniden kurma, referans hedge ile karşılaştırma, sinir ağı policy eğitimi
    • Evidence surface: fiyat kontrolleri, histogramlar, hedge surface
    • Status: Yakın yaklaşık yeniden üretim
    • Remaining uncertainty: özgün eğitim yolları, seed'ler ve checkpoint'ler mevcut değil
• Araştırmada Goals'un gösterdiği değer, belirsizlik içinde ilerlemeyi sürdürürken makul görünen çıktıların abartılı sonuçlara dönüşmesini önlemesidir; tamamlanmayı kanıta dayalı iddia bazlı denetim, yaklaşık sonuçların açıkça belirtilmesi ve yeniden üretim ile tekrar oynatma arasındaki sınır konusunda dürüstlük olarak tanımlar

Goals ne zaman kullanılmamalı

• Tek satırlık düzenleme, basit açıklama, kısa code review veya tek cevapla durulması istenen sorular için uygun değildir → normal Codex prompt'u daha uygundur
• Bitiş çizgisi belirsizse uygun değildir
  • "Make this better" güvenilir bir tamamlanma koşulu sunmaz
  • "Refactor this code" da beklenen son durum, testler ve kısıtlar tanımlanmadan zayıf kalır
• Belirsizliği gizlemek için kullanılmamalıdır
  • Veri erişilemez olabilir ise bunu Goal içinde belirtin
  • Benchmark flaky olabilir ise bunun nasıl ele alınacağını belirtin
  • Vekil kanıta izin veriliyorsa bunun nasıl etiketleneceğini tanımlayın
• Goals'un en güçlü olduğu durumlar: kalıcı hedef, kanıta dayalı bitiş çizgisi ve çok turlu araştırma gerektiren yol özelliklerinin bir araya geldiği işlerdir

Sonuç: hedef ilerlemeyi sürdürsün, tamamlanmayı kanıt belirlesin

• Goals, Codex'in çalışma modelini değiştirerek thread'i izole prompt dizilerinden, tanımlı sonucun merkezde olduğu durum tabanlı bir iş döngüsüne dönüştürür
• Mimari bilerek sınırlandırılmıştır
  • Goal thread kapsamıyla sınırlıdır, yaşam döngüsü durumu ve bütçe takibi vardır; duraklatılabilir, sürdürülebilir, kaldırılabilir, tamamlanabilir veya bütçe nedeniyle durdurulabilir
  • Codex çalışmayı sürdürebilir ama yalnızca kullanıcının tanımladığı sözleşme içinde
• Bu özellik, Codex'in zaten en değerli olduğu debugging, optimizasyon, migrasyon, test ve araştırma işleri için kullanışlıdır
• Kullanıcı hedefi sağlar, Codex kanıtın izini sürer ve Goal bu ikisini, iş tamamlanana ya da dürüst biçimde bloke olana kadar birbirine bağlar
• Karmaşık araştırmalarda bu, cevap üretmek ile denetim (audit) üretmek arasındaki farkı ortaya koyar
• İyi bir Goal, Codex'ten sadece işi bitirmesini istemez; bitmiş olmanın ne anlama geldiğini öğretir

[hmmhmmhm]

/goal Öğle arası saat 12'ye kadar, daha önce yaptığım çalışmaları temel alarak yapılabilecek her şeyi kontrol edip ilerleyin. Saat 12'den önce çalışmayı durdurmamalısınız.