हर एजेंट को महंगा होने की ज़रूरत नहीं

पूरे कोडबेस की समीक्षा और मरम्मत का एक स्किल जो काम को लागत-स्तरीकृत एजेंट सीढ़ी पर फैलाता है — और बिल्कुल अंतिम SHA से कम पर ख़त्म होने से इनkar करता है।

मैंने हाल के दिनों में एक Codex स्किल बनाने में बिताए जो पूरे रिपॉज़िटरी की समीक्षा करता है और जो कमियाँ मिलती हैं उन्हें ठीक करता है। समीक्षा करना आसान हिस्सा था। कठिन हिस्सा यह था कि इसे यह कहने से रोका जाए कि वह पूरा हो गया जब वह पूरा नहीं हुआ था।

तीन चीज़ों ने यह तय किया कि यह आख़िर में कैसा बना।

गिनती (Enumeration) निर्णय नहीं है। दोनों के लिए एक जैसी दर मत दीजिए।

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

इसलिए यह स्किल काम को एक सीढ़ी में बाँटता है:

• ENUMERATE — सस्ता। जो कुछ भी मौजूद है उसकी सूची बनाओ। फ़ाइलें, मॉड्यूल, टेस्ट कवरेज, main के विरुद्ध diff, जिन चीज़ों को हम छुएँगे उनका मैनिफ़ेस्ट। कोई राय नहीं। कोई निर्णय नहीं।
• REVIEW — मध्य। मैनिफ़ेस्ट पर चलो। निष्कर्षों को समूहित करो। हर क्लस्टर के लिए, न्यूनतम पैच और एक पैराग्राफ़ का औचित्य तैयार करो जो उस विफलता मोड का नाम बताए जिसे यह रोकता है।
• JUDGE — केवल शीर्ष स्तर। हर प्रस्तावित पैच को उस कोड के विरुद्ध फिर से पढ़ो जिसे वह छूता है। उसे अधिकृत करो, अस्वीकार करो, या दूसरे गिनती (enumeration) दौर के लिए वापस भेजो। यहीं गलत होना महँगा है, इसलिए यहीं महँगा मॉडल अपनी उपयोगिता साबित करता है: प्राधिकरण पथ, concurrency और cancellation, transaction और migration सुरक्षा, अनुबंध जो कई फ़ाइलों में फैले हैं।

डायग्राम पर बना डैश वाला लूप सजावटी नहीं है। जज से मिली अस्वीकृति रन को समाप्त नहीं करती — यह काम को अधिक संकुचित दायरे के साथ वापस गिनतीकर्ता (enumerator) के पास भेज देती है। repeat until the pass comes back clean वास्तविक अनुबंध है।

Codex उप-एजेंट एक फ़ाइलसिस्टम साझा करते हैं।

यह वह हिस्सा था जिसने मुझे चौंकाया। कोई अलग-थलग कॉपी नहीं। कोई merge चरण नहीं। किसी भी एजेंट द्वारा की गई राइट तुरंत हर दूसरे एजेंट को दिखाई देती है — अगले बनने वाले एजेंट सहित।

इससे वर्कफ़्लो डिज़ाइन करने का तरीक़ा बदल जाता है। तीन समीक्षकों का यह कहना कि वे हर एक रिपॉज़िटरी क्लोन करें और अपना-अपना diff दें, बेमतलब है; जो अंत में लिखता है वही जीतता है, और बाक़ियों का काम बस ग़ायब हो जाता है। इसके बजाय, यह स्किल वर्किंग ट्री को एकल साझा ब्लैकबोर्ड की तरह मानता है: enumerate मैनिफ़ेस्ट लिखता है, review उसे पढ़ता है और हर क्लस्टर के लिए एक पैच फ़ाइल जोड़ता है, judge पैच पढ़ता है, जिन्हें वह अधिकृत करता है उन्हें लागू करता है, और फिर से build चलाता है। सत्यापन चरण ही लूप को बंद करता है।

दूसरा परिणाम: यह सkill अपने ही प्रगति चिह्नों पर भरोसा नहीं कर सकता। "मैंने 14 पैच लागू किए हैं" का कोई मतलब नहीं अगर अगला एजेंट उन्हें overwrite कर दे। इसलिए काउंटरों या "completed" फ़्लैग पर भरोसा करने के बजाय, यह स्किल पूर्णता को केवल उसी एक चीज़ पर gate करता है जो वास्तव में बची रहती है: वर्किंग ट्री का exact final SHA। जब judge sign off करता है, तो रन उस SHA को रिकॉर्ड करता है, और अगला invocation tree को उसके विरुद्ध जाँचता है उससे पहले कि वह फिर से शुरू हो। अगर SHA वह नहीं है जो पिछले साफ़ पास ने छोड़ा था, तो रन enumeration से फिर से शुरू होता है — इसलिए नहीं कि काम गलत था, बल्कि इसलिए कि substrate उसके नीचे से हिल गया।

स्थिति बैज "vibes" नहीं हैं। वे SHA हैं।

• READY FOR MERGE — रिकॉर्ड किया गया SHA मौजूदा tree SHA से मेल खाता है, build पास होता है, और judge ने हर पैच को अधिकृत किया है।
• INCOMPLETE — काम लागू किया गया, लेकिन या तो पिछले साफ़ पास के बाद से tree drift हो गया है या judge ने एक या अधिक क्लस्टर अस्वीकार करके उन्हें फिर से गिनती (enumeration) के लिए वापस भेज दिया है।
• BLOCKED — लूप चला और असफल रहा; कोई क्लस्टर जिसे judge बार-बार अस्वीकार कर रहा है, या build जो green नहीं हो रहा। इस पर कोई मनुष्य देखता है।

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