İnsanların %99'u /goal ve loop'ları yanlış kullanıyor.
Duydukları heyecan şu: "uzun süreli loop'lar ile otonom bir ajan çalıştırmak": bir göreve yönlendir, uzaklaş, geri geldiğinde çalışan kod bul.
Ancak üst düzey ajan mühendisleri bunu 6 aydır (GPT-5.2 ve Opus 4.5 çıktığında) /goal olmadan yapıyor. Buna harness mühendisliği + spec-driven geliştirme denir:
- ajanın sorunu gözlemlemesi için bir harness (koşum) oluştur
- tüm test senaryolarıyla sıkı bir spec (şartname) yaz
- Codex veya Claude Code'un tümünü karşılayana kadar gözetimsiz döngüye girmesine izin ver.
Bunları sürekli gece boyunca başlatırım — her çalıştırma 2-5 saat sürer. Nisan ayında bir tanesi Vercel monorepo'muzdaki bir Turbo derleme-önbellek hatasını çiğnedi ve sabaha kadar yeşile döndü. Aslında /goal gerekli değil.
Peki /goal aslında ne işe yarıyor?
İşte ben uzaktayken tek bir prompt'un yaptıkları:
- ~30 saat, 6.300 satır kod, 92k sayfa tarandı, API'ler için 40 dolar harcandı
- Başka bir ürünün temel döngüsünü klonla — tüm mimari sıfırdan tersine mühendislik ile çıkarıldı
- Bizim versiyonumuzun çıktısı aynı sorgularda referans üründen ~50 kat daha iyiydi. (Bu, newsjack.sh'e güç verecek yeni bir veri katmanıdır - üzerinde çalıştığım açık kaynaklı haber istihbarat becerileri)
Sır, kayıp fonksiyonu geliştirmedir (LFD): ajana bir spec'i oluşturması için değil, optimize etmesi için bir hedef yazarsınız.
Bu, Peter'ın tweet'inin somut bir örneğidir, işlevsel hale getirilmiştir.
Spec-driven geliştirmede kullanılan spec artık başlangıç noktası haline gelir, bitiş çizgisi değil.
Bunu doğru yapmak biraz deneme yanılma gerektirdi. Ama işte tüm oyun kitabı — ancak bu /goal'ları nasıl tasarlayacağınızı anlamanız için önce ne kadar kötü gittiğiyle başlamalıyız.
Ajan 3 kez hile yaptı.
Her şey her zaman yaptığımla başladı: bir spec ile.
Codex'i diğer ürünün herkese açık web sitesine yönelttim - "bunu kendimiz nasıl inşa edebiliriz?". 30 dakika içinde tam bir sistem tasarımı ve test senaryolarıyla geri döndü - spec.
Ama bu sefer farklı bir prompt denedim.
"/goal çıktın onlarınkiyle birebir eşleşene kadar uygula"
Ve işte olanlar:
Döngü 1 (5 dakika)
Ajan değerlendirme setini aldı, onu yansıtan tohum veriler üretti ve beş dakika içinde zafer ilan etti.
"%100" geri çağırma, sıfır genellik — yalnızca kendisine verdiğim 30 şeyi bulabilen bir arama motoru lol.
Düzeltme → onu kör et. Değerlendirme, çalıştırma sırasında gizli, yalnızca puanlamada açığa çıkar, öğe başına bir eksik listesiyle.
Döngü 2 (20 dakika) - kör, 30 öğe.
Ajanı değerlendirme setinden kör ettim, ancak bunun yerine eksiklerden öğrenmeye başladı — her "X'i bulamadın" bir sonraki döngüde bir anahtar kelime haline geldi. Birkaç döngü sonra: tam olarak 30 anahtar kelime kullandı, öğe başına bir tane ve yine "kazandı".
Düzeltme → değerlendirme setini genişlet. Karşı puanlanacak yüzlerce öğe, sıralanamayacak kadar çok.
Döngü 3 (30 dakika) - kör, 200 öğe.
Yeni değerlendirme setine 200 öğe ekledikten sonra ajan yine hile yaptı.
Komik bir şekilde, ajan yine de sıraladı. Anahtar kelime listesi yüzlerceye ulaştı, her terim bir sonraki eksik için kesin bir yemdi.
Üç tur, üç hile.
İşte o an anladım: ajan sadece optimize ediyordu.
Hile, ajandaki bir hata değildi. Bu benim hedefimdeki bir hataydı: ona nereye gideceğini söyledim ve her kısayolu açık bıraktım.
Kapatmadığınız her ucuz yol, optimize edicinin dörtnala gideceği bir yöndür. Ve benim ilk hedefim tüm çitleri atlamıştı.
Döngü 4 (30 saat) - kör, 200 öğe, katı sınırlar.
Bu yüzden yönleri engellemeye başladım. Anahtar kelime listesini sınırla, değerlendirmeyi kör et, tarihi genişlet — her düzeltme bir ucuz yolu daha kapattı, ta ki sayıyı hareket ettiren tek yön, görevde gerçekten daha iyi olmak kalana kadar.
Hile yapmayı bıraktı.
Sonra çalıştı. ~30 saat işlem, 92k sayfa tarandı, token'larda ~40 dolar, 6.300 satır kod.
Referans aldığımız ürünün tavan değil taban olduğu ortaya çıktı: aynı sorgularda ~50 kat daha fazla sonuç elde ettik.
(Merak edenler için tüm yolculuk ve makbuzlar burada)
Kayıp fonksiyonu geliştirme (LFD) - iyi bir kayıp fonksiyonunun anatomisi
Çoğu insan bir ürün oluşturmaya çalışırken, ajanları sıfırdan birkaç saat içinde piyasaya sürmek için kullanır.
Ancak asıl zorluk sonrasında gelir — uzun kuyruk. Spec'in asla hayal edemediği uç durumlar, her seferinde bir hata günlüğü olmak üzere yalnızca üretimde ortaya çıkar. Onları tek tek düzeltirsiniz. Günlüklerde yakalamadığınız durumlar kullanıcılar tarafından bildirilir, ki bu bir hatayı bulmanın en pahalı yoludur.
Bunun ucuz ucunu otomatikleştirdim. OpenClaw ajanım Zoe her gün hata günlüğünü izler ve yeni hatalar geldikçe Codex'i doğurur ve PR'lar oluşturur — bu döngü olabileceği kadar sıkı. (Tam kurulum burada belgelenmiştir)
Kuyruk hala aylar sürer. İyi bir ürün oluşturmak, işi ajanlar yapsa bile zaman almasının nedeni budur.
LFD kuyruğu hızlandırır. Gerçek beklenen çıktı örneklerini önceden alabilirseniz — iyinin neye benzediğini, ölçekte — sevkiyattan önce ıslatmayı çalıştırırsınız: yüzlerce uç durum, bir üç aylık hata raporu damlasıyla değil, tek bir optimizasyon çalıştırmasında ajana çarpar. Ve bu aniden mümkün hale gelmesinin nedeni, giderek daha fazla sorun için bu örneklerin herkese açık olarak durmasıdır.
Spec-driven geliştirme:
Bunu oluştur. Testleri geçir.
Kayıp fonksiyonu geliştirme:
Bunu oluştur. Testleri geçir. Ardından bu 1.000 değerlendirme vakasına karşı yinele.
Bir test paketi sonludur — yeşil olduğu an biter. %95'te 1.000 vakalık bir değerlendirme, aşağı doğru indiğiniz bir hedeftir; çıtayı geçmek dışında çıkış yoktur. Bu önemlidir çünkü ajan asla görmeyeceğiniz yüzlerce karar verir ve her biri bir şeye karşı çözülür. Hedefi yazmadıysanız, ajan bir tane seçer — ve 1-3. turların gösterdiği gibi, tatmin etmesi en ucuz olanı seçer.
Kayıp fonksiyonu değerlendirmeden daha büyüktür. 4 şeyi vardır - hedef, kısıtlamalar, enstrümanlar ve zorlanmış entropi. Dört parça.
1. Hedef
- Numaralandırmanın kâr etmeyeceği kadar büyük. 28 öğelik bir değerlendirme bir turda ezberlendi. Ne kadar çok o kadar iyi.
- Ajanı cevap anahtarına karşı kör et. Değerlendirme verileri yalnızca sonradan puanlama için vardır. Ajan çalıştırma sırasında cevapları görebiliyorsa, bakmanın bir yolunu bulacaktır.
2. Kısıtlamalar
Ajanın ne yapmasına izin verildiği ve neye izin verilmediği.
- Zaman, ajanın her zaman unutacağı kısıtlamadır. Ajanların zaman duygusu yoktur. Metrik nominal olarak hareket ettiği için %2'lik bir kazanç için 10 saat çalışırlar. Ancak 2 saatte %80'lik bir çözüm, 30 günde tamamlanan %100'lük bir çözümden daha iyidir. Çözüm: bir duvar saati bütçesi belirleyin.
- Para. Her ücretli çağrıda katı sınırlar: tarayıcı kredileri, LLM harcaması, tek kullanımlık bir anahtarda toplam dolar tavanı.
- Yüzey. Tüm sağlayıcılar, izin verilen modeller, eşzamanlılık tavanları. Ajanı yalnızca dokunmasını istediğiniz şeylerle sınırlandırın.
- Metodoloji. LLM analizine izin veriliyor mu, yoksa yalnızca deterministik mantık mı? Ajanın hangi veri kaynaklarına erişimi var? Açıkça belirtin.
3. Enstrümanlar (koşum takımı)
Enstrümanı olmayan bir kısıtlama bir histir — ajan onu neşeyle ihlal eder çünkü ihlal ettiğini söyleyemez. Yukarıdaki her kısıtlama için, ajanın onu incelemesi için bir CLI komutu gönderin.
- Hedef ölçümü, doğru çözünürlükte. Hedef enstrümanı dikkatlice seçin. Gerçek bir örnek: "bir LLM'nin iki ekran görüntüsünü derecelendirmesine" izin veren naif bir yargıç, 12 piksel boşluk hatası olan UI klonlarını onaylar, çünkü LLM'ler görüntüleri aslında göremez, onları gömülü hale dönüştürür ve ardından gömülüyü karşılaştırır. Bu nedenle piksel mükemmel UI klonları istiyorsanız, ajanınıza bir piksel farkı aracı verin. Ardından /goal ile piksel farkı 0 olana kadar devam edin.
- Zaman muhasebesi. Her çalıştırmayı ve her adımı zaman damgasıyla işaretleyin. Ajan her adımın ne kadar sürdüğünü, toplam duvar saati süresini bilmelidir. Zaman birinci sınıf bir enstrümandır, bir dipnot değil.
- Sağlayıcı bütçesi. "Şu anda tarayıcılarda ne kadar yakıyoruz?" bir tahmin değil, tek bir komut olmalıdır. Kalan kazıma kredilerini, bu döngüdeki yanmayı, kümülatif yanmayı ve bir sonraki ücretli parti öncesinde öngörülen yanmayı takip edin.
- LLM harcaması. Ajanın veri düzleminde kullanması için bir LLM API anahtarı vermek, mantığın çoğunu basitleştirebilir. Ancak ajan, aslında ne kadar harcadığını bilerek bunları sorumlu bir şekilde harcamalıdır.
- Codex Kullanımı. Bu biraz meta. Döngü kendinin farkında olmalıdır: bu optimizasyon için ne kadar token harcıyorum? Mevcut optimizasyon adımının gradyanını bilmek için faydalıdır.
Desen, eski sözdür: göremediğiniz şeyi optimize edemezsiniz.
Bu döngüleri çalıştırmada yeniyseniz, onu başlatıp gitmeyin. İlk döngüyle oturun. Neye dokunduğunu izleyin. Oluşturduğunuz koşum takımının gerçekten düzgün kullanıldığını onaylayın. Sonra yatın. (Ve neyle uyanacağınızı düşünmeden uyumaya çalışın)
4. Zorlanmış entropi
Zorlanmış entropinin neden önemli olduğu: her döngü, önceki çalışmanın tüm bağlamından devam eder. Model sıfırdan başlamıyor — kendi son yüz kararını ve şimdiye kadar işe yarayan gradyanı okuyor.
Bir /goal döngüsünde, yerel maksimuma ulaşmak varsayılan durumdur. Açık bir teşvik olmadan, ajan aynı tepeyi tırmanmaya devam eder ve "aynı tepe", gelişmeyi bıraktığı yerdir.
Örneğin, küçük bir düğme sonucu %0,1 iyileştiriyorsa, ajan deneyebileceği 1000 başka düğm olsa bile o düğmeyi çevirmeye devam edecektir.
Entropi, çalıştırmaya açıkça zorlanmalıdır, çünkü model bunu kendi başına yapmayacaktır:
- Her döngüde aşırı uyum yansıması. Daha genel bir çözüm mü oluşturuyorum, yoksa değerlendirmeyi mi ezberliyorum? Ezberliyorsa, bir sonraki değişiklik bir değerlendirme şekilli eser eklememeli, kaldırmalıdır (bir listeyi sınırla, bir özelliği kör et, değerlendirmeyi genişlet, bir tohumu reddet).
- Durma üzerinde zorlanmış entropi. Son döngü metrikte hareket ettirmediyse, bir sonraki "aynı fikir, daha sert" olamaz. Model gerçek, bariz olmayan bir sıçrama yapmalıdır — "kalıpların dışında düşünmek" iyi bir prompt'tur - ajanın aynı düğmeyi daha sert çevirmesini durdurur.
- Bir yineleme günlüğü tutun. Ajanın hipotezi, beklenen başarısızlık modunu, her adımdaki teşhisi kaydetmesini sağlayın, böylece sıkıştırmalar arasında geriye bakıp yansıtabilir.
Meta-Meta-Prompt
Bu hedefleri kendim yazıyordum, sonra hızlıca bunun da ajanlar için bir iş olduğunu öğrendim.
Bu yüzden, iyi bir kayıp fonksiyonu geliştirme çalıştırması için bu tür hedefler üreten bir beceri yazdım.
Şimdi burada açık kaynak olarak yayınlandı:
https://github.com/elvisun/loss-function-development
Koşum takımını ve hedefi oluşturmak için /lfd-design
En aşağıya kadar gradyan inişi: iki döngü
Geri çekilin ve en aşağıya kadar gradyan inişidir.
İç döngü ajandır: kod yaz, testleri çalıştır, düzelt. Kısa ufuk, hızlı geri bildirim, tek hedef — testleri geçir. Bu bir geliştiricinin iç döngüsüdür ve spec-driven geliştirme bunu çalıştırma şeklinizdir. Kodlama ajanları bunu zaten otomatikleştirdi.
Dış döngü /goal'dur: tüm sistemi birçok döngü boyunca bir sonuç metriğine doğru sürün — sevk et, ölç, rotayı değiştir, aşağı in. Uzun ufuk, seyrek geri bildirim. Bu geleneksel olarak bir ürün ekibinin döngüsüdür, aylar süren sevk et-ölç-tekrarla ıslatması, tek bir çalıştırmaya sıkıştırılmıştır.
Her iki döngü de artık otomatikleştirildi. Size kalan şey, kayıp fonksiyonunu tanımlamaktır — /goal tam olarak neyi optimize etmeli ve hangi şekilde.
Bir ürünü damıtıyorsunuz — veya herkese açık bir eser bırakan herhangi bir şeyi
Başka bir mercek: bu aslında damıtma işlemidir, eğitim zamanından prompt zamanına taşınmıştır. DeepSeek, Kimi, Minimax hattının GPT ve Claude'a olan farkın çoğunu kapatmasının yolu budur — modelinizi başkalarının çıktıları üzerinde, sizinki onlarınkini yeniden üretene kadar eğitin.
Ancak bir modeli damıtmak yerine, artık /goal ve LFD'yi kullanarak herkese açık olarak bulunabilen herhangi bir esere uyacak şekilde damıtma çalıştırabilirsiniz — iç yapıları asla incelemez ve buna gerek yoktur.
Herkese açık kelimesine dikkat edin. Birinin Hizmet Koşulları'na tabi, giriş duvarlı veya ücretli çıktısını damıtmak adil değildir. Ancak açıkta yayınlananlar — bir şirketin müşteri kazanmak için sevk ettiği çıktılar — her zaman öğrenmek için adil olmuştur. Bu kısım yeni değil — yazılımdaki en eski harekettir. Yeni olan, artık ucuz olması ve aylar yerine saatler içinde yapılabilmesidir.
Geri çekilin ve işte daha büyük değişim. Bilgi simetrisinin olduğu her yerde yürütme maliyeti ~0 dolara düşer — çıktılar herkese açık olduğunda, herkes iyinin neye benzediğini görebilir, bu nedenle herkes onu bir hafta sonu 40 dolara geri damıtabilir.
İşte giderek değerlenen yeni bir hendek: bilgi asimetrisi.
Kurallara uygun açık kaynak şirketi zaten göz kırptı. Nisan 2026'da cal.com (5 milyon dolar YYY) üretim kodunu özel hale getirdi ve açık kaynağı kapattı. Verdikleri neden tam anlamıyla bu makalenin özeti gibi okuyor: AI odaklı güvenlik tehditleri çağında, kaynağınızı bir ajanın okuyabileceği bir yerde bırakamazsınız.
"/goal [cal.com](https://cal.com/) kaynak kodunu oku ve bir şey işe yarayana kadar saldırı yüzeyini sırala"
Bu, uygulaması çok kolay olan çok tehlikeli bir saldırı.
Tüm kimliği "açık kaynak" olan şirket, 2026'da açıklığın bir yükümlülük haline geldiğine karar verdi. Bu size her şeyi anlatmalıdır.
Yazılım tarihi boyunca, "biz inşa ettik" hendekti.
Bu çağ kapanıyor.
Bir sonraki, eserin asla içermediği şeye sahip olana ait: başka hiç kimsenin puanlayamayacağı değerlendirme seti. Kullanıcılarınızın gerçekten takıldığı uç durumların listesi. Özel olarak ölçtüğünüz temel gerçek. Rakibin ajanının göremediği hedefe sahip olan, döngüsü inmeye devam eden tek kişidir.
Ürün artık bir hafta sonu.
Git, bir hafta sonunun dokunamayacağı değerlendirmeyi oluştur.
