सॉफ्टवेयर फैक्ट्रियां क्यों विफल हो जाती हैं

या: हार्नेस ही काफी नहीं है

अपडेट - इस पोस्ट का वीडियो संस्करण YouTube पर लाइव है: https://www.youtube.com/watch?v=Ib5GBkD555M

मुझे लगता है अब हम लूप्स कर रहे हैं

हम सब AI कोडिंग को प्रोडक्शन में लाने की होड़ में हैं। लूप इंजीनियरिंग के बारे में बहुत कुछ कहा जा चुका है, और प्रचलित मान्यता यह है कि हमें शायद और अधिक लूप लिखने चाहिए।

StrongDM ने अपने लाइट्स-ऑफ सॉफ्टवेयर फैक्ट्री के बारे में लिखा, जहाँ कोई मानव कोड नहीं पढ़ता और कोई मानव कोड नहीं लिखता।

कहानी कुछ इस तरह है:

1. आप बाधक हैं।
2. मॉडल काफी अच्छे हैं।
3. कोड मुफ्त है।
4. बस और सामान शिप करो।

OpenAI के Ryan Lopopolo ने फरवरी में इस बारे में लिखा और अप्रैल में एक टॉक दी OpenAI के सॉफ्टवेयर फैक्ट्री, Symphony, के बारे में।

ये सभी लोग वाकई बहुत स्मार्ट हैं और मैं इनका बहुत सम्मान करता हूँ। लेकिन यहाँ सबसे निंदक दृष्टिकोण यह होगा कि इसे स्लॉप तोप में और अधिक VC पैसा डालने का एक और बहाना कहा जाए।

यह... चल रहा है

हमारे दोस्त Mario AI Engineer Europe में उठे और हमसे धीमा करने की विनती की -- क्योंकि जिन कंपनियों के पास कोडिंग-एजेंट दुर्घटनाओं के कारण आउटेज का कोई कारण नहीं होना चाहिए, वे... कोडिंग-एजेंट दुर्घटनाओं के कारण आउटेज झेल रही हैं।

जैसा कि Matt Pocock ने कहा, कोडबेस पहले से कहीं ज्यादा तेजी से बिखर रहे हैं।

मैं इस बारे में कोई निश्चित डेटा/निष्कर्ष नहीं खोज पाया हूँ कि वह पूरी डार्क फैक्ट्री कैसी रही। Weather-report में इस साल फरवरी और जून के बीच कुछ छिटपुट अपडेट हैं। संपादन - 23 जुलाई को हैकर न्यूज़ पर टीम के साथ कुछ बातचीत हुई है - ऐसा लगता है कि हमें जल्द ही एक और औपचारिक अपडेट मिल सकता है!

Faros AI के लोगों ने एक रिपोर्ट जारी की: जब से हम2 सभी ने जनवरी और फरवरी में ये AI कोडिंग टूल्स उठाए हैं, पुल-रिक्वेस्ट रिव्यू की गुणवत्ता काफी नीचे गिर गई है।

• अधिक टिप्पणियाँ, लंबी टिप्पणियाँ, और बिना किसी समीक्षा के मर्ज हो रहे PR की भरमार।
• घटनाएं काफी बढ़ गई हैं।
• प्रति डेवलपर बग्स काफी बढ़ गए हैं।

यह रिपोर्ट एक सत्यापन योग्य स्मोकिंग गन से अधिक एक सहसंबंध संकेत है (हाँ, मैंने जानबूझकर वह शब्द चुना, मुझे क्लॉड प्रोज़ पर मत उलझाओ), और इस पोस्ट का पूरा उद्देश्य स्लॉप डेटा से सावधान रहना है, लेकिन मैंने जो देखा है, उसके आधार पर यह दिशात्मक रूप से मान्य लगता है।

"आप इसे गलत पकड़ रहे हैं" (आप नहीं हैं)

बहुत से लोग आपको बताएंगे कि यह एक कौशल समस्या है -- कि यदि आपको अच्छे परिणाम नहीं मिल रहे हैं, तो यह आपकी गलती है।

लेकिन आप इसे जिस भी तरह से...पकड़ना चुन रहे हैं, मैं गारंटी देता हूँ कि आपको बताया जा रहा है कि यदि टोकन-मैक्सिंग आपके लिए काम नहीं कर रहा है, तो यह एक कौशल समस्या है। आपको बस और अधिक टोकन खर्च करने की जरूरत है। कोड पढ़ना छोड़ दो। और यदि आप अभी वहाँ पहुँच रहे हैं, तो मैं वादा करता हूँ कि यह प्रगति का हिस्सा है। मैंने भी पिछली गर्मियों में ऐसा ही सोचा था।

दुर्भाग्य से मेरे अहंकार के लिए, कुछ बेवकूफी भरी बातें जो मैंने "इसे बेहतर कैसे पकड़ें" के बारे में कहीं, वे रिकॉर्ड हो गईं और अब YouTube पर लगभग एक मिलियन व्यूज हैं। मैं यहाँ डींग नहीं मारना चाहता, मैं यह केवल यह स्थापित करने के लिए साझा कर रहा हूँ कि मैं लंबे समय से कोडिंग एजेंट्स का उपयोग करने के सबसे अच्छे तरीकों पर गहराई से काम कर रहा हूँ, और मैंने कुछ ऐसी चीजें खोजी हैं जिन्हें कई अन्य लोगों ने वास्तव में उपयोगी पाया है।

• Advanced Context Engineering for Coding Agents
• No Vibes Allowed -- Solving Hard Problems in Complex Codebases
• Everything We Got Wrong About RPI

खैर, इस सब ऑनलाइन "बस और टोकन लगाओ" बकबक का वादा, जिसे हमने सहने को मजबूर किया गया है, संक्षेप में यह है: पर्याप्त हार्नेस इंजीनियरिंग के साथ, हम दोनों दुनिया का सर्वश्रेष्ठ प्राप्त कर सकते हैं:

• 10 से 100 गुना तेज,
• उच्च गुणवत्ता, और
• किसी को भी वह काम कभी नहीं करना पड़ेगा जिससे हम सब नफरत करते हैं जिसे कोड रिव्यू कहा जाता है

हमें बस और अधिक लिंटर्स कॉन्फ़िगर करने हैं और पर्याप्त PR रिव्यू बॉट्स पर "विरोधी समीक्षा" जैसे कुछ जादुई शब्द छिड़कने हैं, और हमारा सॉफ्टवेयर बिना किसी घटना के खुशी से खुद का निर्माण करेगा।

यह कोई कौशल समस्या नहीं है

मैं आपको यह समझाने की कोशिश करूंगा कि कोई भी हार्नेस इंजीनियरिंग या लूप्समैक्सिंग उस समस्या को हल नहीं कर सकती जो मूल रूप से एक मॉडल-प्रशिक्षण समस्या है।

इससे निपटने के लिए, मुझे यह जानना पड़ा कि कोडिंग मॉडल वास्तव में कैसे प्रशिक्षित और मूल्यांकन किए जाते हैं - RLVR और बेंचमार्क दोनों पक्षों के संबंध में।

इस पोस्ट में मैं इन पर चर्चा करूंगा:

1. सॉफ्टवेयर फैक्ट्रीज़ 1968 से चली आ रही हैं, वे कैसे विकसित हुई हैं, और AI ने उन्हें कैसे बदला है
2. मॉडल बेंचमार्क (यहां तक कि नए "फ्रंटियर" बेंचमार्क) में शीर्ष स्कोर करने के बावजूद स्लॉप के पहाड़ क्यों उत्पन्न कर सकते हैं
3. इसके बावजूद, आप अपने कोडबेस में आग लगाए बिना काफी तेजी से आगे बढ़ सकते हैं

मैं हर रोज उभरने वाले स्किल्स प्लगइन और एआई-साइकोसिस-टोकनमैक्सिंग सलाह महामारी के प्रचार को काटने की कोशिश करूंगा, और सामान्य शब्दों में उन चीजों के प्रकार के बारे में बात करूंगा जो काम करती हैं, बिना किसी विशेष कौशल या फ्रेमवर्क का उल्लेख किए।

वीडियो संस्करण: यह पोस्ट AI Engineer World's Fair 2026 में मेरे मुख्य वक्तव्य पर आधारित (और उसका विस्तार) है।

इस पोस्ट पर फीडबैक के लिए @addyosmani, @CyrusNewDay, @HamelHusain, @zeeg, @dillon_mulroy, @nayshins, और @jeffreyhuber का धन्यवाद।

एक अलग बात: इसका वाइब कोडिंग से कोई लेना-देना नहीं है

Addy Osmani ने इस चीज़ को स्पष्ट किया है जिसे उजागर करना ज़रूरी है:

एक डेवलपर जो एक साइड प्रोजेक्ट को वाइब-कोड कर रहा है जिसे एक दर्जन लोग कभी चलाएंगे, और एक टीम जो दस साल पुरानी एंटरप्राइज सिस्टम को एक और तिमाही के लिए जीवित रख रही है, उनमें नाम देने लायक लगभग कोई बाधाएं साझा नहीं हैं, और प्रचलन में अधिकांश सलाह वास्तव में उन दो लोगों में से एक है जो दूसरे को बता रहा है कि कैसे जीना है।

यदि आप वाइब कोडिंग पसंद करते हैं, तो कृपया, वाइबिंग करते रहें। मैं अभी भी बहुत सी चीजों को वाइब कोड करता हूँ, मैं बहुत सारे प्रोडक्शन सॉफ्टवेयर को भी मेंटेन करता हूँ (और HumanLayer के माध्यम से, 1000s अन्य इंजीनियरों को ऐसा करने में मदद करता हूँ), इसलिए बाकी पोस्ट उन लोगों के लिए है जो जटिल कोडबेस में कठिन समस्याओं को हल कर रहे हैं।

मैं इस विभाजन के बारे में बात करने के लिए ब्राउनफील्ड शब्द बहुत सुनता हूँ। ऐतिहासिक रूप से इसका मतलब कोई दस साल पुरानी Java चीज़ था, लेकिन जिस गति से हम अब शिप कर सकते हैं, ऐसा लगता है कि एजेंट-निर्मित कोडबेस शायद तीन से छह महीने के बाद संघर्ष करना शुरू कर देता है -- आप धीमा होने लगते हैं, और नई चीजें जोड़ने का आपका तरीका बदलना पड़ता है।

सॉफ्टवेयर फैक्ट्री का एक संक्षिप्त इतिहास

मैंने अपने पूरे करियर में सॉफ्टवेयर फैक्ट्रीज़ बनाई और उनका अध्ययन किया है, लेकिन मैंने यह हाल ही में सीखा: यह शब्द 1968 में NATO सम्मेलन से जाता है -- उसी सम्मेलन से जिसने हमें "सॉफ्टवेयर इंजीनियरिंग" दी।

तब से मुझे एकमात्र अन्य चीज़ बहुत दिलचस्प लगती है वह यह है कि अमेरिकी रक्षा विभाग ने एक 31-पेज का पीडीएफ लिखा कि कैसे DoD को जेनकिंस का बेहतर उपयोग शुरू करने की जरूरत है या कुछ और।

2022 की सॉफ्टवेयर फैक्ट्री

आइए अपनी "सॉफ्टवेयर फैक्ट्री" की परिभाषा को 2022 के आसपास, AI से ठीक पहले, आधारित करें। एक सामान्य सॉफ्टवेयर फैक्ट्री में:

• लोग तय करते हैं कि क्या बनाना है -- इंजीनियर, PM, नेतृत्व दृष्टि का संचालन करते हैं
• यह एक ट्रैकर में जाता है -- Linear, Jira, जो भी हो: एक स्टेट मशीन कि क्या करने की जरूरत है
• कोई एक टिकट लेता है और उसे बनाता है -- शायद कुछ मैनुअल/ऑटोमेटेड टेस्टिंग भी करता है
• पुल रिक्वेस्ट -- स्वचालित जांच, एक मानव कोड की समीक्षा करता है, शायद कोई इसे डाउनलोड करके टेस्ट करता है
• कुछ गलत है? वापस लूप करें "कोई चीज़ बनाता है" पर
• प्रोड में शिप करें -- और यह उपयोगकर्ताओं से संपर्क करता है
• मॉनिटरिंग जोड़ें -- जब कुछ टूटता है तो 3 बजे एक इंजीनियर को पेज करने के आसपास एक पूरा उद्योग बनाया गया है
• उपयोगकर्ता शिकायत करते हैं -- चीजें मांगते हैं, बग ढूंढते हैं, फीचर रिक्वेस्ट फाइल करते हैं → टीम के पास वापस ट्रैकर में जोड़ने के लिए

और यह चलता रहता है। हमने अभी तक AI को छुआ भी नहीं है, और इस तस्वीर में पहले से ही कई लूप्स हैं।

फ्रंट-लोडिंग अलाइनमेंट

एक चीज़ जो टीमों ने दशकों पहले समझ ली थी: बनाने में घंटे या दिन लगते हैं, और समीक्षा में भी।

इसलिए हम काम को फ्रंट-लोड करते हैं -- योजना, आर्किटेक्चर प्रस्ताव, स्प्रिंट प्लानिंग -- एक साथ, एक टीम के रूप में। इसका मतलब है:

• कम रीवर्क, क्योंकि हमने कोई कोड लिखने से पहले संरेखित किया
• हर पंक्ति की समीक्षा करने में कम समय, यदि आपने कभी कोई लंबा लेकिन अच्छी तरह से किया गया PR पढ़ा है, तो आप जानते हैं कि जब यह लगभग-सही होता है तो समीक्षा कितनी तेजी से होती है

हम इस पर बाद में वापस आएंगे - आइए देखें कि जब आप एजेंटिक कोडिंग को तस्वीर में लाते हैं तो क्या होता है।

एजेंटिक सॉफ्टवेयर फैक्ट्री

अब हर कंपनी और उनकी मां --

• Ramp
• Stripe
• WorkOS
• Brex

ने इस साल का अधिकांश समय यह समझाने में बिताया है कि उन्होंने एक एजेंट फैक्ट्री कैसे बनाई जो उनके 75% कोड के क्रम पर शिप करती है।

एजेंटिक फैक्ट्री ज्यादातर "कोई चीज़ बनाता है" → "एक एजेंट चीज़ बनाता है" को बदलने जैसा दिखता है -- यहाँ कुछ चीजें हैं जैसे ऑर्केस्ट्रेशन, एक हार्नेस, एक सैंडबॉक्स, एक मॉडल, कंप्यूटर उपयोग, आदि। मैं उन विवरणों में गहराई से नहीं जाऊंगा क्योंकि सच कहूं तो मैं इसके बारे में पढ़ते-पढ़ते बीमार हो गया हूँ और मुझे यकीन है कि आप भी हैं।

जब एजेंट चीज़ बनाता है:

• बनाने में घंटों या दिनों से घटकर मिनट या घंटे लगते हैं।
• समीक्षा में अभी भी घंटे या दिन लगते हैं। एक मानव को अभी भी कोड पढ़ना और बदलाव का परीक्षण करना है। इसलिए समीक्षा अब बाधक है।

तो आप समीक्षा को भी तेज करते हैं:

• एजेंटिक कोड रिव्यू, स्टाइल, बग्स, सुरक्षा को पकड़ने के लिए।
• एजेंटिक रिग्रेशन टेस्टिंग, ब्राउज़र और कंप्यूटर उपयोग के साथ बाहर से इसे परखने के लिए और शायद आपको एक प्यारा सा छोटा वीडियो भेजे जब यह हो जाए

समीक्षा अब तेज है, लेकिन यह शायद अभी भी बाधक है। लेकिन हम और लूप कर सकते हैं।

अगला आप घटनाओं को फैक्ट्री में रूट कर सकते हैं। 3 बजे किसी को पेज करने के बजाय, वे एक PR के साथ जागते हैं जो शायद इसे पहले ही ठीक कर देता है।

हम उपयोगकर्ता प्रतिक्रिया को भी फैक्ट्री में रूट कर सकते हैं। लोग चीजें मांगते हैं, वे बन जाती हैं।

जिस बिंदु पर काम दो प्रश्न हैं: आप क्यू में कितना सामान भर सकते हैं, और आप बाहर आने वाले की कितनी तेजी से समीक्षा और परीक्षण कर सकते हैं?

जो हमें लाइट्स-ऑफ सॉफ्टवेयर फैक्ट्री पर लाता है।

लाइट्स-ऑफ सॉफ्टवेयर फैक्ट्री

Dan Shapiro ने इस शब्द को गढ़ा और Simon Willison ने StrongDM के इसके कार्यान्वयन के बारे में लिखा -- जहाँ हम अब कोड नहीं पढ़ते हैं।

आप अपनी सुंदर सॉफ्टवेयर फैक्ट्री को देखते हैं। यह उस कष्टप्रद छोटे कोड रिव्यू कदम से बर्बाद हो गया है और आप कहते हैं: आप जानते हैं क्या, वह चीज़ जहाँ एक मानव हर बदलाव को पढ़ता है? धन्यवाद, नहीं।

तो आप इसे छोड़ देते हैं, और आप प्रयास कहीं और लगाते हैं:

• टेस्टिंग में निवेश करें और एजेंट को अपने काम का परीक्षण करने दें
• सैंडबॉक्स और ऑर्केस्ट्रेशन में निवेश करें
• ऑटोमेटेड रिव्यू में निवेश करें
• मॉनिटरिंग में निवेश करें
• रोलआउट में निवेश करें
• उपयोगकर्ताओं से फीडबैक सिग्नल एकत्र करने में निवेश करें

और अब काम वास्तव में केवल एक प्रश्न है: हम एजेंट से कितना सामान बनाने के लिए कह सकते हैं? हम समुद्र को कितना उबालना चाहते हैं?

यह बहुत अच्छा होने वाला है (यह नहीं है)

मैं कुछ संभावित रूप से विवादास्पद प्रस्तावित करने जा रहा हूँ: लाइट्स ऑफ फैक्ट्री काम नहीं करती है।

आइए जानें कि सॉफ्टवेयर फैक्ट्रीज़ क्यों विफल होती हैं।

हमने यह कोशिश की

जुलाई 2025 में हम पूरी तरह से लाइट्स-ऑफ हो गए। बस स्पेक्स और टिकट्स पढ़ें, सभी छोटे/मध्यम सामान के लिए बैकग्राउंड एजेंट्स, पूरी चीज़।

यदि आपने कुछ महीनों के लिए गंभीरता से यह कोशिश की है, तो आप पहले से ही जानते हैं कि यह कैसे समाप्त होता है। आपको कम से कम एक ऐसी समस्या मिलती है जो इतनी कठिन है कि एजेंट इसे हल नहीं कर सकता -- यहां तक कि आपके सबसे उन्नत प्रॉम्प्टिंग और वर्कफ़्लो के साथ भी।

• आप गहरा संदर्भ-जागरूक शोध करते हैं, सभी सही भागों को मॉडल के विश्लेषण के लिए स्मार्ट ज़ोन में इकट्ठा करते हैं
• आप एजेंट को 10 अलग-अलग तरीकों से पुनरुत्पादन करने का प्रयास करते हैं

अंत में आपको इसे चूसना होगा और उस कोडबेस में खुदाई करनी होगी जिसे आपने तीन महीने पहले पढ़ना बंद कर दिया था, यह पता लगाने की कोशिश कर रहे हैं कि क्या टूटा है।

और इस बीच:

• आपकी साइट डाउन थी।
• आपके उपयोगकर्ता नाराज थे।
• और आप, यदि आप मेरे जैसे कुछ भी हैं, दुखी थे -- उस सारे स्लॉप कोड को पढ़ रहे थे जिसे आपने अपने सिस्टम में आने दिया था।

पहली बार जब हमारे साथ ऐसा हुआ, मैंने इसे झटक दिया। भले ही मैंने अभी-अभी क्लॉड स्पेगेटी में खुदाई करते हुए लगभग दो सप्ताह बिताए थे, "डाउनसाइड जोखिम वेग के लायक था"। नवंबर में ~तीसरी बार तक, हमने फैसला किया कि शुरू से फिर से लिखना आसान होगा, और मेरे सह-संस्थापक ने पूरे दो सप्ताह VS Code में (कर्सर भी नहीं) सभी पैटर्न को हाथ से निकालने में बिताए।

मॉडल समय के साथ कोडबेस की गुणवत्ता को खराब करते हैं

मैं इस पर पहुंचना चाहता हूँ: मॉडल में एक कमी है। वे समय के साथ कोडबेस की गुणवत्ता को बनाए नहीं रख सकते और सुधार नहीं सकते -- मानव मार्गदर्शन की एक अच्छी मात्रा के बिना नहीं।4

जब मैं रखरखाव कहता हूँ, तो मेरा मतलब उस विशिष्ट चीज़ से है जहाँ कोडबेस के एक हिस्से को बदलना दूसरे हिस्से को तोड़े बिना वास्तव में, वास्तव में कठिन हो जाता है। यह Martin Fowler की शॉटगन सर्जरी है।

मैं रखरखाव के बारे में बहुत कुछ नहीं कहूंगा। इसके बारे में बहुत सारी किताबें हैं जिन्हें आप पढ़ सकते हैं:

• John Ousterhout की A Philosophy of Software Design
• Robert C. Martin की Clean Code
• Martin Fowler की Refactoring

तो, मॉडल सॉफ्टवेयर रखरखाव क्यों नहीं कर सकते?

"लेकिन निश्चित रूप से तब से मॉडल बेहतर हो गए हैं"

इस बिंदु पर आप शायद कहने के लिए मर रहे होंगे: लेकिन Dex, निश्चित रूप से जुलाई के बाद से मॉडल बहुत बेहतर हो गए हैं

वे कुछ मायनों में हैं। दूसरों में वे लगभग समान हैं।

• एकल समस्याओं को हल करना, या एक नई मार्केटिंग साइट को वाइब-कोड करना? हाँ। बहुत बेहतर।
• समय के साथ कोडबेस की गुणवत्ता में सुधार करना? बहुत बेहतर नहीं, जहाँ तक मैं बता सकता हूँ।

मैं यह साबित नहीं कर सकता। आप भी इसे साबित नहीं कर सकते। कोडबेस की गुणवत्ता बनाए रखने की मॉडल की क्षमता के लिए कोई अच्छा बेंचमार्क नहीं है। (इस पर और बाद में।)

कोडबेस की गुणवत्ता बनाए रखने की मॉडल की क्षमता का कोई अच्छा बेंचमार्क नहीं है

लेकिन यदि आपने कुछ समय के लिए कोडिंग एजेंट्स के साथ काम किया है -- और बहुत से लोग ठीक इसी बारे में पोस्ट कर रहे हैं -- तो आपके पास शायद पहले से ही यह वाइब है: वे समय के साथ चीजों को बदतर बनाते हैं, और कोडबेस में काम करना कठिन बनाते हैं।

तो यह पता लगाने के लिए कि ऐसा क्यों होता है, मैं पहले महान कोडिंग एजेंट पर ज़ूम आउट करना चाहता हूँ।

Claude Code हार्नेस के अंदर रीइन्फोर्समेंट लर्निंग के कारण जीता

Claude Code शून्य से ~$4B -- अब कुछ ~$9B -- राजस्व में एक वर्ष से भी कम समय में पहुंच गया।

जो थोड़ा जंगली है, क्योंकि पहले से ही महान CLI एजेंट थे। aider, cline, codebuff -- सभी Claude Code से पहले थे, सभी में वास्तव में शानदार कॉन्टेक्स्ट इंजीनियरिंग बिल्ट-इन थी, सभी में वही टूल सेट था जिसे आप Claude Code को दे सकते हैं: read, write, edit, grep, bash। मैंने उनका उपयोग किया। वे अच्छे थे। लेकिन साथ ही, टूल का उपयोग कभी-कभी... विफल हो जाता था -- आप इसे एक ही एडिट को तीन बार फड़फड़ाते हुए देखते थे और अपना एडिटर वापस खोलकर इसे स्वयं करने लगते थे।

2024 का SWE-Agent पेपर बताता है कि टूल शेप में छोटे बदलाव कैसे ध्यान देने योग्य अंतर पैदा करते हैं, जैसे ReadFile परिणामों में लाइन नंबर शामिल करना, या Edit टूल को find/replace से लाइन-रेंज एडिट्स में बदलना।

फिर Claude Code लॉन्च हुआ और काफी तेजी से वर्टिकल हो गया। आप इसे वितरण के रूप में खारिज कर सकते हैं, लेकिन प्रामाणिक रूप से स्वीकृत व्याख्या यह है कि Claude Code जीता क्योंकि यह बेहतर था, और यह बेहतर था क्योंकि Anthropic ने मॉडल को हार्नेस के अंदर RL किया -- पहली बार जब किसी लैब ने मॉडल को उन सटीक टूल्स के खिलाफ प्रशिक्षित किया जिनके साथ वे इसे शिप करने वाले थे। और यह एक एजेंटिक लूप में उन टूल्स को कॉल करने में वास्तव में, वास्तव में अच्छा हो गया।

एक चीज़ है टूल डेफिनिशन और इवैल के साथ तब तक खिलवाड़ करना जब तक आपको वह शेप न मिल जाए जो मॉडल को सबसे अच्छी लगती है -- मैंने विभिन्न उपयोग मामलों के लिए ऐसा करने में हफ्ते बिताए हैं। यह एक अलग खेल है जब आपके पास वेट्स होते हैं और आप मॉडल को स्वयं एक विशेष सेट टूल्स पर बेहतर होने के लिए संशोधित कर सकते हैं।

OpenAI टीम ने नवंबर में एक टॉक दी जिसने इसे काफी अच्छी तरह से रखा: यदि आप एक हार्नेस बनाते हैं लेकिन आपके पास वेट्स नहीं हैं और मॉडल को उसके अंदर RL नहीं कर सकते, तो आप हमेशा एक ऐसी टीम से नुकसान में रहेंगे जिसके पास दोनों हैं।

60 सेकंड में कोडिंग एजेंट RL

मैंने इस विषय पर बहुत शोध किया और महत्वपूर्ण भागों को समझाने की कोशिश करने के लिए बहुत सारे विज़ुअलाइज़ेशन बनाए, लेकिन मैंने पाया कि Calvin French-Owen (कोडेक्स टीम पर MTS, Segment के संस्थापक) ने AI Council में एक टॉक दी जिसने बहुत बेहतर और साफ काम किया, इसलिए मैं यहाँ उनकी स्लाइड्स से प्रेरित यह एनिमेशन छोड़ रहा हूँ:

एक मॉडल को कोडिंग में बेहतर बनाने के लिए, आप:

1. एक समस्या को हल करने के लिए कुछ कोडिंग एजेंट ट्रेस उत्पन्न करेंगे (जैसे मेरे टेस्ट ठीक करें)
2. कुछ मानदंडों (वेरिफायर) के आधार पर ट्रेस को स्कोर करें
3. मॉडल वेट्स को अपडेट करें ताकि अच्छे ट्रेस अधिक संभावित हों, और बुरे ट्रेस कम संभावित हों

और फिर आप इसे हफ्तों या महीनों के दौरान लाखों बार करते हैं।

हालांकि इन चीजों का "स्कोरिंग" भाग काफी मनमाने ढंग से एक-आयामी हो सकता है।

खराब डिज़ाइन के लिए कोई दंड नहीं

SWE-bench Multilingual लें। कार्य छोटे हैं -- प्रत्येक लगभग पंद्रह मिनट का काम -- Redis, jq, और Django जैसे ओपन-सोर्स रिपॉजिटरी से स्क्रैप किया गया। इनाम एक या शून्य है:

• FAIL_TO_PASS - क्या आपने वह चीज़ ठीक की जिसे ठीक करने के लिए कहा गया था?
• PASS_TO_PASS - क्या आपने इसे बिना कुछ और तोड़े किया?

यहाँ एक वास्तविक है, fastlane__fastlane-19304, fastlane से -- एक Ruby प्रोजेक्ट। इसकी zip क्रिया दो वैकल्पिक पैरामीटर लेती है और उन पर तुरंत .empty? कॉल करती है, इसलिए जैसे ही आप include और exclude को छोड़ देते हैं, यह गिर जाता है:

मानव फिक्स जिसने इस विशेष समस्या को बंद किया वह दो लाइनें हैं (डिफ़ॉल्ट nils को खाली सरणियों में बदलें):

मूल्यांकन के दौरान, मॉडल

1. एक बेस कमिट से शुरू होता है -- रिपॉजिटरी उस पल के लिए चेक आउट की गई जो उस फिक्स के उतरने से ठीक पहले था
2. बग रिपोर्ट - इस मामले में 'zip_command': undefined method 'empty?' for nil:NilClass

एजेंट जाता है और मुद्दे के आधार पर कुछ कोड लिखता है। यह गोल्डन पैच या टेस्ट पैच नहीं देखता जो ग्रेडर के रूप में कार्य करता है:

फिर:

1. हम जो भी पैच इसने तैयार किया है उसे रखते हैं, फिर
2. टेस्ट फ़ाइलों में इसके द्वारा किए गए किसी भी एडिट को फेंक देते हैं (हमने एक मॉडल को चुपचाप विफल टेस्ट को कमेंट आउट करते हुए या एक मॉक डालते हुए पकड़ा है जो टेस्ट को बेकार कर देता है)
3. बेंचमार्क के टेस्ट पैच को शीर्ष पर लागू करते हैं, और
4. पूरा सूट चलाते हैं: मौजूदा zip टेस्ट (PASS_TO_PASS) प्लस नया (FAIL_TO_PASS) यह देखने के लिए कि क्या वे दोनों पास होते हैं

अलग बात - बेंचमार्क वेरिफायर नहीं हैं - वास्तव में उन्हें एक दूसरे से अलग रखा जाना चाहिए (टेस्ट पर ट्रेन न करें, यडा यडा) - मेरा मुख्य रूप से यह अर्थ "कोडिंग एजेंट ट्रेस की गुणवत्ता का न्याय करना" और इसकी सीमाओं को व्यक्त करना है।

मॉडल सही उत्तर तक कैसे पहुंचा, इससे कोई फर्क नहीं पड़ता। यदि टेस्ट पास हो जाते हैं, तो हम जीत जाते हैं, लेकिन कोडबेस रखरखाव को कम करने के लिए कोई दंड नहीं है।

कोडबेस रखरखाव को कम करने के लिए कोई दंड नहीं है

इस तरह आपको हर चीज के आसपास try catch मिलते हैं:

गुणवत्ता सत्यापित करना "क्या टेस्ट पास हुए" से कहीं अधिक कठिन है

टेस्ट चलाने से आपको ~सेकंड में एक साफ पास या फेल मिलता है। यही कारण है कि RL प्रत्येक मॉडल पीढ़ी को अनुकूलित करने के लिए लाखों लूप चला सकता है।

लेकिन खराब आर्किटेक्चर की लागत फलन हफ्तों, महीनों, शायद वर्षों में मापी जाती है। यह पहली बार होता है जब कोई एक-लाइन बदलाव के लिए उस फ़ाइल को खोलता है और महसूस करता है कि वे इसे एक लाइन में नहीं कर सकते -- कि किसी ने इसे थोड़ा बहुत कठिन वाइब किया, और अब हमें ग्यारह स्थानों पर एक ही संपादन करना होगा और उम्मीद करनी होगी कि तीन फ़ाइलों पर कुछ चुपचाप न टूटे।

टेस्ट आपको सेकंड में फीडबैक देते हैं, लेकिन खराब आर्किटेक्चर की लागत फलन हफ्तों, महीनों, शायद वर्षों में मापी जाती है

खराब डिज़ाइन वह एक चीज़ है जिसका आज के बेंचमार्क मूल्यांकन नहीं कर सकते। और मैं जानता हूँ, मैं जानता हूँ, RL != बेंचमार्क, लेकिन यदि यह RL में हल हो गया होता, तो मुझे पूरा यकीन है कि यह हमारे बेंचमार्क के डिज़ाइन में भी दिखना शुरू हो जाता।

किसी भी मामले में, मैं व्यक्तिगत रूप से आज के बेंचमार्क पर किसी भी सुधार पर भरोसा नहीं करता जो इस बात के संकेतक के रूप में हो कि मॉडल अचानक आपके कोडबेस को स्लॉप करने में अच्छे नहीं हैं।

फ्रंटियर धीरे-धीरे बेहतर हो रहा है

बेशक बहुत सारे स्मार्ट लोग इस पर काम कर रहे हैं। मेरी बात यह नहीं है कि यह नहीं किया जा सकता, यह है कि हाइप अनुशासन से आगे निकल रहा है।

कुछ प्रयास जो मुझे सही दिशा में इशारा करते हुए लगते हैं:

• SWE-Marathon (Abundant AI): ~400-घंटे के कार्य जैसे "सभी Excel को क्लोन करें, हर फीचर" -- एकल पास/फेल बिट के बजाय एक मिश्रित इनाम चैनल के साथ
• DeepSWE (Datacurve): OSS रिपॉजिटरी पर बड़े कार्य जो वास्तविक दुनिया में कभी नहीं बनाए गए, इसलिए निर्माण के अनुसार वे पहले से ही प्रशिक्षण सेट में नहीं हो सकते (संदूषण को हल करता है, लेकिन गुणवत्ता को नहीं)
• Frontier Code (Cognition): मल्टी-PR कार्य, और एक चतुर चाल जो गुणवत्ता का निर्धारणात्मक मूल्यांकन करती है -- यह मॉडल को प्री-पैच कोड पर विफल नहीं होने वाले टेस्ट लिखने के लिए दंडित करता है (यदि आपने म्यूटेशन टेस्टिंग के बारे में कभी नहीं सुना है तो आप एक मजेदार सवारी के लिए तैयार हैं5)। यह कोड-गुणवत्ता नियमों की जांच करने वाले डिफ पर एक जज मॉडल भी चलाता है।

लेकिन गुणवत्ता का न्याय करने वाला एक मॉडल केवल इतना ही जा सकता है।

वास्तव में, यह कल्पना करना कठिन नहीं है कि अगर कोई मॉडल अच्छे कोड को बुरे से विश्वसनीय रूप से अलग कर सके, तो वह शुरू से ही अच्छा संस्करण लिख सकता था। RL को एक तेज़ और विश्वसनीय ओरेकल की ज़रूरत है, और हमारे पास अभी तक maintainability के लिए ऐसा कोई ओरेकल नहीं है।

अगर कोई मॉडल अच्छे कोड को बुरे से विश्वसनीय रूप से अलग कर सके, तो वह शुरू से ही अच्छा संस्करण लिख सकता था, लेकिन maintainability के लिए कोई तेज़ ओरेकल नहीं है, इसलिए हम RL के दौरान इसके लिए reward नहीं दे सकते।

बेशक, अधिक review agents और अधिक tokens मदद करते हैं—वे फ़र्श को ऊपर उठाते हैं, बेवकूफी भरी चीज़ों को पकड़ते हैं।

लेकिन वे छत को नहीं हिलाते, क्योंकि छत वही है जो हम मॉडल को RL में सिखाने में कामयाब हुए हैं, और अच्छा डिज़ाइन वह चीज़ है जिसे हम अभी भी नहीं जानते कि कैसे सिखाया जाए।

इसलिए मैं अभी भी इनमें से किसी पर अपना कोडबेस दांव पर नहीं लगाऊंगा। लेकिन ये पहले evals हैं जो मैंने देखे हैं जो pass/fail पर रुकने के बजाय maintainability को स्कोर करने की कोशिश करते हैं।

अलग बात शायद कोई भविष्य का मॉडल इसे समझ जाए और हम रुक सकें। अगर आप GPT-7 आने तक बस yolo prompts करना चाहते हैं और पता लगाना चाहते हैं, तो आपका स्वागत है—लेकिन bitter lesson भाड़ में जाए, हमारे पास अभी हल करने के लिए समस्याएँ हैं, और मैं बताऊंगा कि हम यह कैसे करते हैं।

रोशनी वापस लाना

आज मुझे पता चला कि Twitter Articles की एक "media limit" होती है, जिसका मतलब है कि बाकी का हिस्सा एक भाग II पोस्ट में जाएगा - बने रहिए।