जब कोई बग तीन फ़ाइलों और दो एसिंक लेयर्स में छिपा हो, तो ज़्यादातर टूल्स धमाके की जगह की ओर इशारा करते हैं, स्रोत की ओर नहीं। Claude Fable 5.1 एरर को उसके असली स्रोत तक ट्रेस करता है, मल्टी-फ़ाइल चेन संभालता है, और ऐसे प्रॉम्प्टिंग पैटर्न देता है जो सिर्फ़ टॉय रेपो पर नहीं, बल्कि प्रोडक्शन कोडबेस पर भी काम करते हैं।
अगर आपने कभी तीन घंटे उस बग का पीछा किया है जो उस फ़ाइल में था ही नहीं जिसमें एरर दिख रहा था, तो आप जानते हैं कि AI डीबगिंग सहायता क्यों मायने रखती है। Claude Fable 5 ने प्रोडक्शन कोड पर लार्ज लैंग्वेज मॉडल क्या कर सकता है, इसकी सीमा ऊपर उठाई, और इसके 5.1 अपडेट ने डेवलपर्स की दो सबसे अहम चीज़ों को और धार दी: बड़े कॉन्टेक्स्ट में लगातार सटीकता, और लक्षणों पर पैच लगाने के बजाय रूट-कॉज़ पहचानना। यह लेख बताता है कि व्यवहार में इसका क्या मतलब है, और इसके लिए उन कोडबेस का इस्तेमाल करता है जिन पर डेवलपर रोज़ काम करते हैं, न कि चुने हुए डेमो प्रोजेक्ट जिनमें तीन फ़ाइलें और एक साफ़ बग होता है।
AI कोडिंग डेमो और असली इंजीनियरिंग काम के बीच का अंतर हमेशा कॉन्टेक्स्ट का रहा है। डेमो रेपो में तीन फ़ाइलें होती हैं, साफ़ इंपोर्ट होते हैं, और एक बग होता है जो एक फ़ंक्शन में आराम से बैठा रहता है। प्रोडक्शन कोडबेस में सैकड़ों मॉड्यूल होते हैं, सर्कुलर डिपेंडेंसी होती हैं, पिछले फ़्रेमवर्क की पुरानी एब्स्ट्रैक्शन होती हैं, और ऐसी एरर होती हैं जो अपने स्रोत से पाँच लेयर दूर दिखती हैं। Fable 5.1 दूसरी स्थिति के लिए बना है।
Claude Fable 5 में 200,000 टोकन की कॉन्टेक्स्ट विंडो है, जो लगभग 150,000 शब्दों के कोड तक फैलती है। इसमें ज़्यादातर नॉन-मोनोलिथिक सर्विसेज़ पूरी तरह समा जाती हैं। 5.1 अपडेट ने यह सुधारा कि मॉडल उस विंडो के दूर के हिस्सों पर कैसे ध्यान देता है: पिछले वर्ज़न 80,000 टोकन पहले की परिभाषाओं पर साफ़ तौर पर कमज़ोर पड़ जाते थे, और कोई इंपोर्ट या कॉन्फ़िगरेशन वैल्यू छूट जाती थी। 5.1 में यह गिरावट काफ़ी हद तक कम हुई है।
डीबगिंग के लिए यह मायने रखता है, क्योंकि असली बग रिलेशनल होते हैं। स्टैक ट्रेस api_handler.py की लाइन 412 की ओर इशारा करता है, लेकिन जिस null वैल्यू से यह हुआ वह बारह कॉल पहले auth_middleware.js में सेट हुई थी। जो मॉडल गहराई पर अपनी सटीकता खो देता है, वह लक्षण पर ही पैच लगा देगा। Fable 5.1 असली स्रोत तक ट्रेस करने की ज़्यादा संभावना रखता है, और यही फ़र्क है एक ऐसे फ़िक्स में जो टिकता है और उस फ़िक्स में जो अगले स्प्रिंट में फिर सामने आ जाता है।
टॉय कोड स्व-निहित होता है। असली कोडबेस में एनवायरनमेंट-विशिष्ट कॉन्फ़िग फ़ाइलें होती हैं, वेंडर लाइब्रेरी होती हैं जिनकी अपनी बग सतहें होती हैं, और वर्षों पहले ऐसी आर्किटेक्चरल फ़ैसले लिए गए होते हैं जिनकी शर्तें अब लागू नहीं होतीं। Fable 5.1 इसे सिर्फ़ सिंटैक्स पैटर्न मिलाने के बजाय कोड की संरचना पर तर्क करके संभालता है। जब आप कोई सर्विस फ़ाइल पेस्ट करके एरर ट्रेस करने को कहते हैं, तो यह अक्सर फ़िक्स सुझाने से पहले जुड़े इंटरफ़ेस के आकार का अनुमान लगा लेता है, न कि एरर मैसेज को किसी जाने-पहचाने पैटर्न से मिला देता है।
व्यवहार का यही बदलाव एक उपयोगी डीबगिंग सेशन को उस सेशन से अलग करता है जिसमें मॉडल आत्मविश्वास से कह देता है कि गलत लाइन बदल दो।
स्टैक ट्रेस किसी कोडबेस का सबसे ईमानदार आउटपुट होते हैं। वे साफ़ दिखाते हैं कि क्या हुआ और किस क्रम में हुआ। समस्या यह है कि एसिंक सीमाओं, वेंडर लाइब्रेरी और कई सर्विसेज़ में फैला 40 लाइन का ट्रेस एक साथ बहुत सारी स्थिति को थामे रखने की माँग करता है। यहीं 200K कॉन्टेक्स्ट वाला मॉडल आपके वर्कफ़्लो में अपनी जगह कमाता है।
असली दुनिया का सबसे आम पैटर्न: एक यूटिलिटी फ़ंक्शन में टाइप मिसमैच की वजह से एक null दो-तीन ऐसी लेयर्स से ऊपर फैलता है जो उसे वैलिडेट नहीं करतीं, और आख़िर में कुछ क्रैश हो जाता है। एरर मैसेज क्रैश की जगह दिखाता है, स्रोत की नहीं। डेवलपर 30 मिनट गलत फ़ाइल पढ़ने में गँवा देते हैं।
जब आप Fable 5.1 को पूरा ट्रेस और चेन की हर फ़ाइल की सामग्री देते हैं, तो वह प्रसार को पीछे की ओर भरोसेमंद तरीके से मैप करता है। एक व्यावहारिक प्रॉम्प्टिंग पैटर्न:
Here is a stack trace and the contents of every file it references.
Identify the point of origin, not just the point of failure.
Then show me the call that introduced the bad value.
स्रोत और फ़ेल्योर पॉइंट के बीच यह साफ़ अंतर बनाना ज़रूरी है। इसके बिना, सक्षम मॉडल भी आम तौर पर फ़ेल्योर वाली जगह पर पैच लगाते हैं। इसके साथ आपको एक ओरिजिन ट्रेस मिलता है जो दिखाता है कि ख़राब वैल्यू कॉल चेन में पहली बार कहाँ आई।
💡 पहले पूरा स्टैक ट्रेस पेस्ट करें, फिर फ़ाइल सामग्री उसी क्रम में दें जिस क्रम में वे ट्रेस में आती हैं। Fable 5.1 कॉल की दिशा और प्रसार पथ का अनुमान लगाने के लिए उसी क्रम का इस्तेमाल करता है।
एसिंक बग एक खास श्रेणी हैं, क्योंकि स्टैक ट्रेस अक्सर पूरी कहानी नहीं बताता। कोई Promise जो तीन टिक पहले रिजेक्ट हुआ था, शायद उस ट्रेस में न दिखे जो आप देख रहे हैं। रेस कंडीशन और भी कम सबूत छोड़ती हैं और अक्सर रुक-रुक कर होती हैं, जिससे उन्हें दोबारा बनाना अविश्वसनीय हो जाता है और दोष तय करना लगभग नामुमकिन।
Fable 5.1 एसिंक डीबगिंग को अपने पिछले वर्ज़न से ज़्यादा व्यवस्थित तरीके से लेता है। सादे पाठ में अनौपचारिक रूप से बताई गई घटनाओं का क्रम दिए जाने पर, यह संभावित एक्ज़ीक्यूशन टाइमलाइन बना सकता है और पहचान सकता है कि शेयर्ड स्टेट कहाँ प्रतिस्पर्धी ऑपरेशन्स से बदला जा सकता है। यह कभी-कभी इवेंट के क्रम या शेयर्ड स्टेट के आकार को स्पष्ट करने के लिए पूछेगा, और यह आत्मविश्वास से दिया गया गलत जवाब देने से बेहतर व्यवहार है।
यहाँ जो पैटर्न काम करता है, वह कथात्मक है: आप बताएँ कि आप क्या होता देख रहे हैं, किस क्रम में, किन कंकरेंसी शर्तों में। फिर मॉडल से पूछें कि कौन सा शेयर्ड म्यूटेबल स्टेट यह लक्षण पैदा कर सकता है। मॉडल संदिग्धों को सीमित करने में उन स्टैक ट्रेस को समझने से बेहतर है जो समय में यात्रा करते दिखते हैं।
स्टैक ट्रेस दिखाते हैं कि रनटाइम पर क्या टूटा। लॉजिक बग अक्सर बिल्कुल कोई स्टैक ट्रेस नहीं बनाते। वे गलत व्यवहार, चुपचाप डेटा करप्शन, या ऐसी स्थितियाँ पैदा करते हैं जो प्रोडक्शन में सिर्फ़ किसी खास यूज़र फ़्लो में सामने आती हैं जिसे किसी ने टेस्ट नहीं किया। ये सबसे महँगे बग होते हैं, क्योंकि ये चुपचाप समय के साथ बढ़ते रहते हैं।
TypeScript और टाइप्ड Python ने null से जुड़े क्रैश काफ़ी कम किए हैं, पर उन्हें पूरी तरह ख़त्म नहीं किया है। ऑप्शनल चेनिंग और यूनियन टाइप अपनी जटिलता जोड़ते हैं, और लीगेसी JavaScript अब भी उन टीमों के प्रोडक्शन कोड का बड़ा हिस्सा है जिन्हें पूरे माइग्रेशन का समय नहीं मिला।
Fable 5.1 आंशिक रूप से टाइप्ड या बिना टाइप वाले कोडबेस पर स्टैटिक तर्क में ख़ास तौर पर मज़बूत है। उसे एक फ़ंक्शन सिग्नेचर और एक सैंपल इनपुट दें, और उससे वे सभी पाथ गिनवाने को कहें जो null या undefined पैदा कर सकते हैं। यह नेस्टेड ऑब्जेक्ट एक्सेस चेन को अच्छी तरह संभालता है, और व्यवहार में ज़्यादातर रनटाइम null फ़ेल्योर ठीक यहीं से शुरू होते हैं।
एक प्रॉम्प्टिंग पैटर्न जो लगातार काम करता है:
Given this function, list every code path where the return value
could be null, undefined, or structurally invalid for the caller.
Assume the caller does no validation.
वह "मान लें कि कॉलर कोई वैलिडेशन नहीं करता" वाली शर्त मॉडल को आशावादी होने के बजाय रक्षात्मक तरीके से तर्क करने पर मजबूर करती है। इसके बिना, डिफ़ॉल्ट व्यवहार यह मानना होता है कि कॉल करने वाला कोड समस्याएँ पकड़ लेगा।
ऑफ़-बाय-वन एरर धोखेबाज़ होती हैं, क्योंकि सिद्धांत में वे सरल हैं और कोड रिव्यू में अदृश्य रहती हैं। एक इंडेक्स जो < होना चाहिए था पर <= है, एक स्लाइस जो आख़िरी एलिमेंट गिरा देता है, एक लूप जो खाली इनपुट पर एक इटरेशन कम चलता है। ये बग इसलिए बच जाते हैं क्योंकि इंसान कोड को इरादे के लिए पढ़ते हैं, अंकगणित के लिए नहीं, और इरादे में शायद ही कभी यह शामिल होता है कि "लेकिन अगर एरे में शून्य एलिमेंट हों तो?"
Fable 5.1 बाउंड्री अंकगणित में भरोसेमंद है। जब आप उससे किसी फ़ंक्शन के इंडेक्स ऑपरेशन की ऑडिट करने को कहते हैं, तो वह लूप कंडीशन की एक तालिका बनाता है, जिसमें एज केस के हिसाब से उनका बाउंड्री व्यवहार दिखता है: खाली एरे, एक एलिमेंट, विषम लंबाई का इनपुट, सम लंबाई का इनपुट। यह तालिकाबद्ध आउटपुट टेस्ट केस लिखने में सीधे काम आता है, क्योंकि एक नज़र में दिखा देता है कि कौन सी शर्तें बिना सुरक्षा के हैं।
💡 Fable 5.1 से बाउंड्री विश्लेषण ऐसी तालिका में माँगें जिसके एक कॉलम में एज केस हो और दूसरे में परिणाम। यह फ़ॉर्मेट गैप्स को ऐसे साफ़ दिखाता है जैसे गद्य विवरण नहीं दिखा सकते।
मॉडल उतना ही उपयोगी है जितने आपके दिए प्रॉम्प्ट। सामान्य प्रॉम्प्ट सामान्य जवाब देते हैं। ये तीन पैटर्न भाषा या कोडबेस के प्रकार से परे, लगातार ऐसा डीबगिंग आउटपुट देते हैं जिस पर अमल किया जा सके।
इसे तब इस्तेमाल करें जब आपके पास स्टैक ट्रेस और संबंधित फ़ाइल सामग्री हो।
Here is a stack trace:
[PASTE TRACE]
Here are the files involved:
[PASTE FILES IN TRACE ORDER]
Trace the error to its point of origin.
Identify the specific value, state, or condition that caused it.
Do not patch the failure line. Find where the bad value was introduced.
आख़िरी निर्देश सब कुछ बदल देता है। इसके बिना, आपको फ़ेल्योर वाली जगह पर पैच मिलता है, जो लक्षण का इलाज करता है। इसके साथ, आपको ओरिजिन ट्रेस मिलता है जो दिखाता है कि ख़राब वैल्यू सिस्टम में कहाँ दाख़िल हुई।
इसे रिग्रेशन के बाद इस्तेमाल करें, जब कोई फ़ीचर जो पिछले स्प्रिंट में चल रहा था अचानक काम करना बंद कर दे।
This feature worked before the following change was merged:
[PASTE DIFF OR DESCRIBE CHANGE]
Current behavior:
[DESCRIBE BUG]
Expected behavior:
[DESCRIBE EXPECTED]
List all the ways the merged change could have caused this regression.
Rank them by likelihood. For each, show the specific code location.
रैंकिंग का निर्देश मॉडल को सभी सैद्धांतिक संभावनाओं को बराबर वज़न देकर सूचीबद्ध करने के बजाय प्रायिकता के आधार पर तर्क करने पर मजबूर करता है। रैंकिंग के बिना, आपको दस संभावित कारण मिलते हैं। रैंकिंग के साथ, आप सबसे संभावित तीन से शुरू करते हैं और केवल तब आगे बढ़ते हैं जब वे गलत निकलें।
इसे तब इस्तेमाल करें जब आपने बग की पुष्टि कर ली हो और ऐसा फ़िक्स चाहते हों जो रिग्रेशन न करे।
This is the bug:
[DESCRIBE BUG AND LOCATION]
This is the function that needs to change:
[PASTE FUNCTION]
Provide a corrected version of the function.
Then provide three unit tests: one for the original failure case,
one for the happy path, one for an edge case the original code did not handle.
तीन-टेस्ट वाली संरचना मायने रखती है। मॉडल अक्सर ऐसे टेस्ट लिखते हैं जो सिर्फ़ उसी केस को कवर करते हैं जिसे उन्होंने अभी ठीक किया, जब तक आप संरचना साफ़ तौर पर न बताएँ। एज केस की शर्त मॉडल को आस-पास के परिदृश्यों के बारे में सोचने पर मजबूर करती है, और अगला रिग्रेशन अक्सर वहीं से शुरू होता है।
सीमाओं के बारे में सीधे बात करना किसी टूल को अचूक मानने से ज़्यादा उपयोगी है। Fable 5.1 मज़बूत है, पर ऐसी वास्तविक स्थितियाँ भी हैं जहाँ यह कमज़ोर पड़ता है, और जहाँ अपना तरीका बदलना इस उम्मीद से बेहतर नतीजे देता है कि मॉडल खुद भरपाई कर लेगा।
200,000 टोकन बड़ी संख्या है, पर अनंत नहीं है। पूरा मोनोरेपो, गहराई से नेस्टेड डिपेंडेंसी ट्री, या ऐसी सर्विस जो वेंडर लाइब्रेरी पूरी तरह इंपोर्ट करती है, इस सीमा को छू लेगी या पार कर देगी। जब आप सीमा के करीब पहुँचते हैं, तो मॉडल अनुमानित तरीकों से बिगड़ता है: वह कॉन्टेक्स्ट में पहले की क्लास परिभाषाएँ खो देता है, ऐसे फ़िक्स देता है जो अब मौजूद न रहे मेथड सिग्नेचर का हवाला देते हैं, या अलग-अलग फ़ाइलों के मिलते-जुलते नाम वाले वेरिएबल में उलझ जाता है।
इसका उपाय है दायरा कड़ाई से सीमित करना। अपना पूरा कोडबेस न पेस्ट करें। केवल स्टैक ट्रेस पेस्ट करें, फिर उस ट्रेस में आने वाली फ़ाइलें, और तब तक कुछ और नहीं जब तक मॉडल खुद न कहे कि उसे अतिरिक्त कॉन्टेक्स्ट के बिना कुछ तय नहीं हो सकता।
💡 संकीर्ण शुरुआत करें। फ़ाइलें तभी जोड़ें जब मॉडल साफ़ कहे कि उसे उनकी ज़रूरत है। ज़्यादातर प्रोडक्शन बग के लिए उससे कहीं कम कॉन्टेक्स्ट चाहिए होता है, जितना डेवलपर पहली बार समस्या के सामने बैठते समय मानकर चलते हैं।
Fable 5.1 उतना हेज नहीं करता जितना कुछ डेवलपर्स को अनिश्चितता में काम करने वाले टूल से उम्मीद होती है। यह अधूरी जानकारी पर तर्क करते हुए भी आत्मविश्वास से, अच्छे फ़ॉर्मेट में फ़िक्स दे देगा। यह एक सामान्य LLM व्यवहार पैटर्न है, Fable की खास बात नहीं। डीबगिंग संदर्भों में व्यावहारिक जोखिम यह है कि एक आत्मविश्वासी गलत फ़िक्स आपको एक घंटे तक गलत रास्ते पर ले जाता है, इससे पहले कि आपको पता चले कि आधार ही गलत था।
इसका उपाय सीधा है: मॉडल कोई फ़िक्स सुझाए तो उससे पूछें कि उस निष्कर्ष तक पहुँचने में उसने कौन-सी मान्यताएँ लीं। "कॉलिंग कोड, एनवायरनमेंट और डेटा के बारे में आपने जो हर मान्यता बनाई है, उसकी सूची दें" जैसा प्रॉम्प्ट कुछ भी चलाने से पहले छिपे तर्क के अंतराल सामने ला देता है।
Claude Fable 5 PicassoIA पर Large Language Models सेक्शन के तहत सीधे उपलब्ध है। इसके लिए कोई API कुंजी नहीं चाहिए, कोई लोकल इंस्टॉलेशन नहीं चाहिए, और कोई पेड सब्सक्रिप्शन ज़रूरी नहीं है। ब्राउज़र इंटरफ़ेस बड़े पेस्ट को साफ़ तरीके से संभालता है और इनपुट को उस तरह नहीं काटता जैसे सरल चैट इंटरफ़ेस काटते हैं, जो तब मायने रखता है जब आप कई पूरी फ़ाइलें पेस्ट कर रहे हों।
PicassoIA पर डीबगिंग सेशन शुरू करने के चरण:
सेशन संदेशों के बीच कॉन्टेक्स्ट बनाए रखता है, इसलिए आप पहले स्थापित की गई बातें खोए बिना और फ़ाइलें जोड़ सकते हैं या फ़ॉलो-अप सवाल पूछ सकते हैं।
गणित-भारी या एल्गोरिदम-भारी कोड पर काम करने वाली टीमों के लिए, DeepSeek R1 को Fable 5.1 के साथ चलाना उपयोगी है। यह डिफ़ॉल्ट रूप से चेन-ऑफ़-थॉट रीज़निंग इस्तेमाल करता है और अपना काम दिखाता है, जिससे पकड़ना आसान होता है कि कब उसने बीच में कोई गलत निष्कर्ष निकाला।
कम जोखिम वाले फ़िक्स या छोटे बग के बैच पर तेज़ नतीजों के लिए, Claude 4.5 Haiku बुनियादी कोड रीज़निंग से समझौता किए बिना रफ़्तार देता है। अलग-थलग फ़ंक्शन में सिंगल-फ़ाइल बग के लिए, Granite 8B Code Instruct 128K कोड कार्यों के लिए ही बना है और जब बग अपनी विंडो में साफ़ तरह फ़िट हो, तो अच्छा प्रदर्शन करता है।
| मॉडल | सबसे अच्छा किसके लिए | कॉन्टेक्स्ट विंडो |
|---|---|---|
| Claude Fable 5 | मल्टी-फ़ाइल डीबगिंग, बड़े रेपो | 200K टोकन |
| Claude Sonnet 5 | संतुलित रीज़निंग और रफ़्तार | 200K टोकन |
| DeepSeek R1 | एल्गोरिदमिक और गणित-भारी बग | 128K टोकन |
| Claude 4.5 Haiku | तेज़, कम दाँव वाले फ़िक्स | 200K टोकन |
| Granite 8B Code | सिंगल-फ़ाइल, सीमित बग | 128K टोकन |
यह जानने का सबसे अच्छा तरीका कि Claude Fable 5.1 आपके खास कोडबेस पर काम करता है या नहीं, उसे उसी बग पर आज़माना है जो तीन हफ़्ते से आपकी बैकलॉग में पड़ा है। डेमो रेपो नहीं, टॉय फ़ंक्शन नहीं: वह असली बग जिसे आपकी टीम तय नहीं कर पाई। असली ट्रेस पेस्ट करें, असली फ़ाइलें पेस्ट करें, इस लेख के प्रॉम्प्टिंग पैटर्न इस्तेमाल करें, और देखें कि वह क्या सामने लाता है।
PicassoIA आपको Fable 5.1 तक तुरंत पहुँच देता है, बिना किसी सेटअप के। आपका पहला असली डीबगिंग सेशन दो मिनट से कम में शुरू हो सकता है। अगर Fable 5.1 पहली कोशिश में इसे हल नहीं करता, तो उसके आउटपुट की तुलना Claude Sonnet 5 या DeepSeek R1 से करें, जो दोनों एक ही इंटरफ़ेस में बिना टूल बदले उपलब्ध हैं।
इन तीनों मॉडलों के बीच, आपको लगभग निश्चित रूप से समस्या पर वह कोण मिलेगा जो आपने पहले नहीं सोचा था। लक्ष्य सोचने का काम आउटसोर्स करना नहीं है। लक्ष्य यह है कि यांत्रिक ट्रेसिंग का काम खत्म हो, ताकि आपका ध्यान उन फ़ैसलों पर जा सके जिनमें इंसानी विवेक चाहिए: क्या फ़िक्स आर्किटेक्चर के हिसाब से सही है, क्या यह कोई नई मान्यता जोड़ता है जो आसपास की किसी चीज़ को तोड़ सकती है, और क्या सही जवाब पैच है या कोई गहरा बदलाव।
अपनी सूची के सबसे कठिन बग से शुरू करें। बस वही टेस्ट मायने रखता है।
अपनी भाषा चुनें
