हर नए मॉडल की रिलीज़ वही पुराना घिसा-पिटा विवाद छेड़ देती है। कमेंटेटर विजेता घोषित करने की होड़ में लग जाते हैं और पिछले स्तर को बेकार घोषित कर देते हैं। GPT-5.6 Luna के Terra और Sol के साथ आने से, कहानी खुद-ब-खुद लिखी जा रही है: Luna इतनी सस्ती और सक्षम है कि वह Terra को अप्रासंगिक बना दे। यह गलत है। यह भी महंगी है। अपने कोडिंग एजेंट्स के लिए मॉडल चुनना कोई सौंदर्य प्रतियोगिता, टीम की पहचान, या बेंचमार्क की दौड़ नहीं है। यह एक परिचालन नीति (operating policy) है। जो टीमें इस अंतर को समझ लेंगी, वे उन टीमों की तुलना में कम खर्च करेंगी, तेज़ी से काम करेंगी और कम गलतियाँ करेंगी जो हर अनुरोध के लिए डिफ़ॉल्ट रूप से सबसे शक्तिशाली मॉडल का उपयोग करती हैं।
आपका डिफ़ॉल्ट वह सबसे सस्ता टूल होना चाहिए जो काम के लायक हो
Luna एक वैल्यू टियर है, और यह कोई कम प्रशंसा नहीं है। यह सीमित, स्पष्ट और आसान कार्यों में बेहतरीन प्रदर्शन करती है। वर्गीकरण (classification), सारांश (summarization), छोटे कोड संपादन (short code edits), और शुरुआती शोध (first-pass research) के बारे में सोचें। जब कोई एजेंट प्राथमिकता लेबल असाइन करने के लिए एक सपोर्ट टिकट को पढ़ता है, तो Luna पर्याप्त है। जब वह कुछ फाइलों में एक वेरिएबल का नाम बदलता है या git diff का एक पैराग्राफ का सारांश तैयार करता है, तो Luna पर्याप्त है। ये ऐसे काम हैं जिनका दायरा सीमित है, इनपुट स्पष्ट हैं और आउटपुट वस्तुनिष्ठ रूप से जांचने योग्य हैं।
आर्थिक प्रभाव ही खेल बदल देता है। Luna सस्ती है। उच्च वॉल्यूम पर, यह ऑटोमेशन को एक महंगी रस्म से बदलकर बुनियादी ढांचे (infrastructure) में बदल देता है। आप टोकन गिनना बंद कर देते हैं और थ्रूपुट (throughput) मापना शुरू कर देते हैं। एक सस्ता मॉडल जो अस्सी प्रतिशत नियमित कार्यों को पूरा कर देता है, वह एक महंगे मॉडल से अधिक मूल्यवान है जो पचासी प्रतिशत कार्य करता है, यदि वह अतिरिक्त पांच प्रतिशत परिणाम को नहीं बदलता है। यदि Luna दो सेकंड में एक यूनिट टेस्ट जेनरेट करती है और Terra पांच गुना लागत पर आठ सेकंड में थोड़ा अधिक बेहतर टेस्ट जेनरेट करती है, तो गणित तभी काम करता है जब कोई हर लाइन का सावधानीपूर्वक ऑडिट कर रहा हो। अधिकांश समय, कोई नहीं करता है। Luna को आपके सीमित कार्यों के लिए डिफ़ॉल्ट होना चाहिए, क्योंकि अधिकांश काम सीमित ही होते हैं।
जब सीमाएं समाप्त हो जाएं, तो एस्केलेट (Escalate) करें
Terra बेकार नहीं है। यह आपका एस्केलेशन टियर है, और यह उन कार्यों में अपनी उपयोगिता साबित करती है जिनकी सीमाएं स्पष्ट नहीं होतीं। इसका उपयोग तब करें जब लक्ष्य अस्पष्ट हो या जब काम में डिप्लॉयमेंट पाथ, क्रॉस-मॉड्यूल बदलाव, या इंसिडेंट ट्राइएज (incident triage) जैसे जटिल सिस्टम शामिल हों। एक डिप्लॉयमेंट पाथ जो फीचर फ्लैग्स के साथ स्टेजिंग, कैनरी और प्रोडक्शन वातावरणों से होकर गुजरता है, उसका कोई साफ-सुथरा स्पेसिफिकेशन नहीं होता। एक ऐसा रिफैक्टर जो बिलिंग लॉजिक को प्रभावित करता है और चुपचाप रिपोर्टिंग पाइपलाइन तक फैल जाता है, वह कोई सीमित कार्य नहीं है। एक प्रोडक्शन इंसिडेंट जहाँ लॉग्स API टाइमआउट के बारे में चिल्ला रहे हों लेकिन मूल कारण पिछली तिमाही के माइग्रेशन स्क्रिप्ट में छिपा हो, वहाँ निर्णय लेने की क्षमता की आवश्यकता होती है।
Terra वही निर्णय क्षमता प्रदान करती है। यह लक्षणों को कारणों से अलग करती है। Luna नुकसान को कम करने के लिए एक रिट्राय लूप को पैच कर सकती है। Terra यह पूछती है कि क्या रिट्राय लूप का होना ही चाहिए, या क्या अंतर्निहित टाइमआउट आर्किटेक्चर ही असली समस्या है। यह अंतर तब मायने रखता है जब गलत सुधार एक अस्थायी सुस्ती को कैस्केडिंग विफलता (cascading failure) में बदल देता है। एक मजबूत मॉडल जो एक खराब प्रोडक्शन माइग्रेशन को रोकता है, वह उस कीमत के लायक है यदि वह एक इंजीनियर का पूरा दिन सफाई करने से बचा ले। एक रोका गया आउटेज महीनों के एस्केलेशन मार्जिन की भरपाई कर देता है।
Sol एक बीमा पॉलिसी है, डेली ड्राइवर नहीं
Sol उन मामलों के लिए है जहाँ अतिरिक्त क्षमता उच्च लागत को उचित ठहराती है। इसका उपयोग उच्च-जोखिम वाले रिव्यू या आर्किटेक्चरल बदलावों के लिए करें। ऑथेंटिकेशन फ्लो को फिर से बनाना, डेटाबेस शार्डिंग को फिर से डिजाइन करना, या पेमेंट गेटवे को प्रभावित करने वाले पुल रिक्वेस्ट (pull request) को मंजूरी देना रोज़ाना होने वाली घटनाएँ नहीं हैं। ये विशेष घटनाएँ हैं। Sol आपका डिफ़ॉल्ट नहीं होना चाहिए। इसे आपका एक्सेप्शन हैंडलर होना चाहिए, जिसे तब बुलाया जाए जब विफलता की लागत इतनी अधिक हो कि सस्ते मॉडल उसे अकेले न संभाल सकें।
उच्चतम-जोखिम वाली श्रेणी के लिए, Sol को एक नियतात्मक सत्यापनकर्ता (deterministic verifier) के साथ जोड़ें। Sol को स्कीमा परिवर्तन का सुझाव देने या आर्किटेक्चरल ट्रेड-ऑफ्स पर विचार करने दें। अपने CI पाइपलाइन, स्टैटिक एनालिसिस और इंटीग्रेशन टेस्ट को यांत्रिक विवरणों की पुष्टि करने दें। मॉडल अंतर्ज्ञान (intuition) लाता है। सत्यापनकर्ता गारंटी लाता है। यही वह संयोजन है जो आपको तब बचाता है जब ब्लास्ट रेडियस (blast radius) सबसे बड़ा हो।
एक राउटर बनाएं, धर्म नहीं
असली पैमाना यह नहीं है कि कौन सा मॉडल सबसे अच्छा है। सवाल यह है कि लागत, लेटेंसी और ब्लास्ट रेडियस के आधार पर किस मॉडल को इस कार्य को संभालना चाहिए। मॉडल के चुनाव को अपनी पहचान मानना बंद करें। यह न कहें, "हम Terra वाले लोग हैं।" इसके बजाय, टास्क क्लास के आधार पर रूट करें।
एक सरल क्लासिफायर बनाएं। आने वाले कार्यों को उनके ब्लास्ट रेडियस (blast radius) के आधार पर टैग किया जाता है। कम ब्लास्ट रेडियस वाले काम Luna को दिए जाते हैं। मध्यम ब्लास्ट रेडियस वाले काम Terra को दिए जाते हैं। उच्च ब्लास्ट रेडियस वाले काम एक शक्तिशाली मॉडल और एक डिटरमिनिस्टिक वेरिफायर (deterministic verifier) को भेजे जाते हैं। शुरुआत करने के लिए आपको एक सटीक मशीन लर्निंग क्लासिफायर की आवश्यकता नहीं है। कुछ ह्यूरिस्टिक्स (heuristics) ही काफी होंगे। वे कोड रिव्यू जो केवल आंतरिक यूटिलिटीज (internal utilities) को छूते हैं और सीमित लाइन काउंट तक ही रहते हैं? Luna। वे टिकट जिनमें डिप्लॉयमेंट पाइपलाइन, क्रॉस-सर्विस कॉल्स, या अस्पष्ट आवश्यकताओं का उल्लेख हो