पिछले तीन हफ़्ते AI-सहायता प्राप्त सॉफ़्टवेयर डेवलपमेंट में मेरे लिए सबसे खुलासा करने वाले रहे हैं।
Claude Fable फिर से तस्वीर में आया, और उसी समय में, OpenAI ने Sol, Terra और Luna के साथ GPT‑5.6 जारी किया। बाज़ार का संकेत स्पष्ट था: फ्रंटियर लैब्स अब अलग-थलग सफलताएँ नहीं भेज रही हैं, बल्कि क्षमता, मूल्य स्तरों और तैनाती की गति के बीच की खाई को कम कर रही हैं। Anthropic अब Fable 5 को अपने टॉप-एंड लॉन्ग-हॉरिज़न मॉडल के रूप में Opus 5 की सूची मूल्य से लगभग दोगुनी कीमत पर बेचता है, जबकि OpenAI GPT‑5.6 को एक परिवार के रूप में प्रस्तुत कर रहा है जो फ्लैगशिप क्षमता से लेकर अधिक लागत-संवेदनशील कार्यों तक फैला हुआ है। इस बीच, xAI Grok 4.5 की कीमत इतनी आक्रामक रूप से तय कर रहा है कि किसी भी लागत-प्रदर्शन चर्चा में इसे गंभीरता से लेना होगा।
और फिर भी उन हफ़्तों में मैंने जो सबसे महत्वपूर्ण बात सीखी, उसका लॉन्च पेजों या बेंचमार्क स्लाइड्स से बहुत कम लेना-देना था।
मेरे वातावरण में असली सफलता तैयारी थी।
हमारे पास कहानियाँ तैयार थीं। हमने काम को ऐसे टुकड़ों में बाँटा था जिन्हें एजेंटिक कोडिंग सिस्टम वास्तव में निष्पादित कर सकते थे। एक बार वह कतार मौजूद हो गई, तो थ्रूपुट बेतुका हो गया। Codex, Claude, Cursor, Grok और वर्कफ़्लो में अन्य टूलिंग के माध्यम से, लगभग दस दिनों में 2 मिलियन से अधिक लाइन कोड लिखे गए। यह संख्या प्रचार की तरह लगती है जब तक आप यह नहीं देखते कि इसे किस चीज़ ने संभव बनाया: जादू या अमूर्त स्वायत्तता नहीं, बल्कि सीमित काम की एक स्थिर धारा जिसमें मॉडलों को चलते रहने के लिए पर्याप्त संरचना थी।
यह पहली चीज़ है जो अभी भी बहुत से लोग चूक जाते हैं। आउटपुट विस्फोट इसलिए नहीं होता क्योंकि मॉडल अचानक स्व-निर्देशित इंजीनियर बन गए। ऐसा इसलिए होता है क्योंकि मनुष्यों ने युद्धक्षेत्र तैयार किया।
दूसरी चीज़ जो मैंने सीखी, वह यह है कि बग्स मार्केटिंग के कबूल करने से कहीं अधिक तेज़ी से पैमाने पर दिखाई देते हैं।
Codex एक अच्छा उदाहरण है। लंबे समय तक चलने वाले काम के बारे में OpenAI की अपनी सामग्री स्पष्ट करती है कि टिकाऊ थ्रेड्स एक ट्रेड-ऑफ़ के साथ आते हैं: निरंतरता उपयोगी है, लेकिन लंबे समय तक चलने वाले थ्रेड्स नए सिरे से शुरू करने की तुलना में अधिक महंगे और प्रबंधित करने में कठिन हो सकते हैं। Goals सुविधा ठीक इसी उद्देश्य के लिए डिज़ाइन की गई है: एक थ्रेड को एक सीमित उद्देश्य से जोड़े रखना, न कि हर कठिन कार्य को एक बढ़ते हुए प्रॉम्प्ट में बदलना। व्यवहार में, यह मेरे देखे गए अनुभव से मेल खाता है। यदि कोई प्रक्रिया बहुत लंबी चलती है, तो बेहतर पैटर्न अक्सर उसे रोकना, एक स्वच्छ हैंडओवर के लिए पूछना, सत्र को पुनः आरंभ करना और एक नए लक्ष्य के साथ जारी रखना होता है। यह केवल सुविधा नहीं है। यह अक्सर परिचालन स्वच्छता है।
एक और अधिक ठोस Codex समस्या भी है जिसका अब एक दृश्य सार्वजनिक पेपर ट्रेल है: सबएजेंट और लोकल-स्टेट ब्लोअप्स।
ओपन इश्यू #34061 एक ऐसे मामले का दस्तावेजीकरण करता है जिसमें एक पुनर्जीवित पैरेंट थ्रेड ने हज़ारों चाइल्ड JSONL लॉग और सैकड़ों गीगाबाइट्स का संग्रहीत सत्र इतिहास उत्पन्न किया। एक अन्य इश्यू स्पष्ट रूप से चेतावनी देता है कि fork_context=true बड़े पैरेंट हिस्ट्री को चाइल्ड एजेंटों में स्नैपशॉट कर सकता है, जिससे शुद्धता जोखिम और टोकन खपत दोनों बढ़ जाते हैं। एक और सार्वजनिक रिपोर्ट दिखाती है कि एक बार ~/.codex में बड़े SQLite लॉग और सत्र स्थिति जमा हो जाने पर Codex कोल्ड स्टार्ट 1–5 मिनट के प्रतीक्षा समय में बदल जाते हैं। कुल मिलाकर, वे रिपोर्टें एक विफलता मोड का वर्णन करती हैं जिसे कई पावर उपयोगकर्ता तुरंत पहचान लेंगे: एक बार जब स्थानीय मेटाडेटा परत काफी बड़ी हो जाती है, तो सत्र स्थिरता उत्पाद अनुभव का एक गंभीर हिस्सा बन जाती है।
यह मायने रखता है क्योंकि मल्टी-एजेंट कोडिंग हमेशा डेमो में बेहतर दिखती है, बजाय एक तनावग्रस्त डेवलपमेंट मशीन पर।
वादा स्पष्ट है। OpenAI के मल्टी-एजेंट डॉक्स बताते हैं कि समानांतर सबएजेंट स्वतंत्र वर्कस्ट्रीम को कैसे गति दे सकते हैं, और वह वादा वास्तविक है। लेकिन वही डॉक्स यह भी चेतावनी देते हैं कि सबएजेंट टोकन उपयोग बढ़ाते हैं और साझा परिवर्तनीय स्थिति में बार-बार लिखने वाले कार्यों के लिए उपयुक्त नहीं हो सकते हैं। ChatGPT Learn पर समानांतर-एजेंट मार्गदर्शन और भी स्पष्ट है: पढ़ने-भारी काम जैसे अन्वेषण, परीक्षण, ट्राइएज और सारांशीकरण से शुरू करें; लिखने-भारी फ्लो के साथ अधिक सावधान रहें क्योंकि संघर्ष और समन्वय ओवरहेड तेज़ी से बढ़ते हैं। वह चेतावनी सैद्धांतिक नहीं है। जिस किसी ने भी एजेंटों के एक बेड़े को एक ही समय में पूर्ण परीक्षण सूट की ओर दौड़ते देखा है, वह जानता है कि इसका क्या मतलब है।
मेरे अपने सेटअप में, यह अब पूरी श्रेणी की परिभाषित परिचालन समस्याओं में से एक है।
समस्या यह नहीं है कि क्या मॉडल समानांतर करने के लिए पर्याप्त स्मार्ट हैं। वे स्पष्ट रूप से हैं। समस्या यह है कि उन्हें अभी भी कहीं बेहतर ऑर्केस्ट्रेशन सीमाओं की आवश्यकता है, क्योंकि "डेलिगेट करने के लिए पर्याप्त स्मार्ट" "मशीन स्वास्थ्य, स्थानीय प्राथमिकता और प्रतिस्पर्धा के तहत लागत अनुशासन को संरक्षित करने के लिए पर्याप्त स्मार्ट" के समान नहीं है।
वही बेमेल मूल्य निर्धारण में भी दिखाई देता है।
Cursor इस समस्या को साफ-साफ दर्शाता है। इसका वर्तमान मूल्य निर्धारण पारदर्शी है: दो मासिक उपयोग पूल हैं, एक Cursor के अपने मॉडलों के लिए और दूसरा तीसरे पक्ष के "Other Models" के लिए। यह यह भी दिखाता है कि Auto एक एकल चीज़ नहीं है। Auto Cost फ्लैट टोकन मूल्य निर्धारण का उपयोग करता है, लेकिन Balance और Intelligence रूटेड मॉडल की दर से बिल करते हैं, और रूटर Composer, GPT‑5.6, Claude या Grok जैसे मॉडलों में से चुन सकता है। कभी-कभार इंटरैक्टिव काम करने वाले लोगों के लिए, वह लचीलापन आकर्षक है। बर्स्टी, औद्योगिक वर्कलोड के लिए, यह एक जाल बन सकता है। एक महीने का प्रीमियम बजट कुछ बहुत उत्पादक दिनों में गायब हो सकता है।
मैंने उस विफलता मोड का ठीक एक समीक्षा-भारी परिदृश्य में परीक्षण किया।
एक परियोजना में लगभग 500k नई कोड लाइनें जोड़ी गईं। हमारी समीक्षा प्रणाली ने उस डेल्टा में लगभग 1,500 मुद्दे चिह्नित किए, जिसमें डुप्लिकेट और झूठी सकारात्मकताएँ शामिल थीं। Cursor CLI को उनके माध्यम से पीसने का कार्य सौंपा गया था। कच्ची टोकन मात्राएँ बहुत बड़ी थीं। आउटपुट उपयोगी था। लेकिन मेरे उपयोग के मामले के लिए अर्थशास्त्र गलत था। जब गहन समीक्षा और सुधार कार्य एक सप्ताह में मासिक भत्ते को खत्म कर सकता है, तो उपकरण अभी भी अच्छा हो सकता है, लेकिन सदस्यता समझ में नहीं आती।
वह तनाव अब हर जगह है।
Claude अभी भी वह प्रणाली है जिसके साथ मैं सबसे अधिक काम करने का आनंद लेता हूँ। लेकिन यह वह भी है जो मुझे लागत के बारे में सबसे अधिक जागरूक बनाता है। Codex, विशेष रूप से व्यापक GPT‑5.6 पारिस्थितिकी तंत्र में, अक्सर अपने आलोचकों के स्वीकार करने से कहीं अधिक थ्रूपुट ले जा सकता है। Grok 4.5 कोई मज़ाक नहीं है; इसकी सार्वजनिक मूल्य निर्धारण और स्थिति इसे एक वैध दावेदार बनाती है। Anthropic का अपना मूल्य निर्धारण Fable-बनाम-Opus ट्रेड-ऑफ़ को इतना स्पष्ट करता है कि यह लगभग आपके लिए संपादकीय लिखता है: फ्रंटियर क्षमता मौजूद है, लेकिन इनवॉइस भी मौजूद है।
और फिर सबसे कठिन समस्या है, वह जिसे कोई लॉन्च इवेंट वास्तव में हल नहीं करता।
लगभग हर फ्रंटियर कोडिंग मॉडल में जिसका मैं उपयोग करता हूँ, अभी भी अंडरपावर्ड और ओवरइंजीनियर्ड के बीच एक निराशाजनक अंतर है।
चुनाव अक्सर एक ऐसे मॉडल के बीच होता है जो पर्याप्त रूप से नहीं सोच रहा है और एक ऐसा मॉडल जो हाथ में काम के लिए बहुत अधिक सोच रहा है। Fable 5 के लिए Anthropic का अपना मार्गदर्शन प्रभावी रूप से इसे स्वीकार करता है। यह कहता है कि उच्च प्रयास ओवरप्लान कर सकता है, नियमित काम कम प्रयास से लाभान्वित हो सकता है, और संक्षिप्त निर्देश अक्सर फूली हुई मचान से बेहतर प्रदर्शन करते हैं। OpenAI अपने GPT‑5.6 मार्गदर्शन में कुछ ऐसा ही कहता है: पुराने मॉडलों से माइग्रेट करते समय, उसी तर्क स्तर से शुरू करें और फिर एक स्तर नीचे परीक्षण करें, क्योंकि नए मॉडल अक्सर कम टोकन के साथ गुणवत्ता को संरक्षित या सुधार सकते हैं। यह कहने का एक तकनीकी तरीका है जो हम में से कई लोग अनुभवजन्य रूप से खोज रहे हैं: प्रयास डायल को ओवरशूट करना अभी भी बहुत आसान है।
शायद इसका एक हिस्सा अभी भी हम पर है।
शायद निर्देश फ़ाइलें बहुत लंबी हैं। शायद कुछ मचान अब मॉडलों की मदद करने के बजाय उनसे लड़ रही है। वह सिद्धांत कम से कम Anthropic के अपने संदर्भ-इंजीनियरिंग मार्गदर्शन के अनुरूप है, जो कहता है कि संदर्भ जानकारीपूर्ण लेकिन कसा हुआ होना चाहिए। एक वास्तविक संभावना है कि कुछ जटिलताएँ जिनका हम मॉडलों पर आरोप लगाते हैं, वे बढ़ी हुई प्रॉम्प्ट बुनियादी ढाँचे द्वारा प्रवर्धित हो रही हैं।
लेकिन उसके लिए जिम्मेदार ठहराने के बाद भी, व्यापक निष्कर्ष अपरिवर्तित रहता है।
मॉडल पहले की तुलना में कम स्पष्ट गलतियाँ कर रहे हैं। लेकिन वे गलतियाँ जो वे अभी भी करते हैं, अक्सर अधिक खतरनाक होती हैं क्योंकि उन्हें पहचानना कठिन होता है। वे कोड के अंदर छिपी होती हैं जो अन्यथा पॉलिश, जानबूझकर और पेशेवर दिखती हैं। दूर से कार्यान्वयन जितना बेहतर दिखता है, मैं उतना ही अधिक संदिग्ध होना सीख गया हूँ।
यही कारण है कि मैं AI-कोडिंग विजयवाद की वर्तमान लहर के प्रति संशय में हूँ।
मैं समझता हूँ कि प्रचार कहाँ से आता है। यदि आप इन प्रणालियों के अंदर हर दिन नहीं रहे हैं, तो अकेला थ्रूपुट चमत्कारिक लग सकता है। और इसमें से कुछ वास्तव में है। लेकिन दैनिक हाथों-हाथ उपयोग दूसरे पहलू को भी उजागर करता है: बिलिंग अनिश्चितता, ऑर्केस्ट्रेशन विफलताएँ, लंबे सत्रों की नाजुकता, सतही सरलीकरण या विस्तृत ओवरडिज़ाइन की ओर एक प्रवृत्ति, और मानव पैकेजिंग, समीक्षा और निर्णय की निरंतर आवश्यकता।
हम अभी भी एक आदर्श LLM कोडिंग दुनिया से बहुत दूर हैं।
प्रचार पूरी तरह से गलत नहीं है। लेकिन यह अभी भी परिचालन वास्तविकता से कहीं कम ईमानदार है।
