/goal Komutu: Codex ve Claude Kodunu 7/24 Otonom Ajanlar Olarak Çalıştırma

Son altı hafta içinde her büyük yapay zeka laboratuvarı aynı temel özelliği piyasaya sürdü. Anthropic, Claude Code'a /goal ekledi. OpenAI bunu Codex CLI ve Codex masaüstü uygulamasına dahil etti. Nous Research ise Hermes'e entegre etti. İsimlendirme bilerek tutarlıdır; bu, sektörün tek bir şey için ortak bir arayüz üzerinde anlaşmasıdır: ölçülebilir bir son duruma ulaşana kadar kapalı döngüde çalışan ve her adımda sizden izin istemeyen bir aracı.

Eğer manuel olarak “onayla, istem gönder, aracıya devam etmesini söyle, tekrarla” döngüsünü yapıyorsanız, /goal bu duruma son veren eğik çizgi komutudur. Aracıyı bir hedefe yönlendirirsiniz, o hedef üzerinde çalışır ve hedefe ulaşıldığında geri döner.

Bu rehber geliştiriciler ve API geliştiricileri içindir. /goal'ın perde arkasında ne yaptığını, bunu Codex ve Claude Code'da nasıl kuracağınızı, sonsuz döngüler yerine gerçek sonuçlar üreten bir istem yapısını ve tüm bunları Apidog kullanarak API iş akışınıza nasıl entegre edeceğinizi ele alacağız.

Rehberin ilerleyen kısımlarındaki API örneklerini takip etmek isterseniz, Apidog'u ücretsiz indirin.

/goal aslında ne yapar

Tek cümleyle: /goal, bir yapay zeka aracısının, onay için size geri dönmeye gerek kalmadan, bir durma koşulu tetiklenene kadar bir görev üzerinde döngü yapmasını sağlar.

Alttaki mekanik basittir. Ana aracının attığı her adımdan sonra küçük, hızlı bir doğrulayıcı model çalışır ve tek bir soruyu yanıtlar: “Hedefe ulaşıldı mı?” Hayır ise, ana model çalışmaya devam eder. Evet ise, döngü kapanır ve aracı geri bildirimde bulunur. Bu, 2026'nın başlarında “Ralph döngüsü”nün popülerleştirdiği aynı modeldir, ancak şimdi resmi araçların içinde birinci sınıf bir komut olarak gelmektedir.

Normal aracı kullanımındaki fark:

• /goal olmadan: döngü sizsiniz. Çıktıyı okur, doğru olup olmadığına karar verir, bir sonraki adımı tetikler, bir araç çağrısını onaylar ve benzeri. Her yineleme size dikkat maliyeti getirir.
• /goal ile: döngü aracıya aittir. Planlar, yürütür, kendi kendini doğrular ve yalnızca tamamlandığında, bir kısıtlamaya takıldığında veya bütçesi tükendiğinde ortaya çıkar.

Somut bir örnek: Claude Code'a /goal create a landing page demek, araştırma, altyapı oluşturma, stil belirleme, hata ayıklama ve son bir önizlemeyi tek bir sürekli çalıştırmada tetikler. Uzaklaşıp geri geldiğinizde, ya ürünü piyasaya sürersiniz ya da üzerinde değişiklik yapmaya devam edersiniz.

Neden bu aniden her yerde

Şu anda /goal'ın satıcılar arasında piyasaya sürülmesinin nedeni, uzun vadeli aracı görevlerinin iki öngörülebilir şekilde başarısız olmasıydı:

1. Kayma (Drift). Orijinal hedefe karşı kontrol eden bir doğrulayıcı olmadan, modeller sapıp kendine güvenli ama yanlış çıktılar üretebilirdi.
2. Sürekli gözetim (Babysitting). Model işi yapabilse bile, kullanıcıların her yinelemeyi denetlemesi gerekiyordu ki bu da bir aracının amacını boşa çıkarıyordu.

İkinci bir doğrulayıcı model her ikisini de düzeltir. Ucuzdur (küçük model, dar istem) ve döngüye kesin bir durma koşulu verir. Tüm numara budur. Laboratuvarlar bu modelin işe yaradığını fark ettiğinde, haftalar içinde hepsi aynı ad altında piyasaya sürdü.

Codex'te /goal kurulumu

Codex CLI size en fazla kontrolü sağlar. İşte minimum kurulum:

1. Masaüstü uygulamasında hedefleri etkinleştirin: Codex masaüstünü açın, Ayarlar → Yapılandırma'ya gidin ve goals = true olarak ayarlayın. CLI bunu devralır.
2. CLI'ı tam otomatik modda başlatın böylece onay istemlerini görmeyi bırakırsınız:

codex --approval-mode full-auto

3. Bir hedef belirleyin:

/goal [hedefiniz buraya]

Hepsi bu kadar. Codex, hedefin kaydedildiğine dair bir onay yazdıracak ve ardından çalışmaya başlayacaktır.

Eğer teknik bir kullanıcı değilseniz, CLI yerine Codex masaüstü uygulamasında başlayın. İşlevsellik aynıdır, ancak duraklatma, temizleme ve token kullanımını izleme için bir kullanıcı arayüzü (UI) elde edersiniz.

Claude Code'da /goal kurulumu

Claude Code CLI neredeyse aynı şekilde çalışır. CLI'ı başlatın, /goal yazın ve ardından görev açıklamasını ekleyin. Resmi belgeler Claude Code dokümantasyon sitesinde bulunmaktadır.

Claude Code'u başlatırken kurulum veya yapılandırma hatalarıyla karşılaşırsanız, geçersiz custom3p kurumsal yapılandırma düzeltmesi en yaygın hata modunu kapsar. /goal ile çoklu aracı iş akışlarıyla Claude Code'u nasıl yöneteceğinize dair daha derinlemesine bir bakış için, Claude Code üzerinde çoklu aracı katmanı olan Ruflo'nun detaylı analizimize bakın.

Gözden kaçırılması kolay bir ipucu: /goal, Claude Code içinde çalışan görev için canlı token sayısını ve bir ilerleme çubuğunu gösterir. Sadece çıktıyı değil, token sayısını da izleyin. İlerleme olmadan token yakan bir hedef, doğrulayıcının yakınsama konusunda başarısız olduğunun bir işaretidir ve bu durumda /pause veya /goal clear tuşlarına basmalısınız.

Gerçekten işe yarayan istem yapısı

/goal için sözdizimi basittir. Zor kısım, iki saat boyunca çalışan ve size ince bir şekilde yanlış bir şey veren bir aracı yerine, kullanılabilir bir sonuç üreten bir istem yazmaktır.

Her etkili /goal isteminin üç bileşeni vardır:

1. İş: ne yapılmasını istediğiniz, tek bir satırda.
2. Ölçülebilir son durum: “tamamlandı” neye benziyor, doğrulayıcının kontrol edebileceği bir biçimde.
3. Kısıtlamalar: tüm süreç boyunca geçerli olması gereken kurallar.

İskelet:

/goal [işi yap] [ölçülebilir son duruma] kadar [geçerli olması gereken kısıtlamalar] olmadan

Bir kodlama görevi için gerçek bir örnek:

/goal tüm başarısız testleri düzelt ta ki npm test 0 ile çıkana kadar /auth dizini dışındaki hiçbir dosyayı değiştirmeden

Son durum doğrulanabilir (npm test çıkış kodu) ve kısıtlama, doğrulayıcının her yinelemede uygulayabileceği katı bir sınırdır. Doğrulayıcı test komutunu çalıştırdığı için aracı tamamlanmayı taklit edemez.

Belirsiz görevler için (“bu UI'ın modern hissetmesini sağla”), /goal kötü performans gösterir çünkü son durum ölçülebilir değildir. Ya hedefi ölçülebilir olacak şekilde yeniden yazın (“Lighthouse erişilebilirlik puanı 90+ olana kadar”), ya da normal bir istemle devam edin.

Daha uzun görevler için gelişmiş yapı

Daha büyük hedefler için, iskeleti dört bloğa genişletin:

/goal
Hedef: [tek satırlık hedef]
Başarı kriterleri:
  - [ölçülebilir kriter 1]
  - [ölçülebilir kriter 2]
Kısıtlamalar:
  - [sınır 1]
  - [sınır 2]
Bağlam:
  - [aracının bilmesi gereken dosyalar, depolar, API anahtarları]

Bu format, doğrulayıcıya her döngü yinelemesinde kontrol edilecek somut şeyler verir. Başarı kriterleri olmadan, doğrulayıcı bulanık bir semantik eşleşmeye geri döner ki kayma buradan kaynaklanır.

Çalmaya değer örnekler

/goal sadece kod yazmak için değildir. İyi çalışan birkaç örnek:

Araştırma

/goal Nisan 2026'dan bu yana yayınlanan Claude Opus 4.7 için her genel karşılaştırmayı topla, kaynakları kaydet ve tablo en az 10 farklı karşılaştırmayı kapsayana kadar tarihe göre sıralanmış bir markdown tablosu oluştur

Depo bakımı

/goal bu depoda ölü kod, kullanılmayan bağımlılıklar ve eski dosyalar bul, ardından her bir öğenin bir gerekçesi olana kadar güvenli kaldırmaları listeleyen bir PR açıklaması öner

Dokümantasyon

/goal README.md'yi yeni bir katılımcının projeyi kurabilmesi, çalıştırabilmesi, test edebilmesi ve anlayabilmesi için yeniden yaz, ta ki bu dört adımın her birinin çalışan bir komutu ve beklenen bir çıktısı olana kadar

Özellik geliştirme

/goal koyu/açık tema geçişi ekle, seçimi localStorage'da kalıcı hale getir, her iki tema için stilleri güncelle ve geçiş sayfa yenilemesi olmadan çalışıp yenilemeye dayandığında tarayıcıda doğrula

Ortak desen: her örnek doğrulanabilir bir son durumu belirler. Bu, biten bir hedef ile döngülerde çalışan bir hedef arasındaki çizgidir.

/goal'ı API geliştirme iş akışlarıyla eşleştirme

/goal'ın şu ana kadarki çoğu kapsamı genel kodlama görevleriyle ilgiliydi. Arka uç ve platform mühendisleri için daha ilginç kullanım durumu, son durumun neredeyse her zaman test edilebilir olduğu API çalışmalarıdır.

API uç noktaları /goal için mükemmeldir çünkü “tamamlandı” durumu belirsiz değildir: istek 200 döner, yanıt şeması eşleşir ve sözleşme belgelenmiştir. “Bu uç noktanın testlerini geçmesini sağla” diyen bir hedef yazabilirsiniz ve doğrulayıcının okuyabileceği somut bir sinyal olur.

Uygulamada geçerli olan bir iş akışı:

1. Sözleşmeyi önce Apidog'da tasarlayın. Uç noktayı, istek şemasını, yanıt şemasını ve örnek yükleri Apidog içinde tanımlayın. Bu, doğruluk kaynağı haline gelir.
2. Spesifikasyonu dışa aktarın. Apidog, Codex veya Claude Code'a bağlam olarak vereceğiniz OpenAPI 3.x'i dışa aktarır.
3. /goal'ı çalıştırın. Aracıya şunu söyleyin: “Her Apidog test durumu geçene kadar uç noktayı uygula.”
4. Doğrulayıcı test çalıştırıcısını kontrol eder. Her döngü yinelemesinde, doğrulayıcı çalışan servise karşı Apidog CLI testlerini çalıştırır. Aracı ancak her durum yeşil olduğunda tamamlanır.

Bu, aracının kendi testlerini icat etmesine izin vermekten maddi olarak daha iyidir, çünkü sözleşme zaten kilitlenmiştir. Aracı, spesifikasyonun kapsadığı uç durumları gözden kaçıran başarılı bir test paketi gönderemez.

Apidog'u daha önce kullanmadıysanız, API platformu tasarım, sahte hizmet oluşturma (mocking), test etme ve dokümantasyonu tek bir araçta birleştirir; bu burada önemlidir çünkü /goal, doğrulayıcının durumu kontrol etmek için yalnızca tek bir komut çalıştırması gerektiğinde en iyi şekilde çalışır. Tasarım odaklı API iş akışı rehberimiz, sözleşme odaklı kurulumu ayrıntılı olarak ele alır ve QA mühendisleri için API test aracı genel bakışı, aracının yineleyeceği test durumlarını nasıl yapılandıracağınızı gösterir.

Eğer MCP sunucularıyla (çoğu yapay zeka kodlama aracının artık harici araçları çağırmak için kullandığı protokol) çalışıyorsanız, aynı desen geçerlidir. /goal aracılarının yerel MCP sunucunuza karşı güvenli bir şekilde çalışmasını sağlayan kurulum için Apidog ile MCP sunucusu testi makalesine bakın.

/goal'ı üretimde çalıştırmaktan elde edilen profesyonel ipuçları

/goal'ı gerçek işlerde çalıştırdıktan sonra öğrendiğiniz birkaç şey:

• Tek seferde bir hedef. Hem Codex hem de Claude Code sizi tek bir aktif hedefle sınırlar. Bunları biriktirmeye çalışmak garip durumlara yol açar. Çalıştırmalar arasında /goal clear kullanın.
• /plan ile eşleştirin. Yararlı bir iş akışı, önce /plan yapmak, planı gözden geçirmek ve ardından planı bağlam olarak kullanarak /goal çalıştırmaktır. Bu, yineleme sayısını yarıya indirir çünkü aracı döngü ortasında yaklaşımı yeniden tasarlamaz.
• Markdown dosyalarını taslak olarak kullanın. Ajan'a bir progress.md dosyasını sürdürmesini söyleyin. Okunabilir bir denetim izi elde edersiniz ve aracı, yinelemeler arasında kalıcı bir bağlama sahip olur.
• Modelin kendi hedefini yazmasına izin verin. Kaba fikrinizi normal bir istem içine bırakın ve modelden bunu başarı kriterleri ile bir /goal çağrısına dönüştürmesini isteyin. Model, doğrulayıcının gerçekten neyi kontrol edebileceğini bildiği için sizden daha iyi hedef istemleri yazar.
• Ana modeli değil, doğrulayıcıyı izleyin. Eğer döngü kapanmıyorsa, sorun neredeyse her zaman başarı kriterlerinin ölçülemez olmasıdır. Kriterleri sıkılaştırın, aynı hedefi tekrar denemeyin.
• /goal uzun vadeli işler içindir. Tek satırlık bir yeniden düzenleme için normal bir istem daha hızlıdır. Otonom döngünün bir ek yükü vardır.

/goal ne zaman sizi yarı yolda bırakır

Akılda tutulması gereken dürüst sınırlamalar:

• Maliyet. Bir saat boyunca çalışan bir döngü, aynı görevin manuel olarak yapılmasından daha fazla token tüketir. Bir bütçe belirleyin.
• Sinyali olmayan görevler. Kullanıcı deneyimi iyileştirmesi (UX polish), metin tonu (prose tone), tasarım zevki (design taste); bunların hiçbirinin net bir doğrulayıcısı yoktur. Aracı ya pes edecek ya da sahte bir durma koşulu icat edecektir.
• Harici yan etkiler. E-posta göndermeyi, ödeme yapmayı veya üretim API'lerini çağırmayı içeren bir hedef, katı kısıtlamalar gerektirir. Aracı kendi başına dikkatli olmayı çıkarmaz. API'lerinizi çağıran yapay zeka aracıları etrafında erişim kontrolü oluşturmaya devam ediyorsanız, ekipler için GitHub Copilot kullanım ve faturalandırma API'si yazımız, büyük satıcıların bunu nasıl ele aldığını kapsar.
• Eski bağlam. Uzun süren hedefler, kod tabanı döngü ortasında değişirse orijinal spesifikasyondan sapabilir. Eski bağlama karşı devam etmesine izin vermek yerine duraklatın ve sıfırlayın.

Yapay zeka ile nasıl inşa ettiğiniz için bunun anlamı

/goal, “otomatik tamamlama olarak yapay zeka”dan “brifing verdiğiniz ve kontrol ettiğiniz bir işçi olarak yapay zeka”ya geçiştir. Arayüz değişikliği küçük olsa da (tek bir eğik çizgi komutu), etkisi büyüktür: bir geliştirici olarak yaptığınız iş, daha iyi başarı kriterleri ve kısıtlamalar yazmaya doğru kayar ve gerçek kod satırlarını yazmaktan uzaklaşır.

Bundan en çok faydalanan ekipler, halihazırda test edilebilir sözleşmelere, güçlü sürekli entegrasyona (CI) ve net spesifikasyonlara sahip olanlardır. Eğer API'nizin tanımlanmış bir OpenAPI belgesi ve bir test paketi varsa, bir /goal aracısına bir uç nokta ve bir son tarih verebilirsiniz. Eğer API'niz sadece birinin kafasında mevcutsa, aracının doğrulaması gereken hiçbir şey olmaz ve döngü çöker.

Burası, API platformlarının yapay zeka iş akışları için taşıyıcı altyapı haline geldiği noktadır. Apidog, tasarım odaklı API geliştirme etrafında inşa edilmiştir ve bu, uygulamayı yapan aracının spesifikasyonunuzu okuyup kendi çalışmasını test durumlarınıza göre kontrol edebildiğinde çok daha faydalı hale gelir. Yukarıda açıklanan sözleşme odaklı iş akışını kurmak isterseniz Apidog'u indirin.

Sıkça Sorulan Sorular

/goal Codex web uygulamasında çalışır mı? Evet. Codex CLI, Codex masaüstü, Codex uygulaması ve Claude Code CLI'da çalışır. Hermes de aynı komutu destekler. Satıcılar arasında özellik eşitliği esastır.

/goal normal bir istemden nasıl farklıdır? Normal bir istem tek bir adım çalışır ve durur. /goal, her adımdan sonra durma koşulunu kontrol eden bir doğrulayıcı modelle kapalı bir döngüde çalışır. Ne zaman duracağına siz değil, aracı karar verir.

Aracı, belirlediğim kısıtlamaların dışına çıkabilir mi? Doğrulayıcı, her yinelemede kısıtlamaları uygular, bu nedenle aracının bunları ihlal etmemesi gerekir. Pratikte, kısıtlama ifadesi ne kadar gevşek olursa, aracının onu yorumlaması için o kadar fazla alan olur. Açık olun: “/auth dışındaki hiçbir dosyayı değiştirmeden” uygulanabilir; “hiçbir şeyi bozmadan” ise uygulanamaz.

/goal normal bir Claude veya Codex oturumundan daha pahalıya mal olur mu? Evet. Daha fazla token harcamayı bekleyin. Doğrulayıcı daha ucuz, daha küçük bir model üzerinde çalışır, ancak ana model hala işi yapıyor ve bunu daha özerk bir şekilde yapıyor. Bir bütçe belirleyin veya harcamayı kontrol etmek için /pause kullanın.

Aracının çıktısını gerçek bir API'ye karşı test etmek istersem ne olur? API sözleşmesini kilitlemek ve uygulamaya karşı gerçek test durumlarını çalıştırmak için Apidog gibi bir araç kullanın. Aracının doğrulayıcısı Apidog CLI'yı çağırabilir, bu da size ölçülebilir bir son durum sağlar. Kısıtlı bir bütçeyle Claude destekli bir hizmet kuruyorsanız, ücretsiz Claude API rehberine bakın.