99% लोग /goal और लूप्स का गलत इस्तेमाल कर रहे हैं।
वे जो हाइप सुनते हैं वह है "लंबे समय तक चलने वाले लूप्स जो एक स्वायत्त एजेंट को प्रेरित करते हैं": इसे किसी कार्य पर लगाओ, दूर चले जाओ, और वापस आओ तो काम करता कोड मिले।
लेकिन टॉप एजेंटिक इंजीनियर पिछले 6 महीनों से (जब GPT-5.2 और Opus 4.5 आए थे) बिना /goal के भी ऐसा कर रहे हैं। इसे हार्नेस इंजीनियरिंग + स्पेक-ड्रिवन डेवलपमेंट कहते हैं:
- एजेंट के लिए समस्या को देखने हेतु एक हार्नेस बनाएं
- सभी टेस्ट केस के साथ एक सटीक स्पेक लिखें
- कोडेक्स या क्लॉड कोड को बिना निगरानी के तब तक लूप करने दें जब तक वह सभी को पूरा न कर ले।
मैं इन्हें लगातार रात भर चलाता हूं — एक रन में 2-5 घंटे। अप्रैल में एक ने हमारे Vercel मोनोरेपो में Turbo बिल्ड-कैश बग को चबाया और सुबह तक उसे हरा कर दिया। वास्तव में किसी /goal की आवश्यकता नहीं है।
तो वास्तव में /goal किसके लिए है?
यहाँ वह है जो एक single prompt ने तब किया जब मैं दूर था:
- ~30 घंटे, 6,300 लाइनें कोड, 92k पेज क्रॉल किए गए, APIs पर $40 खर्च
- किसी दूसरे उत्पाद के कोर लूप को क्लोन करना — पूरी आर्किटेक्चर को शुरू से रिवर्स-इंजीनियर किया गया
- हमारे वर्शन का आउटपुट समान क्वेरीज़ पर रेफरेंस उत्पाद से ~50× बेहतर था। (यह एक नया डेटा लेयर है जो newsjack.sh को पावर देगा - ओपन-सोर्स न्यूज़-इंटेल स्किल्स जिस पर मैं काम कर रहा हूं)
रहस्य है लॉस फंक्शन डेवलपमेंट (LFD): आप एजेंट को एक लक्ष्य लिखते हैं जिसे ऑप्टिमाइज़ करना है, कोई स्पेक नहीं जिसे बनाना है।
यह पीटर के ट्वीट का एक ठोस उदाहरण है, जिसे ऑपरेशनलाइज़ किया गया।
स्पेक-ड्रिवन डेवलपमेंट में इस्तेमाल किया गया स्पेक अब शुरुआती बिंदु बन जाता है, फिनिश लाइन नहीं।
इसे सही करने में मुझे कुछ प्रयोग करने पड़े। लेकिन यहाँ पूरी प्लेबुक है — लेकिन हमें पहले यह समझना होगा कि यह कितना बुरा हुआ ताकि आप समझ सकें कि इन /goals को कैसे डिज़ाइन करना है।
एजेंट ने 3 बार धोखा दिया।
सब कुछ वहीं से शुरू हुआ जो मैं हमेशा करता हूं: एक स्पेक।
मैंने बस कोडेक्स को दूसरे उत्पाद की पब्लिक वेबसाइट पर पॉइंट किया - "हम इसे खुद कैसे बना सकते हैं?" 30 मिनट में यह एक पूर्ण सिस्टम डिज़ाइन और टेस्ट केस के साथ वापस आया - स्पेक।
लेकिन इस बार, मैंने एक अलग प्रॉम्प्ट आज़माया।
"/goal implement until your output matches theirs exactly"
और यहाँ क्या हुआ:
लूप 1 (5 मिनट)
एजेंट ने eval सेट पकड़ा, उसी के जैसा सीड डेटा जेनरेट किया, और पांच मिनट में जीत का ऐलान कर दिया।
"100%" रिकॉल, शून्य जनरैलिटी — एक सर्च इंजन जो केवल 30 चीज़ें ढूंढ सकता था जो मैंने इसे दी थीं lol।
फिक्स → इसे अंधा करो। रन के दौरान eval को छिपाएं, केवल स्कोरिंग के समय दिखाएं, प्रति आइटम मिस लिस्ट के साथ।
लूप 2 (20 मिनट) - अंधा, 30 आइटम।
मैंने एजेंट को eval सेट से अंधा कर दिया, लेकिन यह मिस से सीखने लगा — हर "आपको X नहीं मिला" अगले साइकिल में एक कीवर्ड बन गया। कुछ लूप में: इसने ठीक 30 कीवर्ड का उपयोग किया, प्रति आइटम एक, और यह फिर से "जीत" गया।
फिक्स → eval सेट को चौड़ा करो। सैकड़ों आइटम स्कोर करने के लिए, गिनने के लिए बहुत अधिक।
लूप 3 (30 मिनट) - अंधा, 200 आइटम।
नए eval सेट में 200 आइटम जोड़ने के बाद, एजेंट ने फिर से धोखा दिया।
मज़ेदार बात यह है कि एजेंट ने फिर भी गिन लिया। कीवर्ड लिस्ट सैकड़ों तक बढ़ गई, प्रत्येक शब्द अगली मिस के लिए एक सटीक लालच था।
तीन राउंड, तीन धोखे।
तब मुझे समझ में आया: एजेंड बस ऑप्टिमाइज़ कर रहा था।
धोखा देना एजेंट में कोई बग नहीं था। यह मेरे लक्ष्य में एक बग था: मैंने इसे बताया कि कहाँ जाना है और हर शॉर्टकट खुला छोड़ दिया।
हर सस्ता रास्ता जिसे आप बंद नहीं करते, वह एक दिशा है जिस पर ऑप्टिमाइज़र दौड़ेगा। और मेरे शुरुआती लक्ष्य ने सभी बाड़ों को छोड़ दिया था।
लूप 4 (30 घंटे) - अंधा, 200 आइटम, कठोर सीमाएं।
इसलिए मैंने दिशाओं को ब्लॉक करना शुरू किया। कीवर्ड लिस्ट को सीमित करें, eval को अंधा करें, डेट को चौड़ा करें — प्रत्येक फिक्स ने एक और सस्ता रास्ता बंद किया, जब तक कि केवल एक ही दिशा बची जो नंबर को आगे बढ़ाती थी वह थी कार्य में वास्तव में बेहतर होना।
इसने धोखा देना बंद कर दिया।
फिर यह चला। ~30 घंटे की कंप्यूट, 92k पेज क्रॉल, ~$40 टोकन में, 6,300 लाइनें कोड।
पता चला कि जिस उत्पाद को हम रेफरेंस कर रहे थे वह फर्श था, छत नहीं: हम समान क्वेरीज़ पर ~50× परिणाम सतह पर लाने में समाप्त हुए।
(उत्सुक लोगों के लिए पूरी यात्रा और रसीदें यहाँ)
लॉस फंक्शन डेवलपमेंट (LFD) - एक अच्छे लॉस फंक्शन की शारीरिक रचना
जब अधिकांश लोग कोई उत्पाद बनाने की कोशिश करते हैं, तो वे एजेंट्स का उपयोग कुछ घंटों में शून्य से शिप्ड तक जाने के लिए करते हैं।
लेकिन पकड़ यह है कि इसके बाद क्या आता है — लंबी पूंछ। ऐसे एज कभी जिनकी स्पेक ने कभी कल्पना नहीं की थी, केवल प्रोडक्शन में एक समय में एक एरर लॉग के साथ सतह पर आते हैं। आप उन्हें एक-एक करके ठीक करते हैं। जो मामले आप लॉग में नहीं पकड़ते, उन्हें उपयोगकर्ता रिपोर्ट करते हैं, जो एक बग खोजने का सबसे महंगा तरीका है।
मैंने इसके सस्ते सिरे को ऑटोमेटेड किया है। मेरा OpenClaw एजेंट Zoe हर दिन एरर लॉग देखता है और नई एरर आने पर Codex को स्पॉन करता है और PRs बनाता है — यह लूप जितना टाइट हो सकता है, उतना है। (पूरा सेटअप यहाँ डॉक्यूमेंटेड है)
लंबी पूंछ में अभी भी महीने लगते हैं। यही कारण है कि एजेंट्स के काम करने पर भी एक अच्छा उत्पाद बनाने में अभी भी समय लगता है।
LFD लंबी पूंछ को फास्ट-फॉरवर्ड करता है। यदि आप शुरू में ही वास्तविक अपेक्षित-आउटपुट उदाहरण प्राप्त कर सकते हैं — अच्छा कैसा दिखता है, पैमाने पर — तो आप शिप करने से पहले सोक चलाते हैं: एक ऑप्टिमाइज़ेशन रन में सैकड़ों एज केस एजेंट से टकराते हैं, बग रिपोर्ट के एक तिमाही ड्रिप में नहीं। और यह अचानक संभव होने का कारण यह है कि अधिक से अधिक समस्याओं के लिए, वे उदाहरण बस सार्वजनिक रूप से बैठे होते हैं।
स्पेक-ड्रिवन डेवलपमेंट:
इसे बनाओ। टेस्ट पास करो।
लॉस-फंक्शन डेवलपमेंट:
इसे बनाओ। टेस्ट पास करो। फिर इन 1,000 eval मामलों के खिलाफ पुनरावृत्ति करो।
एक टेस्ट सूट सीमित है — जैसे ही हरा होता है, समाप्त। 95% पर 1,000-मामले का eval एक लक्ष्य है जिसकी ओर आप उतरते हैं; बार के अलावा कोई निकास नहीं है। यह मायने रखता है क्योंकि एजेंट सैकड़ों निर्णय लेता है जो आप कभी नहीं देखेंगे, और हर एक किसी न किसी चीज़ के लिए हल करता है। यदि आपने लक्ष्य नहीं लिखा, तो एजेंट एक चुनता है — और जैसा कि राउंड 1-3 ने दिखाया, यह वही चुनता है जो संतुष्ट करने में सबसे सस्ता हो।
लॉस-फंक्शन eval से बड़ा है। इसमें 4 चीज़ें हैं - लक्ष्य, बाधाएं, उपकरण, और मजबूर एंट्रॉपी। चार टुकड़े।
1. लक्ष्य
- इतना बड़ा कि गिनती काम न आए। 28-आइटम का eval एक राउंड में याद हो गया। जितना अधिक, उतना बेहतर।
- एजेंट को उत्तर कुंजी से अंधा करें। eval डेटा केवल पोस्ट-हॉक स्कोरिंग के लिए मौजूद है। यदि एजेंट रन के दौरान उत्तर देख सकता है, तो यह देखने का कोई रास्ता खोज लेगा।
2. बाधाएं
एजेंट को क्या करने की अनुमति है, और क्या नहीं।
- समय वह बाधा है जिसे एजेंट हमेशा भूलता है। एजेंट्स को समय का कोई अहसास नहीं होता। वे 2% लाभ के लिए 10 घंटे तक पीसते रहेंगे क्योंकि मीट्रिक नाममात्र रूप से बढ़ रहा है। लेकिन 2 घंटे में 80% समाधान 30 दिनों में पूर्ण 100% से बेहतर है। समाधान: एक वॉल-क्लॉक बजट सेट करें।
- पैसा। हर भुगतान वाली कॉल पर कठोर सीमाएं: क्रॉलर क्रेडिट, LLM खर्च, डिस्पोजेबल कुंजी पर कुल डॉलर सीलिंग।
- सतह। सभी प्रदाता, स्वीकृत मॉडल, समवर्ती सीमाएं। एजेंट को केवल उन चीज़ों तक सीमित करें जिन्हें आप इसे छूना चाहते हैं।
- पद्धति। क्या LLM विश्लेषण की अनुमति है, या केवल नियतात्मक तर्क? एजेंट के पास कौन से डेटा स्रोतों तक पहुंच है? इसे स्पष्ट करें।
3. उपकरण (हार्नेस)
एक उपकरण के बिना एक बाधा सिर्फ एक भावना है — एजेंट खुशी से इसका उल्लंघन करेगा क्योंकि यह बता नहीं सकता कि यह उल्लंघन कर रहा है। ऊपर दी गई हर बाधा के लिए, एजेंट के निरीक्षण के लिए एक CLI कमांड शिप करें।
- लक्ष्य माप, सही रिज़ॉल्यूशन पर। लक्ष्य उपकरण को ध्यान से चुनें। वास्तविक उदाहरण: एक भोला "एक LLM से दो स्क्रीनशॉट को रेट करने के लिए कहें" जज 12px स्पेसिंग त्रुटियों के साथ UI क्लोन को स्वीकृत करता है, क्योंकि LLM वास्तव में छवियों को नहीं देख सकते, यह उन्हें एम्बेडिंग में बदल देता है फिर एम्बेडिंग की तुलना करता है। इसलिए यदि आप पिक्सेल-परफेक्ट UI क्लोन चाहते हैं, तो अपने एजेंट को एक पिक्सेल-डिफ टूल दें। फिर /goal तब तक जब तक पिक्सेल डिफ 0 न हो।
- समय लेखा। हर रन और हर स्टेप को टाइमस्टैम्प करें। एजेंट को पता होना चाहिए कि प्रत्येक स्टेप में कितना समय लगा, कुल वॉल-क्लॉक बीता। समय एक प्रथम श्रेणी का उपकरण है, फुटनोट नहीं।
- प्रदाता बजट। "हम अभी क्रॉलर्स पर कितना जला रहे हैं?" एक अनुमान नहीं, एक कमांड होना चाहिए। स्क्रैप क्रेडिट शेष, इस लूप में बर्न, संचयी बर्न, और अगले भुगतान वाले बैच से पहले अनुमानित बर्न को ट्रैक करें।
- LLM खर्च। इसे डेटा-प्लेन में उपयोग करने के लिए एक LLM API कुंजी देना तर्क को बहुत सरल बना सकता है। लेकिन एजेंट को उन्हें जिम्मेदारी से खर्च करना चाहिए, पहले यह जानकर कि यह वास्तव में कितना खर्च कर रहा है।
- Codex उपयोग। यह थोड़ा मेटा है। लूप को आत्म-जागरूक होना चाहिए: मैं इस ऑप्टिमाइज़ेशन पर कितने टोकन खर्च कर रहा हूं? वर्तमान ऑप्टिमाइज़ेशन स्टेप के ग्रेडिएंट को जानने में सहायक।
पैटर्न वही पुरानी कहावत है: आप जो देख नहीं सकते, उसे ऑप्टिमाइज़ नहीं कर सकते।
यदि आप इन लूप्स को चलाने में नए हैं, तो इसे शुरू न करें और दूर न चलें। पहले साइकिल के साथ बैठें। देखें कि यह क्या छूता है। पुष्टि करें कि आपने जो हार्नेस बनाया है, उसका वास्तव में ठीक से उपयोग किया जा रहा है। फिर सोने जाएं। (और यह सोचे बिना सो जाने की कोशिश करें कि आप जागकर क्या देखेंगे)
4. मजबूर एंट्रॉपी
मजबूर एंट्रॉपी क्यों मायने रखती है: प्रत्येक लूप पिछले रन के संपूर्ण संदर्भ से जारी रहता है। मॉडल नई शुरुआत नहीं कर रहा है — यह अपने ही पिछले सौ निर्णयों और अब तक काम करने वाले ग्रेडिएंट को पढ़ रहा है।
/goal लूप में, स्थानीय मैक्सिमा से टकराना डिफ़ॉल्ट स्थिति है। एक स्पष्ट किक के बिना, एजेंट उसी पहाड़ी पर चढ़ता रहता है, और "वही पहाड़ी" वह है जहाँ वह सुधारना बंद करने पर था।
उदाहरण के लिए यदि एक छोटा नॉब परिणाम में 0.1% सुधार करता है, तो एजेंट उसी एक नॉब को घुमाता रहेगा भले ही उसके पास 1000 अन्य नॉब हों।
एंट्रॉपी को रन में स्पष्ट रूप से मजबूर किया जाना चाहिए, क्योंकि मॉडल इसे अपने आप नहीं लेगा:
- प्रत्येक साइकिल में ओवरफिट प्रतिबिंब। क्या मैं एक अधिक सामान्य समाधान बना रहा हूं, या eval को याद कर रहा हूं? यदि याद कर रहा है, तो अगला परिवर्तन एक eval-आकार का आर्टिफैक्ट हटाना चाहिए (एक सूची को सीमित करें, एक सुविधा को अंधा करें, eval को चौड़ा करें, एक सीड को अस्वीकार करें), एक जोड़ना नहीं।
- ठहराव पर एंट्रॉपी को मजबूर करें। यदि पिछले साइकिल ने मीट्रिक को नहीं हिलाया, तो अगला "वही विचार, कठिन" नहीं हो सकता। मॉडल को एक वास्तविक गैर-स्पष्ट छलांग लगानी होगी — "बॉक्स के बाहर सोचो" एक अच्छा प्रॉम्प्ट है - एजेंट को उसी नॉब को और जोर से घुमाने से रोकता है।
- एक पुनरावृत्ति लॉग रखें। एजेंट को परिकल्पना, अपेक्षित विफलता मोड, प्रत्येक स्टेप का निदान लॉग करने दें, ताकि यह पीछे मुड़कर कॉम्पैक्शन में प्रतिबिंबित हो सके।
द मेटा-मेटा-प्रॉम्प्ट
मैं इन लक्ष्यों को स्वयं लिख रहा था, फिर जल्दी से सीखा कि यह भी एजेंट्स का काम है।
इसलिए मैंने एक स्किल लिखी जो एक अच्छे लॉस-फंक्शन-डेवलपमेंट रन के लिए इस प्रकार के लक्ष्य उत्पन्न करती है।
अब यहाँ ओपन-सोर्स किया गया है:
https://github.com/elvisun/loss-function-development
/lfd-design हार्नेस और लक्ष्य उत्पन्न करने के लिए
ग्रेडिएंट डिसेंट सभी तरह से नीचे: दो लूप
एक कदम पीछे हटें और यह सभी तरह से ग्रेडिएंट डिसेंट है।
आंतरिक लूप एजेंट है: कोड लिखें, टेस्ट चलाएं, ठीक करें। छोटा क्षितिज, तेज़ प्रतिक्रिया, एक उद्देश्य — टेस्ट पास करवाएं। यह एक डेवलपर का आंतरिक लूप है, और स्पेक-ड्रिवन डेवलपमेंट इसे चलाने का तरीका है। कोडिंग एजेंट्स पहले से ही इसे ऑटोमेटेड कर चुके हैं।
बाहरी लूप /goal है: पूरे सिस्टम को एक आउटकम मीट्रिक की ओर कई चक्रों में चलाएं — शिप करें, मापें, रास्ता बदलें, उतरें। लंबा क्षितिज, छिटपुट प्रतिक्रिया। परंपरागत रूप से यह एक उत्पाद टीम का लूप है, महीनों के शिप-माप-पुनरावृत्ति सोक को एक एकल रन में संपीड़ित किया गया।
दोनों लूप अब ऑटोमेटेड हैं। आप पर जो बचा है वह लॉस फंक्शन को परिभाषित करना है — /goal को वास्तव में किस ओर और किस तरह से ऑप्टिमाइज़ करना चाहिए।
आप एक उत्पाद — या कुछ भी जो एक सार्वजनिक आर्टिफैक्ट छोड़ता है — को डिस्टिल कर रहे हैं
एक और लेंस: यह मूल रूप से डिस्टिलेशन है, जो प्रशिक्षण-समय से प्रॉम्प्ट-समय पर स्थानांतरित हो गया है। यह उसी तरह है जैसे DeepSeek, Kimi, Minimax लाइन ने GPT और क्लॉड के लिए अधिकांश अंतर को बंद किया — अपने मॉडल को किसी और के आउटपुट पर प्रशिक्षित करें जब तक कि आपका उन्हें पुनरुत्पादित न करे।
लेकिन एक मॉडल को डिस्टिल करने के बजाय, अब आप /goal और LFD का उपयोग करके किसी भी सार्वजनिक रूप से खोजे जा सकने वाले आर्टिफैक्ट में डिस्टिलेशन फिटिंग चला सकते हैं — यह कभी आंतरिक निरीक्षण नहीं करता और इसकी आवश्यकता नहीं है।
सार्वजनिक शब्द पर जोर दें। किसी के ToS-गेटेड, लॉगिन-वॉल्ड, या भुगतान वाले आउटपुट को डिस्टिल करना उचित नहीं है। लेकिन जो खुले में प्रकाशित है — वे आउटपुट जो एक कंपनी ग्राहक जीतने के लिए शिप करती है — उससे सीखना हमेशा उचित रहा है। वह हिस्सा नया नहीं है - यह सॉफ्टवेयर की सबसे पुरानी चाल है। नया यह है कि यह अब सस्ता है और महीनों के बजाय घंटों में किया जा सकता है।
एक कदम पीछे हटें, और यहाँ बड़ा बदलाव है। निष्पादन की लागत ~$0 ढह जाती है जहाँ भी सूचना समरूपता होती है — जब आउटपुट सार्वजनिक होते हैं, तो हर कोई देख सकता है कि अच्छा कैसा दिखता है, इसलिए कोई भी सप्ताहांत में $40 में इसे वापस डिस्टिल कर सकता है।
तो यहाँ एक नई खाई है जो तेजी से मूल्यवान होती जा रही है: सूचना विषमता।
कैनोनिकल ओपन-सोर्स कंपनी पहले ही झपक चुकी है। अप्रैल 2026 में, cal.com ($5M ARR) ने अपना प्रोडक्शन कोड प्राइवेट ले लिया और क्लोज्ड-सोर्स हो गया। उन्होंने जो कारण दिया वह सचमुच इस निबंध के सार जैसा पढ़ता है: AI-संचालित सुरक्षा खतरों के युग में, आप अपना स्रोत वहाँ नहीं छोड़ सकते जहाँ एक एजेंट इसे पढ़ सके।
"/goal read cal.com source code and enumerate its attack surface until something works"
यह एक बहुत खतरनाक हमला है जिसे निष्पादित करना बहुत आसान है।
जिस कंपनी की पूरी पहचान "ओपन सोर्स" थी, उसने 2026 में फैसला किया कि खुलापन एक देनदारी बन गया है। आपको यह सब कुछ बता देना चाहिए।
सॉफ्टवेयर के पूरे इतिहास के लिए, "हमने इसे बनाया" खाई थी।
वह युग समाप्त हो रहा है।
अगला युग उसी का है जिसके पास वह चीज़ है जो आर्टिफैक्ट में कभी नहीं थी: वह eval सेट जिसके खिलाफ कोई और स्कोर नहीं कर सकता। उन एज केस की सूची जिन पर आपके उपयोगकर्ता वास्तव में ठोकर खाते हैं। वह ग्राउंड ट्रुथ जिसे आप निजी तौर पर मापते हैं। जिसके पास वह लक्ष्य है जिसे प्रतिद्वंद्वी का एजेंट नहीं देख सकता, वह एकमात्र है जिसका लूप उतरता रहता है।
उत्पाद अब एक सप्ताहांत है।
जाओ वह eval बनाओ जिसे एक सप्ताहांत छू नहीं सकता।
