AI के ठीक किए कोड को दूसरे AI से ग़लत साबित करवाने वाली पाइपलाइन

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

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

इसलिए मैंने जाँच को बाहर निकाल दिया। Claude का ठीक किया कोड Codex को थमाता हूँ, और सिर्फ़ एक चीज़ माँगता हूँ। "मान लो कि यह फ़िक्स ग़लत है, और इसका खंडन करके दिखाओ।"

लगातार तीन राउंड में और गहरे बग निकले

इस लूप की क़ीमत पहली बार मुझे एक लॉगआउट बग में समझ आई। लक्षण सीधा-सादा था। लॉगआउट बटन दबाने पर भी कभी-कभी लॉगआउट नहीं होता। Claude ने कारण ढूँढकर ठीक किया, और सिर्फ़ कोड पढ़ो तो सब जँचता था। मैं भी मर्ज करने ही वाला था।

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

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

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

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

रिव्यू नहीं, खंडन करवाता हूँ

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

इसके ऊपर मैं तीन शर्तें और लगाता हूँ।

1. सबूत का फ़ॉर्मैट अनिवार्य है। हर आपत्ति के साथ फ़ाइल और लाइन नंबर, और वह री-प्रोडक्शन सिनेरियो जुड़ा होना चाहिए जिसमें वह खामी असल में फटती है। "यह हिस्सा जोखिम भरा लगता है" स्वीकार नहीं है। सिनेरियो न बना पाओ तो वह शक आपत्ति नहीं, ख़ारिज माना जाता है। असल में खंडनकर्ता अक्सर अपने ही शक का खुद खंडन करके उसे वापस ले लेता है, और यही फ़ॉल्स पॉज़िटिव छाँटने वाला मुख्य पुर्ज़ा है।
2. फ़ैसला ग्रेड में लेता हूँ। पास / छोटे बदलाव के बाद पास / ब्लॉक, तीन दर्जे काफ़ी हैं। ग्रेड हो तो "आपत्ति तो है पर मर्ज हो सकता है" वाली हालत और "मर्ज नहीं होना चाहिए" वाली हालत आपस में गड्डमड्ड नहीं होतीं।
3. स्वतंत्र कॉन्टेक्स्ट में चलाता हूँ। खंडनकर्ता को सिर्फ़ diff और उससे जुड़ा कोड दिया जाता है। काम के दौरान की बातचीत या "ऐसा क्यों ठीक किया" वाली कहानी नहीं दी जाती। जिस पल कहानी साझा हुई, खंडनकर्ता भी उसी ग़लतफ़हमी में रँग जाता है।

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

कब चलाना है

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

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

दूसरा मॉडल ही क्यों

उसी मॉडल के नए सेशन से भी कुछ हद तक असर मिलता है। कॉन्टेक्स्ट अलग होने भर से कहानी में रँग जाने वाली समस्या तो मिट ही जाती है। पर कुछ महीने चलाने के बाद नतीजा यह निकला कि मॉडल ही अलग हो, तो पकड़ में आने वाली चीज़ें पक्के तौर पर ज़्यादा होती हैं।

हर मॉडल का ध्यान अलग-अलग जगह जाता है। एक अगर स्टेट मैनेजमेंट की टाइमिंग की समस्याओं पर संवेदनशील है, तो दूसरा कॉन्ट्रैक्ट के उल्लंघन और बाउंड्री वैल्यू पर। एक ही मॉडल के दो सेशन एक ही अंधा कोना साझा करते हैं, पर अलग मॉडलों के अंधे कोने एक-दूसरे से खिसके होते हैं। क्रॉस-वेरिफ़िकेशन की क़ीमत ठीक उसी खिसकाव से निकलती है।

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